From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathew McBride To: development@lists.ipfire.org Subject: Re: ARM 64? Date: Mon, 18 Jun 2018 09:40:24 +1000 Message-ID: <3A1243D4-40E2-4A00-BB9D-592E0F962387@traverse.com.au> In-Reply-To: <1cfe866b-f889-447e-3421-aa56e8792d1d@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6429865908339483018==" List-Id: --===============6429865908339483018== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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,IP= Sec etc. operations) I am certain that an RNG is part of the SEC engine, but I need to check the d= river status on Linux. /proc/crypto output for those interested: https://gist.github.com/mcbridematt= /11f14c78ed4e35e97adf2f027010e374 Regards, Mathew=20 =EF=BB=BFOn 15/6/18, 3:09 am, "Peter M=C3=BCller" = wrote: 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 acceleratio= n. =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, but= 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 brandi= ng in > order of performance (or similar) like Intel has. >=20 > That might actually turn out to be a bigger marketing problem, but we w= ill 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 due= to >> having more cache, DDR4 etc (and higher clock). >=20 > 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 stora= ge. 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 s= pecific > features like cache and good single-core performance. >=20 >> A72 is about double A53 in performance (and power consumption!) per MH= z, as >> A72 is a modern out-of-order speculative core (it did get hit with the >> Meltdown/Spectre issue). >=20 > Yes, wouldn't mind to have some systems based on that one since the A53= will be > too slow for really large enterprise deployments. >=20 >> 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. >=20 > I prefer the NICs in the SoC which gives great performance. The disadva= ntage > 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 sens= e 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 O= S, for >> the NXP >> > Layerscape/QorIQ SoC's this firmware is open source, and not str= ictly >> 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/ppa= -generic >> /blob/integration/ReleaseNotes.txt >> I am not a security expert, but it could be a good test environment fo= r 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 --===============6429865908339483018==--