lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 10 Sep 2018 20:08:02 +0200 From: Ard Biesheuvel <ard.biesheuvel@...aro.org> To: Olof Johansson <olof@...om.net> Cc: Scott Branden <scott.branden@...adcom.com>, Grant Likely <grant.likely@...retlab.ca>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>, Arnd Bergmann <arnd@...db.de>, Broadcom Kernel Feedback List <bcm-kernel-feedback-list@...adcom.com>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Leif Lindholm <leif.lindholm@...aro.org>, Alexander Graf <agraf@...e.de> Subject: Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER On 10 September 2018 at 20:01, Olof Johansson <olof@...om.net> wrote: > On Mon, Sep 10, 2018 at 10:53 AM, Scott Branden > <scott.branden@...adcom.com> wrote: >> Olof/All, >> >> >> On 18-09-04 03:13 AM, Grant Likely wrote: >>> >>> Hey folks. More comments below, but the short answer is I really don't >>> see what the problem is. Distros cannot easily support platforms that >>> require a dtb= parameter, and so they probably won't. They may or may >>> not disable 'dtb=', depending on whether they see it as valuable for >>> debug. >>> >>> Vertically integrated platforms are a different beast. We may strongly >>> recommend firmware provides the dtb for all the mentioned good >>> reasons, but they still get to decide their deployment methodology, >>> and it is not burdensome for the kernel to keep the dtb= feature that >>> they are using. >>> >>> On Tue, Sep 4, 2018 at 7:24 AM Ard Biesheuvel <ard.biesheuvel@...aro.org> >>> wrote: >>>> >>>> On 2 September 2018 at 04:54, Olof Johansson <olof@...om.net> wrote: >>>>> >>>>> On Thu, Aug 30, 2018 at 9:23 AM, Ard Biesheuvel >>>>> <ard.biesheuvel@...aro.org> wrote: >>>>>> >>>>>> On 30 August 2018 at 17:06, Olof Johansson <olof@...om.net> wrote: >>>>>>> >>>>>>> On Wed, Aug 29, 2018 at 10:54 PM, Ard Biesheuvel >>>>>>> <ard.biesheuvel@...aro.org> wrote: >>>>>>>> >>>>>>>> On 29 August 2018 at 20:59, Scott Branden >>>>>>>> <scott.branden@...adcom.com> wrote: >>>>>>>>> >>>>>>>>> Hi Olof, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 18-08-29 11:44 AM, Olof Johansson wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On Wed, Aug 29, 2018 at 10:21 AM, Scott Branden >>>>>>>>>> <scott.branden@...adcom.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Enable EFI_ARMSTUB_DTB_LOADER to add support for the dtb= command >>>>>>>>>>> line >>>>>>>>>>> parameter to function with efi loader. >>>>>>>>>>> >>>>>>>>>>> Required to boot on existing bootloaders that do not support >>>>>>>>>>> devicetree >>>>>>>>>>> provided by the platform or by the bootloader. >>>>>>>>>>> >>>>>>>>>>> Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add opt-in Kconfig option >>>>>>>>>>> for the >>>>>>>>>>> DTB loader") >>>>>>>>>>> Signed-off-by: Scott Branden <scott.branden@...adcom.com> >>>>>>>>>> >>>>>>>>>> Why did Ard create an option for this if it's just going be turned >>>>>>>>>> on >>>>>>>>>> in default configs? Doesn't make sense to me. >>>>>>>>>> >>>>>>>>>> It would help to know what firmware still is crippled and how >>>>>>>>>> common >>>>>>>>>> it is, since it's been a few years that this has been a requirement >>>>>>>>>> by >>>>>>>>>> now. >>>>>>>>> >>>>>>>>> Broadcom NS2 and Stingray in current development and production need >>>>>>>>> this >>>>>>>>> option in the kernel enabled in order to boot. >>>>>>>> >>>>>>>> And these production systems run mainline kernels in a defconfig >>>>>>>> configuration? >>>>>>>> >>>>>>>> The simply reality is that the DTB loader has been deprecated for a >>>>>>>> good reason: it was only ever intended as a development hack anyway, >>>>>>>> and if we need to treat the EFI stub provided DTB as a first class >>>>>>>> citizen, there are things we need to fix to make things works as >>>>>>>> expected. For instance, GRUB will put a property in the /chosen node >>>>>>>> for the initramfs which will get dropped if you boot with dtb=. >>>>>>>> >>>>>>>> Don't be surprised if some future enhancements of the EFI stub code >>>>>>>> depend on !EFI_ARMSTUB_DTB_LOADER. >>> >>> That's an odd statement to make. The DTB loader code is well contained >>> and with defined semantics... True, the semantics are "I DON'T BELIEVE >>> FIRMWARE", but it is still well defined. What scenario are you >>> envisioning where EFI_ARMSTUB_DTB_LOADER would be explicitly excluded? >>> >>> Conversely, the dtb= argument is an invaluable debug tool during >>> development. As Olof has already said, there are a lot of embedded >>> deployments where there is no desire for grub or any other >>> intermediary loader. >>> >>>>>>>> On UEFI systems, DTBs [or ACPI >>>>>>>> tables] are used by the firmware to describe itself and the >>>>>>>> underlying >>>>>>>> platform to the OS, and the practice of booting with DTB file images >>>>>>>> (taken from the kernel build as well) conflicts with that view. Note >>>>>>>> that GRUB still permits you to load DTBs from files (and supports >>>>>>>> more >>>>>>>> sources than just the file system the kernel Image was loaded from). >>>>>>> >>>>>>> Ard, >>>>>>> >>>>>>> Maybe a WARN() splat would be more useful as a phasing-out method than >>>>>>> removing functionality for them that needs to be reinstated through >>>>>>> changing the config? >>>>>>> >>>>>> We don't have any of that in the stub, and inventing new ways to pass >>>>>> such information between the stub and the kernel proper seems like a >>>>>> cart-before-horse kind of thing to me. The EFI stub diagnostic >>>>>> messages you get on the serial console are not recorded in the kernel >>>>>> log buffer, so they only appear if you actually look at the serial >>>>>> output. >>> >>> As an aside, they probably should be recorded. That is probably a >>> question for the UEFI USWG. Grub and the ARMSTUB could probably bodge >>> something together, but that would be non-standard. >>> >>>>> Ah yeah. I suppose you could do it in the kernel later if you detect >>>>> you've booted through EFI with dtb= on the command line though. >>>>> >>>>>>> Once the stub and the boot method is there, it's hard to undo as we >>>>>>> can see here. Being loud and warn might be more useful, and set a >>>>>>> timeline for hard removal (12 months?). >>>>>>> >>>>>> The dtb= handling is still there, it is just not enabled by default. >>>>>> We can keep it around if people are still using it. But as I pointed >>>>>> out, we may decide to make new functionality available only if it is >>>>>> disabled, and at that point, we'll have to choose between one or the >>>>>> other in defconfig, which is annoying. >>>>>> >>>>>>> Scott; an alternative for you is to do a boot wrapper that bundles a >>>>>>> DT and kernel, and boot that instead of the kernel image (outside of >>>>>>> the kernel tree). Some 32-bit platforms from Marvell use that. That >>>>>>> way the kernel will just see it as a normally passed in DT. >>>>>>> >>>>>> Or use GRUB. It comes wired up in all the distros, and let's you load >>>>>> a DT binary from anywhere you can imagine, as opposed to the EFI stub >>>>>> which can only load it if it happens to reside in the same file system >>>>>> (or even directory - I can't remember) as the kernel image. Note that >>>>>> the same reservations apply to doing that - the firmware is no longer >>>>>> able to describe itself to the OS via the DT, which is really the only >>>>>> conduit it has available on an arm64 system.. >>>>> >>>>> So, I've looked at the history here a bit, and dtb= support was >>>>> introduced in 2014. Nowhere does it say that it isn't a recommended >>>>> way of booting. >>>>> >>>>> There are some firmware stacks today that modify and provide a >>>>> runtime-updated devicetree to the kernel, but there are also a bunch >>>>> who don't. Most "real" products will want a firmware that knows how to >>>>> pass in things such as firmware environment variables, or MAC >>>>> addresses, etc, to the kernel, but not all of them need it. >>>>> >>>>> In particular, in a world where you want EFI to be used on embedded >>>>> platforms, requiring another bootloader step such as GRUB to be able >>>>> to reasonably boot said platforms seems like a significant and >>>>> unfortunate new limitation. Documentation/efi-stub.txt has absolutely >>>>> no indication that it is a second-class option that isn't expected to >>>>> be available everywhere. It doesn't really matter what _your_ >>>>> intention was around it, if those who use it never found out and now >>>>> rely on it. >>>>> >>>>> Unfortunately the way forward here is to revert 3d7ee348aa4127a. >> >> What's the path forward? Revert, defconfig change (this patch), or Kconfig >> default addition? > > Revert or Kconfig select, and a Kconfig select means that the option > is a dead one anyway so we might as well revert. > I disagree. Making it default y is fine by me, but please don't remove it. > Ard, do you have other fixes lined up or should we take the patch > through arm-soc? > I don't have any fixes but either way is fine.
Powered by blists - more mailing lists