I know there is no real standard for ARM booting, but would it really have been too hard to come up with something simpler and more like what PC BIOS does? Then again, if you're already choosing to use grub, I guess you probably don't care...
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).
Probably not a version of Linux that can drive multiple types of recent PCIe graphics adapter, USB, SCSI hostadapter and network card though.
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?
> 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.
If everything was compiled into u-boot and a bit extra added, then yes. U-boot as it is commonly found (the small version you're referring to) doesn't do as much stuff as UEFI. Plus Secure Boot is a thing that people really care about, and when used correctly enhances your own security, it's not (always) some giant conspiracy.
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.
From a developer perspective is secure boot more of a obstacle than really useful. You need to use gummiboot, etc. to terminate the signing in order to use developer kernels without having a bottleneck, that one person in the company that does the signing, in the development process. (I am currently working with an Intel Quark X1020 where secure boot is enforced, it's not really nice)
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.
There's no need to be snarky. Fedora and Red Hat are very concerned about the fragmentation of ARM, and the fact that ARM is almost completely different from everything else. We actively try to make sure that upstream kernels boot unmodified out of the box on new aarch64 hardware as it comes out, working closely with vendors to ensure they upstream all their drivers and don't do stupid stuff. We have also co-written (with ARM) standards to ensure that any operating system will boot unmodified out of the box on any aarch64 server hardware, because in the end that's what is required to turn ARM into a serious server platform.
As someone who has added support for a few boards to both U-Boot and Barebox, I really recommend looking at Barebox first.
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!
This is the method that OpenBSD will be using for the armv7 port starting with 6.0, a version of u-boot loader loads our EFI bootloader ported to ARM, along with .dtb/FDT (Flattened Device Trees) files for each system that is currently supported.
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.
Given it looks like coreboot's ARM support is still not quite there from what I can see, I'm not surprised they picked u-boot which has been running on ARM for some time.
Don't believe the FUD. UEFI does not increase attack surface. It reduces it through means such as secure boot.
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.
Unless you're arguing for something new and different, the only other option you have to UEFI secure boot, is completely unverified boot which provides zero security.
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.
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.