[Freedombox-discuss] Intel Compute Stick

Blibbet blibbet at gmail.com
Wed Jan 14 03:20:18 UTC 2015


Thanks for clarification of UEFI use on ARM server. I was talking about
OSVs (MSFT, APPL) who are also OEMs (iPad, Surface Tablet, etc), using
UEFI on their hardware, to help keep their OS tied to their HW. ARM use
wasn't really for any technical need for booting on ARM. I have yet to
experience UEFI on ARM[64] servers yet.

> You can expect to see more ARM hardware booting with UEFI (which as I
> understand it is in fact Free Software, although it can have non-free
> modules) (and ACPI (boo!)).


Actually, SMM scares me more than ACPI. SMM is used like a software TPM
now, look for SMM LockBox in the code. And ARM is emulating Intel on
this "feature", sigh.

TianoCore.org is BSD-licensed. Some of the PXE drivers from Intel side
are not available, using CoreBoot for PI would fix that, there are two
existing people who've done it, just need Intel and UEFI Forum to adopt
it. On ARM side, Linaro's fork of UEFI is better w/r/t source access.

However, I'm concerned that while UEFI might be licensed in an
OSI-compliant license, there are other restrictions from UEFI Forum
members regarding using it. I don't have any info on this, except
secondhand info who claim it would cost $$ to do nonstandard things to
UEFI, like build it w/o ACPI support or SMM support or with a CoreBoot
PI init package, etc. Maybe UEFI Forum member OEMs can do changes like
this, not sure, maybe it cost a LOT of money in backdoor deals. I
presume INTC (and MSFT) have a lot of IP in UEFI, to control commercial
usage, beyond FOSS license.

Another issue with UEFI and Linux is the Secure Boot thing is still only
being done by Linux OEMs (eg, SUSE) for pricey server products, no
low-cost consumer devices that properly use UEFI's security on Linux.
OEM can own the CA process and not require MSFT to be CA, even. The
'shim' that most use with Linux is an insecure boot method. If UEFI is
to be used, it should be used properly, not with an insecure hack, to
workaround Win8. FBX needs an OEM who is a non-MSFT CA who can build
with SecureBoot that boots FreedomBox securely, IMO. (Or, the UEFI needs
to be built without SecureBoot, and also without TPM or TrustZone
support, perhaps along with APCI and SMM and other scary backdoors.)

Probably simpler to try and find an OEM building Chrome boxes, who use
CoreBoot, and try to get FBX based on that hardware profile, than to try
and do all these things to make UEFI usable on Linux.



More information about the Freedombox-discuss mailing list