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. _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
