Hi Daniel,
On Thu, 8 Oct 2020 at 06:06, Daniel Thompson daniel.thompson@linaro.org wrote:
On Wed, Oct 07, 2020 at 10:52:30AM -0600, Simon Glass wrote:
Hi Heinrich,
On Thu, 1 Oct 2020 at 15:15, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 1. Oktober 2020 22:27:43 MESZ schrieb Simon Glass sjg@chromium.org:
Hi Heinrich,
On Mon, 28 Sep 2020 at 12:20, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 28.09.20 18:51, Simon Glass wrote:
Hi,
I thought perhaps it might be worth starting a thread on this, as despite Grant and Heinrich kinding spending a bit of time talking about this, I am still very much in the dark about how 'embedded'
and
distro/other boot flows are going to come together with EBBR. Of course this would be easier f2f.
Case 1: Firmware loads the kernel to a particular address, selects DT and boots it. The kernel may require EFI boot services, or may not, but
in
the general case the firmware provides them.
The Linux kernel has an EFI stub. This EFI stub consumes UEFI
services
and starts the main part of the kernel.
What about the case where we don't want to use EFI?
Nobody forbids you to forego UEFI. But the topic of EBBR is UEFI.
With UEFI you have a standardized way of booting which allows to boot alternative operating systems with alternative firmwares. This allows to replace OS and firmware independently.
This is the bit that I just don't understand. When you talk about a standard way, I just don't see it. It seems that there are many ways to boot and none of it is standardised. It almost seems like UEFI is being used to avoid having to standardise things.
I don't follow this (or perhaps I do follow it but don't agree with it).
UEFI is a standard. If is a flexible one although from the point of view of EBBR I think "scaleable" is a better term. It is the capacity to scale down to a very small feature set that allows it to be used in EBBR.
EBBR is mostly a set of constraints on a UEFI implement that reduces implementer flexibility (e.g. increasing standardization). We are willing to explicitly relax UEFI requirements but prefer to upstream that sort of thing to the UEFI spec (one of the recent changes to UEFI can, I think, be traced to that).
From the linux side, how do I determine what boots? From the firmware side, how can I check that booting will succeed?
That will depend to some extent on the use-case.
The introduction of secure boot will be a big improvement here. On systems where the OEM (or similar) controls a signing key then passing a signature check means that the payload has been tested and is known to be bootable.
From a testing point of view, how can I write a test of the end-to-end flow (well, firmware to Linux user space)?
The answer here is not very clear.
One of my team spent a little while looking at testing EBBR implementations using EFI applications and the scaleability was a problem since it becomes easy to have test suite that passes because almost all the tests get skipped due to the feature being disabled.
Like the above answer about verifying bootability I think we need to constrain what the system is for before we can see clearly how to test it.
There are use cases where you are tight on resources and will decide to skip this standard.
That seems like a huge missed opportunity. We just end up with n+1 ways of doing it.
Personally I'm more than a little sceptical that systems that tight on resources will actually exist in any market in which EBBR could ever be relevant.
Further I'm even more sceptical that if such systems will exist that they would have benefited from an alternative approach to standardization.
efibootmgr can only be used if the firmware provides UEFI runtime services.
Currently you cannot use efibootmgr to set variables with U-Boot as U-Boot does not offer SetVariable() at runtime yet.
I'm not even sure that is feasible/desirable. U-Boot may not be allowed to access the boot media if linux is also using it. How about we have a way for linux to write variable updates somewhere so that U-Boot picks them up on the next boot?
In principle this is can be achieved using UEFI by providing an app that uses EFI Boot Services to do update the variables.
However there is a chicken-and-egg problem for installers and similar (how to set the boot order to cause the app to run) and AFAIK there is no PoC implementation to play with at this point.
We are talking about having a 'secure' part of EBBR, which allows
for
secure boot. Should we have a 'defined boot' part of EBBR, that defines how the kernel/DT/initrd are selected, based on EFI
variables?
Secure Boot in UEFI terms involves setting up the PK, KEK, db, and
dbx
variables. Then every UEFI binary loaded can only be started via
service
StartImage() if it was signed with a certificate with a public key in
db
and not in dbx.
Verification of intrd and fdt is out of scope for the UEFI
specification.
If these are in a FIT then the verification can be done in U-Boot.
If you ensure the integrity of your binaries without relying on the UEFI secure boot infrastructure, that is fine.
Perhaps we should avoid using the UEFI secure-boot stuff then? What benefit does it provide?
Primarily standardization...
Unfortunately I just don't know enough about all the different boot flows used by the different distros. It seems like crazy town. Does anyone have some pointers so I can do some study?
Debian/Ubuntu, Fedora and Suse all use UEFI [-> shim] -> GRUB ->
Linux
if the firmware running the installer image supports UEFI.
FreeBSD and OpenBSD can be started as UEFI payloads but they
typically
do not use GRUB.
Here is a good starting point: https://wiki.ubuntu.com/UEFI/SecureBoot
OK thank you. What are SHIM and MOK not incorporated into the boot loader?
Shim was created to install Linux on devices that only have Microsoft certificates in the KEK.
If you control the PK and KEK UEFI variables, you don't need shim.
OK. So there is no way to add keys within the BIOS itself? Or is it just that people don't want the hassle?
From an EBBR point of view I would expect it to be an implementation decision. For some use cases key enrolment makes sense, for others not so much.
In the PC space, Microsoft required that vendors include a means for users to change the keys that are trusted as part of some certification programme. However AFAIK that rule does not apply to Arm even in the cases where that certification programme is relevant.
So UEFI is a standard, in that it describes APIs. But so is the C library or ACPI, or C for that matter. I think there is another level missing here.
My point is not that systems are too constrained to use UEFI. It's more that there isn't a lot of point, for many systems. It seems to just add complexity, although it makes things simpler for Linux, I imagine. Some of the points made in this thread seem to be about removing arch-specific code from U-Boot and putting it in an EFI application, but to what end?
The valuable piece of a boot standard IMO would be to describe behaviour, how various features are configured (e.g. verified boot, adding kernels/devicetree/initrd, boot selection, key management, recovery) and how to test it.
Reading your responses, if I understand things correctly, EBBR is just a short doc that suggests using EFI protocols to boot Linux. It doesn't specify what any of the pieces should be, how they should interact, even less what their behaviour should be. I'd like to see a boot standard specify:
- what U-Boot (or some other bootloader) does and the environment it provides (EBBR seems to have some of this) - what any of the 'glue' pieces between U-Boot and linux are allowed to do, their inputs and outputs (this means grub, etc.) - how linux controls what boots, key management, etc.
Without this it is just 'please use EFI', so far as I can see. Is that the intent or is it just that it is in the early stages?
Regards, Simon