From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: ARM 64? Date: Mon, 18 Jun 2018 18:11:15 +0200 Message-ID: <7a1c1b4c-d9a2-8803-de6d-5f505cfb6869@link38.eu> In-Reply-To: <3eb0858eb89351a7a38dc1422e8e78ff2d114a76.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0624989381542526271==" List-Id: --===============0624989381542526271== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, this looks quite good - I am strongly interested. :-) Best regards, Peter M=C3=BCller > 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 >=20 > Wow, that is a very extensive list of supported ciphers and hashes as well = as > the combination of HMAC + cipher mode. >=20 > IPsec in the kernel will basically be not consuming any CPU cycles for cryp= to. >=20 > Best, > -Michael >=20 >> >> 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 >> acceleration. >> =20 >> Apart from some low-level backdoors (baked into USB, ... firmware chip= s) >> 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, th= is >> 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 = due >> to >> >> having more cache, DDR4 etc (and higher clock). >> >=20 >> > Performance is also coming from the rest of the periphery. The RPi h= as 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 = 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, y= our >> Mustang >> >> is probably around the A72 level. >> >> >> >> In general, ARM network SoCs try to work 'smarter' instead of 'hard= er', >> so the >> >> high network performance comes from having very good network silico= n, >> 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 = 10G >> in this >> > case which I don't really understand. The only use-case that makes s= ense >> to me >> > is a server but for that the CPU is too slow and people would probab= ly >> 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 (PSC= I), >> 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. >> >=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 "We don't care. We don't have to. We're the Phone Company." --===============0624989381542526271== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ2dBZEZpRUV2UDRTaUdoRVlE SnlyUkxrMlVqeUQzMTduMmdGQWxzbjJhc0FDZ2tRMlVqeUQzMTcKbjJoNEl3Ly9STjF1ckpPUThz eVppRktIaVVGT0xxcnpZeFZCWWQrQkY2RTI0UTIxaG5hK3QxazdETVRWbXl3VQpnWDVLRHl3NTN1 WHJWRnQxczFIdnFxaEZ4cDRQQi9yM1hCWXlsODZ6VkpzU053WG9KSDBHVkFSUnJ5blZJSnhDClRh UWlmQlk0YURjRlBGd0x1VGlvYzVUczZpNTQ5bmhqc21qQ29FRE95cE5Gc0lMbGx4NWRYM1dOM3Zp c0c5UW0KZ0gzMTQ5WDNPaEJBUWtDTU1qTThlaU83bDBnOXVBaWVHODJFTS93dlFtK1lJR3JBMWNl UFBidXQveURnbUh6Ngp6OHZlU3V5Mk1qbEg2Sy9NdDQweWFsd0I0V3ZFVmJGN3Zia2RjMXlPcENw NWpUQTYzdGpLUmZocGRJM0l3aGxoCnhjWHRzaHRTUmxoWEs3WDFTbmVlRWpndCs3eEJWb09VVk5T eVlBaEp2bUYwUDRFdGFkR25aL0lVaXNHNzl5YjYKcHFLY3R4K3RTSWVUclFZQThzZWF5WVhuMm52 YjZoZEpYNVhWb2ZpOWRIZTByQ1VGN0FTVFc0cU16blpqN2RwOAoxL0pvTGk4L3kwcG1IZEsvanJl MkhuUExkVjN3M1RDaGZGenZwWGNCY3Q0ZnMzTWZpV0g0eDc0WTRMUkZMbnFZCmROY2F4TXc2Zitr aEhMTm10dk5SK1hDN2x0NGUxY3AxUXVxc1hDN3pIRzNPMzludjNvWHNnWUN6My9iYXJ0QWkKQm9w ZXdkYUJGMStyZjZzRS8xTWF1b3ZhcGRvTDhqek9ERzF0Q3M3djhBdlcxWXlBNmRJYnZpekpGWnBR eGdqSgpVSFU3Qk16bnROTDlPcjFXOGpKVlNIdXZjTUpKWTZpbjVEQ1JFSHFYY2hIN1NHMitNRWM9 Cj1VbEhRCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============0624989381542526271==--