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: Sat, 04 Aug 2018 20:31:25 +0200 Message-ID: <6de3b596-52d7-5b90-c951-39e56d9f191b@link38.eu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3320427357388430447==" List-Id: --===============3320427357388430447== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, thanks for the update. Sorry for high reply latencies here... :-| Especially after recent Spectre NG security vulnerabilities I am certainly interested in having some trustworthy hardware around. As mentioned already, ARM64 sounds good so far - there is no need to add another rant about the current situation on the CPU market. @Mathew: Any updates from the hardware side? :-) Best regards, Peter M=C3=BCller > Hello guys, >=20 > so here is a quick status update on aarch64 & EFI: >=20 > * EFI: We have a separate branch with a bootloader that runs in EFI > mode for x86_64 and aarch64. We won't support 32 bit x86 and EFI. >=20 > It seems to be running quite okay on most hardware, although we haven't > really tested enough yet to say if is ready for production. All in all > we might merge it for Core 124, but since there was no feedback > whatsoever it is hard to make that decision, yet. >=20 > * aarch64: We got a booting kernel and userland. It runs on the RPi 3 > with a little bit of manual configuration of the bootloader. Generally > I do not want to support any SBCs, but Arne used this one for testing > at least. >=20 > Since we don't have any other hardware and especially nothing that > supports EFI, we haven't brought the two things together, but are > looking forward to do this soon. >=20 > I have launched a virtual machine with both, aarch64 and EFI on the APM > Mustang that I have available and it is running well. It is fast, it is > stable and we don't expect a big backlog of bugs that we need to solve > before this is ready to be shipped. >=20 > So, that is the July update from my side. Please feel free to ask any > questions if there are any. >=20 > Best, > -Michael >=20 > On Mon, 2018-06-18 at 18:11 +0200, Peter M=C3=BCller wrote: >> Hello, >=20 >> this looks quite good - I am strongly interested. :-) >=20 >> Best regards, >> Peter M=C3=BCller >=20 >>> 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 wel= l as >>> the combination of HMAC + cipher mode. >>> >>> IPsec in the kernel will basically be not consuming any CPU cycles for cr= ypto. >>> >>> Best, >>> -Michael >>> >>>> >>>> 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 - ya= y!). >>>> However, after reading the datasheet it did not became clear to me i= f it >>>> has some built-in random number generator and/or cryptography >>>> acceleration. >>>> =20 >>>> Apart from some low-level backdoors (baked into USB, ... firmware ch= ips) >>>> 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 stil= l 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 o= ut 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 performan= ce: >>>> >> >>>> >> The LS1043 has the same A53 cores as the RPi3, but performs bette= r 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 >>>> 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 s= ome >>>> specific >>>> > features like cache and good single-core performance. >>>> >=20 >>>> >> A72 is about double A53 in performance (and power consumption!) p= er >>>> MHz, as >>>> >> A72 is a modern out-of-order speculative core (it did get hit wit= h the >>>> >> Meltdown/Spectre issue). >>>> >=20 >>>> > Yes, wouldn't mind to have some systems based on that one since th= e 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 'ha= rder', >>>> so the >>>> >> high network performance comes from having very good network sili= con, >>>> 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 1= x 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 prob= ably >>>> 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 (P= SCI), >>>> as well >>>> >> as some TPM-like functions. >>>> >> NXP provides a good overview: https://github.com/qoriq-open-sourc= e/ppa- >>>> generic >>>> >> /blob/integration/ReleaseNotes.txt >>>> >> I am not a security expert, but it could be a good test environme= nt 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 >=20 --=20 "We don't care. We don't have to. We're the Phone Company." --===============3320427357388430447== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ2dBZEZpRUV2UDRTaUdoRVlE SnlyUkxrMlVqeUQzMTduMmdGQWx0bDhQMEFDZ2tRMlVqeUQzMTcKbjJoMU1RLy9ibkc4dUI4L2dj QUJFMnJWZjBrRXFVMXlsTzFMdlN6M2UxaUR1WnU3SUpsS3NJNmpuQ2twOWZ0MAozTjB0SUNaUEZY YmpHUmxtd1RYcjV6N0ZuUElLQmcyc1gzZkVxT3FuN2dVM2w5TEtkMk1XNkdwZEp0M1d5dWhWCmJN UWlRdDM5cFZXbGY2cGF6TFYzQzliSjJyRGU0d2grNEtvekxDWDBlMEZJUkxpZHNYTzZqVXByT29p L2pJUm0KSjQ5MzN4c1VSOFVrUW9FOFhqdEY4WDh6QjFhZ2RFZEtaa2J5cWJWVFJpeTQzOXpvMEt6 emVqY1JxZTVJN2J0QwoxR0FBVEFZZVpjbkdWY2c1aHRiRXh5UWUvQmVyQkFEcEwrRm9YSFVnaHhZ cEZsMmJ3cjF6ZDRxOW1ydXMrdSswCklMeE9PN1Avc2RaM2pFaFQ0MjF4Wlg5a0QxdERnQnMxOFlr WHVoUmFjdmhoWWFxVktYZDN5MmpBdGVHeXB5N2EKeHM5SkJCZ1BkLzFkVTlNRWRjQjdPeTFlRm1t NUhFeDhwcXlpY3pRWlBXUVdsajdkSFlBSi9zTyswU01GMTdQbQpDL0NRUjZqOU5hL05CYjFlbkc0 OHNBNXR4RlYwRkNtR0pwZ0EveVpSSlBKMy9VNGZ6Rm1vcDQxL0hLcHlIcFM2CnhlZjJBc29MYWhL aGljQkJSNXJDb0hrMlZuaGxLaUlsck14bVdmK2lBUkhHSHE1SnhZeFEwQVJJYjgzTUh1NWkKMmdL Q3NvZ2o5V3BlSmxRMjhNNGRjRkNDQXljK0VWcnVEVTFuNEFXMmVSdlhNRGtuNWVDckFzZGE0NUVG K0hXVwpyc1E2cTcrVkwyclVlYUcrS3k1bVJMZzAxWStxOGJYS3VBMFFVVFY3ZlJKdzlGRlQzaG89 Cj12QTE4Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============3320427357388430447==--