From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: ARM 64? Date: Mon, 18 Jun 2018 12:23:52 +0100 Message-ID: <3eb0858eb89351a7a38dc1422e8e78ff2d114a76.camel@ipfire.org> In-Reply-To: <3A1243D4-40E2-4A00-BB9D-592E0F962387@traverse.com.au> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3608479393144723048==" List-Id: --===============3608479393144723048== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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. >=20 > /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 >=20 > Regards, > Mathew=20 >=20 > =EF=BB=BFOn 15/6/18, 3:09 am, "Peter M=C3=BCller" wrote: >=20 > Hello, > =20 > 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. > =20 > 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. :-) > =20 > Best regards, > Peter M=C3=BCller > =20 > > Hey Matt, > >=20 > > On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote: > >> Hi Michael, > >> > >> Just in response to your questions: > >> =EF=BB=BFOn 25/5/18, 11:10 pm, "Michael Tremer" > wrote: > >> =20 > >> =20 > >> 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, b= ut > not a > >> Mustang. > >> =20 > >> 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=3DTraverse+LS1043+Prototype > >=20 > > 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. > >=20 > > That might actually turn out to be a bigger marketing problem, but we > will see > > that in the future. > >=20 > >> 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 d= ue > to > >> having more cache, DDR4 etc (and higher clock). > >=20 > > Performance is also coming from the rest of the periphery. The RPi ha= s 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. > >=20 > > We have been trying to tell people that they should look out for some > specific > > features like cache and good single-core performance. > >=20 > >> 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 t= he > >> Meltdown/Spectre issue). > >=20 > > Yes, wouldn't mind to have some systems based on that one since the A= 53 > will be > > too slow for really large enterprise deployments. > >=20 > >> The latest gen of ARM64 server cores would all be well above A72, yo= ur > Mustang > >> is probably around the A72 level. > >> > >> In general, ARM network SoCs try to work 'smarter' instead of 'harde= r', > so the > >> high network performance comes from having very good network silicon, > taking > >> advantage of crypto accelerators etc. > >=20 > > 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 1= 0G > in this > > case which I don't really understand. The only use-case that makes se= nse > to me > > is a server but for that the CPU is too slow and people would probably > go for a > > A72-class CPU. > >=20 > >> > 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). > >> =20 > >> 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/p= pa- > 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. > >=20 > > Great that this is entirely open. > >=20 > > -Michael > >=20 > >> > >> =20 > >> Cheers, > >> Matt > >> =20 > >> > >> > =20 > --=20 > "We don't care. We don't have to. We're the Phone Company." > =20 > =20 >=20 >=20 --===============3608479393144723048==--