Re: ARM 64?

["Peter Müller" <peter.mueller@link38.eu>]

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

Hello,

this looks quite good - I am strongly interested. :-)

Best regards,
Peter Müller

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

-- 
"We don't care.  We don't have to.  We're the Phone Company."


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]