Re: ARM 64?

["Peter Müller" <peter.mueller@link38.eu>]

[-- Attachment #1: Type: text/plain, Size: 7899 bytes --]

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" <peter.mueller(a)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 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" <michael.tremer(a)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."
>>>>     
>>>>     
>>>>
>>>>
> 
> 
> 

-- 
"We don't care.  We don't have to.  We're the Phone Company."


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]