-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hello guys,
so here is a quick status update on aarch64 & EFI:
* 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.
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.
* 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.
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.
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.
So, that is the July update from my side. Please feel free to ask any questions if there are any.
Best, - -Michael
On Mon, 2018-06-18 at 18:11 +0200, Peter Müller wrote:
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@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 cryptographyacceleration.
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@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."