From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4FF9C07E95 for ; Fri, 2 Jul 2021 20:09:16 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1CD0C61402 for ; Fri, 2 Jul 2021 20:09:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1CD0C61402 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7DFF7829E2; Fri, 2 Jul 2021 22:09:14 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="cqSGRYcy"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6A08F829F0; Fri, 2 Jul 2021 22:09:12 +0200 (CEST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id C392182903 for ; Fri, 2 Jul 2021 22:09:07 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x72a.google.com with SMTP id f6so10607546qka.0 for ; Fri, 02 Jul 2021 13:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WvV3azMwtS1MTCEdT3yLUSZiTmemJ+SK1+TeqM+lAyw=; b=cqSGRYcy61viQp6UcQMoCcVl2d8T/URFQWeEnKTjhF5LflAeYGzCvAwZIHMVVilhjh P9Ihzuj9NRHkZ9CeK+EW8K0DtWYHG4hjhug+VJPlEkuNodYdTPEyPDgzBJZ/HmjXy9RV umwt63YoL/wERsXsoxNOnNsqgD7ZFrGBgJNSM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WvV3azMwtS1MTCEdT3yLUSZiTmemJ+SK1+TeqM+lAyw=; b=Hwjfauhc6wGLIwLzpQNxFKKAY8RHp2CoGVpBKV10g8Y99Ip5iVfyjDPC0yh0gexhBM FWZF+ul2ohkdeECVRYPESSYXOo1PvZuGRkVstu3Pz6EuTc37Qfy+447fPY8QHRjl1+ug t8yN0gPjznpPciPVWFvJS8idPp1Cd3ZUcYO8dGbQ7oOgTlcRaAGbKOtyN5BDznxzMjc7 C4ig748b0FmOAA8NXsYuKu4wHQsAMGEFEvyVLhD2nLb56iEGae6+py+szXKitzM01s13 e3DvWTwyuMg1kuegp34Bz0Sm3fWPaaqeByPnEMyiDIhHHGZ6rTJhboTM76XskhVH2aEx YpSA== X-Gm-Message-State: AOAM532eLn2CN7RP7NskvsnsjOyEmdyxSQKStuyx2BjmJmbmDUpPF5lM NzduPKt/Ig5F/JDQEtnuz3vIzQ== X-Google-Smtp-Source: ABdhPJzCRrGVQF73z8NwdYXweWg8Dd7yDD1QmBYzmbV5nn+kmgz1rjAlU0uyGXVA0h8y2IwDgZMlpg== X-Received: by 2002:a37:789:: with SMTP id 131mr1508673qkh.385.1625256546638; Fri, 02 Jul 2021 13:09:06 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-447a-194c-2139-e81a.res6.spectrum.com. [2603:6081:7b01:cbda:447a:194c:2139:e81a]) by smtp.gmail.com with ESMTPSA id s13sm1811008qkm.87.2021.07.02.13.09.05 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Jul 2021 13:09:06 -0700 (PDT) Date: Fri, 2 Jul 2021 16:09:04 -0400 From: Tom Rini To: Mark Kettenis Cc: Simon Glass , u-boot@lists.denx.de, pali@kernel.org, xypron.glpk@gmx.de, ilias.apalodimas@linaro.org, agraf@csgraf.de, yamada.masahiro@socionext.com Subject: Re: [PATCH 0/7] efi: Various tidy-ups and drop the default Message-ID: <20210702200904.GD9516@bill-the-cat> References: <20210628014841.501036-1-sjg@chromium.org> <5613706c36261e2a@bloch.sibelius.xs4all.nl> <20210628133711.GY9516@bill-the-cat> <5613729265807ef8@bloch.sibelius.xs4all.nl> <561381f2e2a95db0@bloch.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kawfBpz4YELAgyI3" Content-Disposition: inline In-Reply-To: <561381f2e2a95db0@bloch.sibelius.xs4all.nl> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean --kawfBpz4YELAgyI3 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 02, 2021 at 09:48:27PM +0200, Mark Kettenis wrote: > > From: Simon Glass > > Date: Fri, 2 Jul 2021 13:05:20 -0600 > > Cc: Tom Rini , U-Boot Mailing List , > > Pali Roh=E1r , > > Heinrich Schuchardt , > > Ilias Apalodimas , > > Alex Graf , > > Masahiro Yamada > > Content-Type: text/plain; charset=3D"UTF-8" > >=20 > > Hi Mark, > >=20 > > On Mon, 28 Jun 2021 at 11:49, Mark Kettenis w= rote: > > > > > > > From: Simon Glass > > > > Date: Mon, 28 Jun 2021 08:18:26 -0600 > > > > > > > > Hi Tom, Mark, > > > > > > > > On Mon, 28 Jun 2021 at 07:37, Tom Rini wrote: > > > > > > > > > > On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > > > > Date: Sun, 27 Jun 2021 19:48:34 -0600 > > > > > > > > > > > > > > It has come to light that EFI_LOADER adds an extraordinary am= ount of > > > > > > > code to U-Boot. For example, with nokia_rx51 the size delta i= s about > > > > > > > 90KB. About 170 boards explicitly disable the option, but is = is clear > > > > > > > that many more could, thus saving image size and boot time. > > > > > > > > > > > > EFI_LOADER used to be a lot smaller. It is great to see that o= ver the > > > > > > years UEFI support has become more complete, but a lot of that = new > > > > > > code implements features that are not at all essential for just > > > > > > booting an OS from storage. If that growth leads to the sugges= tion to > > > > > > disable EFI_LOADER completely by default, we're putting the cart > > > > > > before the horse. > > > > > > > > > > Well, I see I forgot to prefix my patch with RFC, but I hadn't fo= und > > > > > EFI_LOADER being used in the wild on armv7, but wasn't sure about= the > > > > > BSD families. I did see that Debian doesn't use it, and that Arm= bian > > > > > doesn't even use it on aarch64. > > > > > > > > > > > > The current situation is affecting U-Boot's image as a svelt = bootloader. > > > > > > > > > > > > Really? I know UEFI has a bad reputation in the Open Source wo= rld, > > > > > > and some of its Microsoft-isms are really annoying (yay UCS-2).= But > > > > > > it works, it provides a standardized approach across several pl= atforms > > > > > > (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Pers= onally > > > > > > I'd wish the industry had standardized on Open Firmware instead= , but > > > > > > that ship sailed a long time ago... > > > > > > > > > > > > I find it hard to imagine that 90k is a serious amount of stora= ge for > > > > > > something that is going to include a multi-MB Linux kernel. Th= is > > > > > > isn't code that lives in SPL or TPL where severe size restricti= ons > > > > > > apply. > > > > > > > > > > In one of those cases where I need to pop back in to the other (N= okia > > > > > N900 specific) thread and see if the big size reduction really wa= s just > > > > > disabling EFI_LOADER, it's perhaps just one of those "fun" things= about > > > > > Kconfig and anything other than "make oldconfig" for spotting new= config > > > > > options that default to enabled. > > > > > > > > Yes it will be interesting to see what you find there. My results on > > > > nokia_rx51 were something like this: > > > > > > > > default > > > > arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 > > > > rodata +10989.0 text +109846.0 > > > > > > > > without ebbr > > > > arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 > > > > rodata +5333.0 text +29712.0 > > > > > > > > with various other things: > > > > CONFIG_OF_LIBFDT_ASSUME_MASK=3D7 > > > > # CONFIG_OF_TRANSLATE is not set > > > > # CONFIG_SIMPLE_BUS is not set > > > > # CONFIG_TI_SYSC is not set > > > > # CONFIG_CMD_FDT is not set > > > > > > > > arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rod= ata > > > > +3274.0 text +15552.0 > > > > > > > > (Mark, in the same email:) > > > > > > FIT simply isn't fit for purpose (pun intended). It only reall= y works > > > > > > for booting Linux, and forces people to combine u-boot, kernel, > > > > > > initial ramdisk and other firmware components into a single ima= ge. > > > > > > That is really undesirable as: > > > > > > - This makes it sigificantly harder to update individual compon= ents of > > > > > > such an image. Making it hard to update a kernel is obviousl= y a > > > > > > serious security risk. > > > > > > - This makes it impossible to build an OS install image that wo= rks om > > > > > > multiple boards/SoCs. > > > > > > > > > > > > I would really like to understand this better. The whole thing is a > > > > complete mystery to me. > > > > > > > > Firstly I have sometimes fiddled with booting other OSes using FIT.= It > > > > seemed OK. I can't see why it only works with Linux. > > > > > > Well, you could of course rework the boot flow of other OSes such that > > > booting them includes some sort of FIT if you really wanted to. I But > > > an OS like OpenBSD comes with its own bootloader that is essential in > > > the boot flow. On OpenBSD armv7/arm64/riscv64 it adds some essential > > > properties to the device tree. Besides, the kernel itself relies on a > > > valid EFI memory map. > >=20 > > (thanks for taking the time to reply with so much detail) > >=20 > > That's news to me; when did that happen? Anyway, I doubt that adds a > > lot of code. >=20 > Shortly after EFI_LOADER support was added to U-Boot and there was a > clear consensus that EFI_LOADER support was going to be enabled by > default on armv7 and armv8 targets. My initial commit of the EFI > bootloader for armv7 is from May 2016. >=20 > > > > Secondly, I don't expect that U-Boot itself would be in the FIT. > > > > > > So the FIT would only contain the OS kernel and other OS components? > > > What about the FIT that is used on some arm64 platforms to combine > > > U-Boot and TF-A? I guess you can have multiple FITs... > > > > > > > Thirdly, do you really want the kernel and initrd to be separate? At > > > > least in the systems I have used, they are built together, even hav= ing > > > > the same name, e.g.: > > > > > > > > initrd.img-5.10.40-1rodete1-amd64 > > > > System.map-5.10.40-1rodete1-amd64 > > > > vmlinuz-5.10.28-1rodete2-amd64 > > > > > > I don't really use Linux on these platforms. But I'd expect the > > > normal package management tools of my Linux distribution to build > > > those as necessary and place them in the root file system where the > > > bootloader picks them up. And as a distro developer, I'd like to have > > > the same approach work on all Linux systems, regardless the specific > > > firmware they're running (EDK2, U-Boot or something completely > > > different). Ideally that wouldn't even depend on the architecture. > > > > > > Now Armbian takes a different approach, and does treat most systems > > > they provide as special snowflakes, providing flash images for each > > > board. But that doesn't scale and makes for a fairly crappy user > > > experience. They don't always support booting a mainline kernel. And > > > updating the kernel often requires installing special packages. > >=20 > > I don't think it is a requirement that things have to be special > > snowflakes. There are a few common boot flows to support and we can > > put that support in U-Boot and in userspace, without needing to make > > everything special. > >=20 > > > > > > > Finally, for the firmware components, do you mean system firmware? = If > > > > so, I would expect it to be more convenient to distribute updates to > > > > that separately, although I suppose they could be combined with the > > > > kernel if the combinatorial explosion can be contained. What is the > > > > problem, exactly? (If you mean peripheral firmware, I would expect > > > > fwupd to handle that.) > > > > > > I guess I mean system firmware. Essentially everything that runs on > > > the system before my OS bootloader runs. So for me, U-Boot is part of > > > the system firmware even if it sometimes happens to live on removable > > > media. > > > > > > > What exactly is impossible? Can you please be more specific? > > > > > > So let me explain what we want for OpenBSD. We really want a uniform > > > user experience across platforms, and don't want to maintain different > > > codepaths for special snowflake platforms that might exist for a > > > specific architecture. > > > > > > Installing OpenBSD on a machine should be as simple as dd'ing the > > > installer to some boot media, plugging it in and powering the machine > > > on. Now this is somewhat tricky to achieve on some hardware targetted > > > by U-Boot as they don't come with usable system firmware on the board > > > itself. But on those boards you can mostly get away with having > > > U-Boot on uSD or eMMC and the OS installer on USB. > > > > > > Updating the OpenBSD kernel should be as simple as copying the kernel > > > to /bsd. Since the root filesystem uses the UFS/FFS filesystem, this > > > means that whatever we use as a bootloader must be able to read from > > > that filesystem. To make sure the kernel is properly seeded with > > > entropy, the OpenBSD bootloader has some additional tricks up its > > > sleeve. It will replace a special segment in the kernel with random > > > data before handing control to the kernel. On platforms that support > > > it, it will try to use a firmware-provided RNG to do this (and EFI > > > supports this) but also mix in some random data from a file on the > > > UFS/FFS filesystem. It will actually mark that file as "used" after > > > reading it to throw a warning when the file is reused when the machine > > > is rebooted (it should have been filled with fresh new entropy). So > > > you really need to use the OpenBSD bootloader instead loading an > > > OpenBSD kernel directly from system firmware. > > > > > > Updating the OpenBSD bootloader should be as simple as running > > > installboot(8) from within the OS. > > > > > > This all works on pretty much any architecture that OpenBSD supports. > > > And right now, thanks to EFI_LOADER support in U-Boot, we have a > > > nearly uniform boot flow on amd64, arm64, armv7 and riscv64. > >=20 > > OK I see. Really it sounds like you have a pre-kernel loader. The > > functionality (some fresh random data) could just as easily be > > provided by U-Boot directly, with vastly less code and complexity. But > > I do understand that trying to design across a whole system is a pain, > > and it is attractive to try to use what hooks exist already to do what > > you want. >=20 > What do you mean with vastly less code and complexity. At this point > 70% of the OpenBSD bootloader code is shared between most of the > architectures OpenBSD runs on (alpha, amd64, arm64, armv7, hppa, i386, > powerpc, riscv64, sh, sparc64). And on platforms that support UEFI > (amd64, arm64, armv7 and riscv64) this is closer to 95% shared code. >=20 > Having OS-dependent code in U-Boot doesn't work. FreeBSD tried that > with the U-Boot API. It was never enabled by default, and got broken > all the time. That's good to know and I believe validates why we want EFI_LOADER as much as possible. This is a good example of how real world OSes can make use of this to reduce their own overhead. And I think this also shows why we need EFI_LOADER, the U-boot API was never being sufficiently tested and most importantly never had anyone championing it's usage. That's not the case with the EFI API. > > How do you do verified boot? >=20 > We don't. I don't think it makes sense for an Open Source OS where > people like to tinker with things. And it gets in the way of some of > our own security features. OpenBSD relinks the kernel upon every boot > as a defence against attacks that depend on the kernel address space > layout. Doing that in an environment where all code needs to be > signed is a big challenge. >=20 > There is a comany that has products based on OpenBSD. They do > verified boot. I'm not really familliar with the details, but > presumably they turned off address space randomization and I believe > it is based on EFI_LOADER support. Patrick Wildt contributed patches > to implement this to U-Boot before the Linaro folks did their > full-blown UEFI-based implementation. That's good to know, thanks! --=20 Tom --kawfBpz4YELAgyI3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmDfcl8ACgkQFHw5/5Y0 tyxbHwwAjW+fJNdIgfC8RcorXNd3EjqirYT4Q/mhSK2Z4Rk66JMLnbeTtsDvmVUI fx9M5jNNPrkwgaaG68S0SFDKVRK/uiP5X1GawDe0+kpcvWTcOcX0daUAhoCTR4oA iAYt8GGJ/sSsukIv7HuKGTMdA1YMDYpmaeKZgdG8yR4PFEYsFeie3Em7GJFr3OF+ Fee5+PGjx5D0MQW3adVt+H9Xhgoh3cz9Ax7Hwjt42Zf0zEvBFjBCb90M8vZCDI7W 5xjoS7Jwv4yAKS4fGUSCgYci6Sjrad13iDuAZeA2vM1dfgsuT3W/534AjTmFhIV4 wTbPok1j73c8h+4BvKy+5CgbVnc8p0pETqk2ziWVJOF+CRDayIwBPJeOmp19Ytal YSwYUFSL4C7Ni/fSIijqn+t4R9+f4hNn88vuT6O1FheEmDP5Fn4Sk4NEKY4LaWcd i5SkkA2mFCHdNkUrPIQZCkqSW+zxics0DS5ts0mQ/5wga8tEjnD3NT5Pjjm+KpTY znhFiRPN =zAK4 -----END PGP SIGNATURE----- --kawfBpz4YELAgyI3--