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üller > 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" 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 cryptography >>>> acceleration. >>>> >>>> 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" >>>> 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." >>>> >>>> >>>> >>>> > > > -- "We don't care. We don't have to. We're the Phone Company."