Re: ARM 64?

[Michael Tremer <michael.tremer@ipfire.org>]

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

On Mon, 2018-06-18 at 09:40 +1000, Mathew McBride wrote:
> 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

Wow, that is a very extensive list of supported ciphers and hashes as well as
the combination of HMAC + cipher mode.

IPsec in the kernel will basically be not consuming any CPU cycles for crypto.

Best,
-Michael

> 
> 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."
>     
>     
> 
>