+Bill Le jeu. 6 juin 2019 à 03:08, Ard Biesheuvel <[email protected]> a écrit :
> On Wed, 5 Jun 2019 at 21:28, Tom Rini <[email protected]> wrote: > > > > On Wed, Jun 05, 2019 at 08:30:12PM +0200, Ard Biesheuvel wrote: > > > On Wed, 5 Jun 2019 at 19:30, Tom Rini <[email protected]> wrote: > > > > > > > > On Wed, Jun 05, 2019 at 06:14:08PM +0100, Mark Brown wrote: > > > > > On Wed, Jun 05, 2019 at 02:16:11PM +0200, Ard Biesheuvel wrote: > > > > > > > > > > > The idea of EBBR is to move away from a vertically integrated > model, > > > > > > and permit systems or appliances to use packaged OSes in the > field, > > > > > > similar to how this is being done on servers today. The idea > that it > > > > > > is required for, say, company X shipping product Yrev0, to > upstream a > > > > > > new rev of the DT in order to tweak their board and ship product > Yrev1 > > > > > > is simply ridiculous. It doesn't scale, and we shouldn't care - > the DT > > > > > > bindings is what we care about, and if it adheres to those, the > > > > > > platform can provide any DT it wants, and there is no reason the > > > > > > kernel devs should ever need to look at it. > > > > > > > > > > I don't think anyone is particularly suggesting that (at least not > in > > > > > the portions of the thread I read properly, I have to confess I was > > > > > skimming a bunch of it)? > > > > > > > > Just so we're all on the same page, we do understand that someone > > > > somewhere is providing Yrev0.dtb and Yrev1.dtb, yes? Or are we > > > > expecting someone to be run-time fixing up Yboard.dtb for rev0 vs > rev1 > > > > vs .. ? > > > > > > Let me put it like this: company X is not interested in having to > > > engage with the distros to get Yrev1.dtb into the OS, nor do they want > > > to be forced to start from an official DTB and apply deltas to make it > > > correct. You ship a board with some description of the board that the > > > OS can understand - this is how the OS identifies which hardware it > > > runs on: the DT description. > > > > Where does this description that's coming with the board come from? > > That _matters_ if you want to have any idea what will be able to use it. > > > > From the platform, not from the OS. How the firmware achieves that is > left unspecified by EBBR, it only mandates that it is passed to the OS > via a config table. > > > > > > > For development, things are obviously different, I understand > that. > > > > > > Shipping DTs for devboards makes sense, especially while the DT > > > > > > bindings are not set in stone yet. But imposing this model for > > > > > > production is unsustainable. > > > > > > > > > > I don't think I've particularly seen anyone trying to do that for > > > > > anything other than devboards, like Tom says people with actual > products > > > > > usually don't even consider it. It's more that there is this > devboard > > > > > case where the DTs are currently in kernel and a lot of the people > > > > > hacking on things are using devboards if only for want of anything > else > > > > > so they naturally end up caring about that case. > > > > > > > > Keep in mind that the in-kernel dev board ones _are_ important as > that's > > > > what you start your custom platform from, 9 times out of 10. It's > quite > > > > often the case of "OK, $vendor gave us schematics for EVB, lets cut > what > > > > we don't need and tweak" with a matching set of cuts and tweaks to > the > > > > dts for the EVB. In the case of carrier+SOM it's just adding to, if > > > > using the stock carrier, or again adapting things for the custom > > > > carrier. > > > > > > Of course. But how is this relevant? I am not saying DTs have to be > > > truly original works, just that the OS should not be the one providing > > > it. > > > > Because we've been talking about where the device tree comes from, and I > > keep trying to point out that we are no where near a proven record of > > "DTB is always valid and functional with the Linux Kernel from here > > on out". There's not the tooling nor review to enforce that and there's > > a few examples every year (of just in-tree device trees, not custom end > > products) where it gets broken. > > > > So now, you are saying companies should only ship products with > devices trees that have been reviewed by the kernel community? > > This makes no sense to me whatsoever: the DT *bindings* are the > contract that we have with the platforms. If someone ships a DT that > adheres to the bindings, we are on the hook to fix it. If someone > ships a broken DT, it is their problem and they are fix it in their OS > fork, or they issue a firmware update that fixes it. > > > > > But maybe it's just me that's confused about what "shipping" means in > > > > this context. Almost no one bothers "shipping" the DTS files for a > > > > custom product to mainline Linux as no one is supposed to be running > > > > anything other than the provided software on the custom device and > so it > > > > goes where ever it goes for that products needs and support plans. > > > > Rarely does a board, devboard or finished end-user product, ship > with a > > > > DTB file stored stand-alone in a flash chip, that is intended as the > > > > final forever DTB. It's just another part of > > > > firmware-by-which-I-mean-the-whole-software-stack. > > > > > > Who said anything about the DT being stored in a flash chip? I already > > > explained more than once that it is up to the firmware to decide *how* > > > it stores the DT, and the filesystem is fine if it does not care about > > > security or if it implements some form of authentication. > > > > It's been stated I believe in other parts of this thread or perhaps I'm > > just thinking of the many other times people have talked about hardware > > shipping a device tree. If the hardware is shipping the DTB to use, > > it's often stored someplace other than normal storage so that it's not > > overwritten by accident. Similar to ACPI tables :) > > > > > The point is that we are trying to move from this custom device model > > > to a model where you can run a generic distro, without having to put > > > the burden on the OS vendor to bundle a DT for every platform that it > > > will ever run on, which is especially tricky if those platforms do not > > > exist yet. > > > > So we are, or are not trying to come up with recommendations for > > shipping a DTB file for hardware? > > > > I'm not sure i understand the question, but EBBR is not just a > recommendation. If you want to claim EBBR compliance, your platform > should be able to boot an OS that comes without bundled DTB images. > > > > > Which is why my whole point here has been that the DTB needs to be > > > > treated and signature checked just like any other part of what's > being > > > > loaded (kernel, initrd, grub and grub.conf OR systemd-boot and > > > > systemd-boot.conf, etc, etc). > > > > > > > > > > Again, I am not arguing that the DT should be linked into the firmware > > > executable, I am only saying that UEFI secure boot is not appropriate > > > for authenticating it (and that the OS should not be providing it) > > > > Are you just saying "the DT exists in the config table GUID, it is good" > > and ignoring the question of how the DT is put into the config table and > > any sort of "it is good" test? > > > > So now we are policing the DT as well, and checking whether it is > 'good' or not? The platform knows best how to describe the hardware, > so it is the hardware that provides the DT period. If a crappy product > provides a crappy DT, then you will get a crappy experience, just as > you might expect. > > > Finally, is UEFI secure boot appropriate for authentication of the > > initrd? The bootloader config files? > > > > No. initrd is a file system interpreted by the Linux kernel, and we > already have ways to authenticate that (unless you build it into the > kernel image, in which case you get it for free) > > bootloader config files are an implementation detail of the > bootloader, and the same reasoning applies: UEFI secure boot > authenticates the OS to the platform, not the other way around. If the > firmware wants to sign its config files, it can, and it might even > reuse some of the crypto code that UEFI secure boot uses. But it is > not part of UEFI secure boot. > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
