UEFI on top of U-Boot on ARM
lists.denx.de
lists.denx.de
When enabled, the resulting U-Boot binary only grows by ~10kb, so it's very light weight.
For comparison, the original PC BIOS, which includes far more functionality than just a bootloader, is 8KB.
If you were expecting it to be lightweight, I'm afraid I've got disappointing news for you. The UEFI/aarch64 binary is 2MB or so. But it's like a mini-operating system with drivers for a bunch of disk hardware, network devices and filesystems, because it supports network booting and booting from files located on local disks (so similar to grub).
While I have no great love for UEFI, it's damn convenient to be able to use the UEFI command line to mount up local filesystems, browse files etc when troubleshooting boot problems. Also to be able to plug in a USB key, see the files there, and try booting from one of them.
Since SBSA/SBBR is used almost exclusively on servers, 2 MB - so what?
So UEFI can to the same as a much smaller u-boot?
As I say I have no great affection for UEFI. Internally the code is pretty awful. But if you want a standard that works the same across x86 and ARM servers and exists already on those servers, then it's UEFI (I'm aware you can run u-boot on x86, but next to no one actually does that).
BTW UEFI is fully open source as of a few months ago after Microsoft relicensed the FAT driver. So we're just comparing two free software projects with different takes on the booting problem.
U-boot is ported and regularly run on the MinnowBoard with an Intel Atom.
Do you speak about tianocore? I don't have much experience with it, can you configure it as well as u-boot and just compile in stuff you need?
Update: If you didn't know, u-boot supports signed images too. So UEFI is not necessary for this.
U-Boot does have support for more architectures and SoCs, but the Barebox code base is of _much_ higher quality. Also, the bourne-like shell is a pleasure to work with!
http://www.openbsd.org/60.html
It's actually pretty cool, the advantages of this approach are:
* We can use our standard boot(8) loader, which has already been ported to EFI for i386/amd64. Code sharing! :-)
* There is a single ELF kernel for all supported SoCs, no longer need special u-Boot headers/images.
* The kernel can be loaded off of our native filesystem (FFS/UFS) vs. FAT/ext2. The kernel can live inside the root filesystem and be updated normally.
The other option is insecure booting with no verification, and if your malware is running with privileges to be able to inject itself into the boot process, the machine is already compromised anyway.
In this case secure boot provides some means of protection. People not using UEFI however, they are vulnerable and most likely affected.
And that has to be less secure than UEFI by definition.
In that regard arguing about how UEFI brings attack surface seems misguided. Yes, there's is an attack surface, but that's only because now there is something to attack where there previously was a fully open door.
What you're saying is pretty much that any imperfect security measure lessons security compared to no measure at all, because it brings attack surface. That's a fairly backwards way of thinking.