
UEFI on top of U-Boot on ARM - zdw
http://lists.denx.de/pipermail/u-boot/2016-February/244378.html
======
userbinator
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.

~~~
rwmj
For aarch64, SBBR
[http://infocenter.arm.com/help/topic/com.arm.doc.den0044b/DE...](http://infocenter.arm.com/help/topic/com.arm.doc.den0044b/DEN0044B_Server_Base_Boot_Requirements.pdf)

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).

~~~
dTal
Mini??? I seem to recall you used to be able fit _Linux_ on a 1.44 megabyte
floppy...

~~~
rwmj
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?

~~~
chme
> 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.

So UEFI can to the same as a much smaller u-boot?

~~~
rwmj
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.

~~~
chme
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.

~~~
rwmj
EDK2 is built for Fedora here. It contains build instructions, link the
sources, etc.
[http://pkgs.fedoraproject.org/cgit/rpms/edk2.git/](http://pkgs.fedoraproject.org/cgit/rpms/edk2.git/)

------
nwmcsween
Why not barebox[1] which iirc is a fork of U-boot that does EFI, etc?

[1][http://www.barebox.org/](http://www.barebox.org/)

~~~
wkz
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!

------
brynet
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.

[http://www.openbsd.org/60.html](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.

------
Quequau
UEFI is one of the blocking hurdles for running CoreOS on Raspberry Pi and
ODROID boards. I wonder if this would help overcome that.

------
mappu
Patch from February - how far is this along?

------
voltagex_
Taking a different approach is EFIDroid -
[http://efidroid.org/](http://efidroid.org/)

------
green7ea
Why not coreboot?

~~~
mixedCase
Gotta NIH fast.

~~~
green7ea
Could you please explain what NIH is.

~~~
craigcabrey
Not invented here syndrome.

------
mariuolo
Does this also come with an increase in surface attack from malware?

~~~
josteink
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.

~~~
amluto
I would argue that, taking Secure Boot as a given, the UEFI design provides an
amazingly large surface which to attack Secure Boot.

~~~
josteink
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.

