public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Mathew McBride <matt@traverse.com.au>
To: development@lists.ipfire.org
Subject: Re: ARM 64?
Date: Mon, 18 Jun 2018 09:40:24 +1000	[thread overview]
Message-ID: <3A1243D4-40E2-4A00-BB9D-592E0F962387@traverse.com.au> (raw)
In-Reply-To: <1cfe866b-f889-447e-3421-aa56e8792d1d@link38.eu>

[-- Attachment #1: Type: text/plain, Size: 4826 bytes --]

Hi Peter,
There are two crypto options on our board:
- ARMv8 Cryptography instructions (similar to AES-NI on x86)
- Freescale SEC/CAAM engine (a 'hardware accelerator' that can do many TLS,IPSec etc. operations)
I am certain that an RNG is part of the SEC engine, but I need to check the driver status on Linux.

/proc/crypto output for those interested: https://gist.github.com/mcbridematt/11f14c78ed4e35e97adf2f027010e374

Regards,
Mathew 

On 15/6/18, 3:09 am, "Peter Müller" <peter.mueller(a)link38.eu> wrote:

    Hello,
    
    this board sounds very interesting indeed (trustworthy hardware - yay!).
    However, after reading the datasheet it did not became clear to me if it
    has some built-in random number generator and/or cryptography acceleration.
    
    Apart from some low-level backdoors (baked into USB, ... firmware chips)
    it seems like this is suitable for security relevant devices. Looking
    forward to hear some experiences with IPFire on it. :-)
    
    Best regards,
    Peter Müller
    
    > Hey Matt,
    > 
    > On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
    >> Hi Michael,
    >>
    >> Just in response to your questions:
    >> On 25/5/18, 11:10 pm, "Michael Tremer" <michael.tremer(a)ipfire.org> wrote:
    >>     
    >>     
    >>     I think you hardware is good enough for a builder. But I still am not sure
    >> what
    >>     to expect from the CPU. It will be faster than a Raspberry Pi, but not a
    >>     Mustang.
    >>     
    >> We did some benchmarks with the Phoronix test suite a while ago, this will
    >> give you an idea:
    >> http://openbenchmarking.org/result/1708303-TR-
    >> 1703199RI93&obr_hgv=Traverse+LS1043+Prototype
    > 
    > I had a look at that. And yes indeed, it is a bit hard to figure out the
    > performance by the CPU name alone for most ARM SoCs. There is no branding in
    > order of performance (or similar) like Intel has.
    > 
    > That might actually turn out to be a bigger marketing problem, but we will see
    > that in the future.
    > 
    >> To give an idea of the Cortex (ARM designed)-based core performance:
    >>
    >> The LS1043 has the same A53 cores as the RPi3, but performs better due to
    >> having more cache, DDR4 etc (and higher clock).
    > 
    > Performance is also coming from the rest of the periphery. The RPi has a slow
    > and not very stable USB bus to talk to the network to and SD card storage. Even
    > with a faster CPU it might very often just wait for data.
    > 
    > We have been trying to tell people that they should look out for some specific
    > features like cache and good single-core performance.
    > 
    >> A72 is about double A53 in performance (and power consumption!) per MHz, as
    >> A72 is a modern out-of-order speculative core (it did get hit with the
    >> Meltdown/Spectre issue).
    > 
    > Yes, wouldn't mind to have some systems based on that one since the A53 will be
    > too slow for really large enterprise deployments.
    > 
    >> The latest gen of ARM64 server cores would all be well above A72, your Mustang
    >> is probably around the A72 level.
    >>
    >> In general, ARM network SoCs try to work 'smarter' instead of 'harder', so the
    >> high network performance comes from having very good network silicon, taking
    >> advantage of crypto accelerators etc.
    > 
    > I prefer the NICs in the SoC which gives great performance. The disadvantage
    > only is that they sometimes to odd configurations like 5x 1G and 1x 10G in this
    > case which I don't really understand. The only use-case that makes sense to me
    > is a server but for that the CPU is too slow and people would probably go for a
    > A72-class CPU.
    > 
    >>     > There is a TrustZone firmware running in the ring/EL above the OS, for
    >> the NXP
    >>     > Layerscape/QorIQ SoC's this firmware is open source, and not strictly
    >> required
    >>     > to run the system (it gets loaded by u-boot after power on).
    >>     
    >>     What does the firmware do?
    >> It implements some vendor-specific power-management extensions (PSCI), as well
    >> as some TPM-like functions.
    >> NXP provides a good overview: https://github.com/qoriq-open-source/ppa-generic
    >> /blob/integration/ReleaseNotes.txt
    >> I am not a security expert, but it could be a good test environment for secure
    >> boot, private key storage and other things.
    > 
    > Great that this is entirely open.
    > 
    > -Michael
    > 
    >>
    >>     
    >> Cheers,
    >> Matt
    >>  
    >>
    >>
    
    -- 
    "We don't care.  We don't have to.  We're the Phone Company."
    
    



  reply	other threads:[~2018-06-17 23:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <c51182f4-9958-4b76-83e0-9a8affa81038@traverse.com.au>
2018-05-24  1:32 ` Mathew McBride
2018-05-24 10:31   ` Michael Tremer
2018-05-24 11:02     ` Mathew McBride
2018-05-24 14:44       ` Michael Tremer
2018-05-25  2:45         ` Mathew McBride
2018-05-25 13:10           ` Michael Tremer
2018-05-28 10:32             ` Mathew McBride
2018-05-28 11:15               ` Michael Tremer
2018-06-14 17:08                 ` Peter Müller
2018-06-17 23:40                   ` Mathew McBride [this message]
2018-06-18 11:23                     ` Michael Tremer
2018-06-18 16:11                       ` Peter Müller
2018-07-26  9:50                         ` Michael Tremer
2018-08-04 18:31                           ` Peter Müller
2018-08-19  8:54                           ` Mathew McBride
2018-08-20 15:11                             ` Michael Tremer
2018-05-23  2:46 Guy Ellis
2018-05-23  9:58 ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A1243D4-40E2-4A00-BB9D-592E0F962387@traverse.com.au \
    --to=matt@traverse.com.au \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox