Hi Daniel, On Thu, 8 Oct 2020 at 06:06, Daniel Thompson <daniel.thomp...@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.g...@gmx.de> wrote: > > > > > > Am 1. Oktober 2020 22:27:43 MESZ schrieb Simon Glass <s...@chromium.org>: > > > >Hi Heinrich, > > > > > > > >On Mon, 28 Sep 2020 at 12:20, Heinrich Schuchardt <xypron.g...@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 _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
