On Tue, 24 Oct 2023 at 01:37, Jan Hendrik Farr <kernel@xxxxxxxx> wrote: > > On 23 13:22:53, Ard Biesheuvel wrote: > > On Tue, 3 Oct 2023 at 04:03, Jan Hendrik Farr <kernel@xxxxxxxx> wrote: > > > > > > On 12 09:00:51, Ard Biesheuvel wrote: > > > > From: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > > > > > > Now that the EFI stub boot flow no longer relies on memory that is > > > > executable and writable at the same time, we can reorganize the PE/COFF > > > > view of the kernel image and expose the decompressor binary's code and > > > > r/o data as a .text section and data/bss as a .data section, using 4k > > > > alignment and limited permissions. > > > > > > > > Doing so is necessary for compatibility with hardening measures that are > > > > being rolled out on x86 PCs built to run Windows (i.e., the majority of > > > > them). The EFI boot environment that the Linux EFI stub executes in is > > > > especially sensitive to safety issues, given that a vulnerability in the > > > > loader of one OS can be abused to attack another. > > > > > > This split is also useful for the work of kexecing the next kernel as an > > > EFI application. With the current EFI stub I have to set the memory both > > > writable and executable which results in W^X warnings with a default > > > config. > > > > > > What made this more confusing was that the flags of the .text section in > > > current EFI stub bzImages are set to > > > IMAGE_SCN_MEM_EXECUTE | IMAGE_SCN_MEM_READ. So if you load that section > > > according to those flags the EFI stub will quickly run into issues. > > > > > > I assume current firmware on x86 machines does not set any restricted > > > permissions on the memory. Can someone enlighten me on their behavior? > > > > > > > No current x86 firmware does not use restricted permissions at all. > > All memory is mapped with both writable and executable permissions, > > except maybe the stack. > > > > The x86 Linux kernel has been depending on this behavior too, up until > > recently (fixes are in -rc now for the v6.6 release). Before this, it > > would copy its own executable image around in memory. > > > > So EFI based kexec will need to support this behavior if it targets > > older x86 kernels, although I am skeptical that this is a useful > > design goal. > > I don't see this as an important goal either. > > > I have been experimenting with running the EFI stub code in user space > > all the way until ExitBootServices(). The same might work for UKI if > > it is layered cleanly on top of the EFI APIs (rather than poking into > > system registers or page tables under the hood). > > > > How this would work with signed images etc is TBD but I quite like the > > idea of running everything in user space and having a minimal > > purgatory (or none at all) if we can simply populate the entire > > address space while running unprivileged, and just branch to it in the > > kexec() syscall. I imagine this being something like a userspace > > helper that is signed/trusted itself, and gets invoked by the kernel > > to run EFI images that are trusted and tagged as being executable > > unprivileged. > > I've been experimenting with running EFI apps inside kernel space instead. > This is the more natural approach for signed images. Sure, a malicious EFI > app could do arbitrary stuff in kernel mode, but they're signed. On the other > hand running this entirely in user space would at least guarantee that the > system can not crash due to a misbehaving EFI app (at least until > ExitBootServices()). > > The question of whether or not to make this the job of a userspace helper that > is signed must have come up when kexec_file_load syscall was added. It would > have also been an option at the time to extend trust to a signed version of > the userspace kexec tool. > > Why was kexec_file_load created instead of restricting kexec_load to a signed > version of the kexec userspace tool? I think one of the reasons is that it is hard to handle dynamic linked libraries, not only the kexec-tools binary. Thanks Dave
