From: Dave Young <dyoung@redhat.com>
To: Jan Hendrik Farr <kernel@jfarr.cc>
Cc: Ard Biesheuvel <ardb@kernel.org>,
Ard Biesheuvel <ardb@google.com>,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
Evgeniy Baskov <baskov@ispras.ru>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Jones <pjones@redhat.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Gerd Hoffmann <kraxel@redhat.com>,
Kees Cook <keescook@chromium.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"Goyal, Vivek" <vgoyal@redhat.com>
Subject: Re: [PATCH v2 00/15] x86/boot: Rework PE header generation
Date: Tue, 24 Oct 2023 16:31:27 +0800 [thread overview]
Message-ID: <CALu+AoSPqDOAhwoLCYkGRnE96X6r7rpOwERmse+=YQyA4OW2ug@mail.gmail.com> (raw)
In-Reply-To: <CALu+AoQbBr0RyBG6JxyKO81Ur=0uG_FxZq3=-QYhF2OxV7+F7g@mail.gmail.com>
On Tue, 24 Oct 2023 at 16:21, Dave Young <dyoung@redhat.com> wrote:
>
> On Tue, 24 Oct 2023 at 01:37, Jan Hendrik Farr <kernel@jfarr.cc> wrote:
> >
> > On 23 13:22:53, Ard Biesheuvel wrote:
> > > On Tue, 3 Oct 2023 at 04:03, Jan Hendrik Farr <kernel@jfarr.cc> wrote:
> > > >
> > > > On 12 09:00:51, Ard Biesheuvel wrote:
> > > > > From: Ard Biesheuvel <ardb@kernel.org>
> > > > >
> > > > > 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.
Hmm, another one is that ptrace needs to be disabled in some way,
anyway I think it is way too complicated, but I do not remember the
details, added Vivek in cc.
See this article: https://lwn.net/Articles/532778/
>
> Thanks
> Dave
prev parent reply other threads:[~2023-10-24 8:32 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 9:00 [PATCH v2 00/15] x86/boot: Rework PE header generation Ard Biesheuvel
2023-09-12 9:00 ` [PATCH v2 01/15] x86/efi: Drop EFI stub .bss from .data section Ard Biesheuvel
2023-09-12 9:00 ` [PATCH v2 02/15] x86/efi: Disregard setup header of loaded image Ard Biesheuvel
2023-09-12 9:00 ` [PATCH v2 03/15] x86/efi: Drop alignment flags from PE section headers Ard Biesheuvel
2023-09-12 9:00 ` [PATCH v2 04/15] x86/boot: Remove the 'bugger off' message Ard Biesheuvel
2023-09-12 9:00 ` [PATCH v2 05/15] x86/boot: Omit compression buffer from PE/COFF image memory footprint Ard Biesheuvel
2023-09-12 9:00 ` [PATCH v2 06/15] x86/boot: Drop redundant code setting the root device Ard Biesheuvel
2023-09-12 9:00 ` [PATCH v2 07/15] x86/boot: Grab kernel_info offset from zoffset header directly Ard Biesheuvel
2023-09-12 9:00 ` [PATCH v2 08/15] x86/boot: Drop references to startup_64 Ard Biesheuvel
2023-09-15 9:15 ` Ingo Molnar
2023-09-15 13:48 ` Ard Biesheuvel
2023-09-15 15:40 ` Ingo Molnar
2023-09-15 15:45 ` Ingo Molnar
2023-09-15 15:48 ` Ard Biesheuvel
2023-09-12 9:01 ` [PATCH v2 09/15] x86/boot: Set EFI handover offset directly in header asm Ard Biesheuvel
2023-09-12 9:01 ` [PATCH v2 10/15] x86/boot: Define setup size in linker script Ard Biesheuvel
2023-09-12 9:01 ` [PATCH v2 11/15] x86/boot: Derive file size from _edata symbol Ard Biesheuvel
2023-09-12 9:01 ` [PATCH v2 12/15] x86/boot: Construct PE/COFF .text section from assembler Ard Biesheuvel
2023-09-12 9:01 ` [PATCH v2 13/15] x86/boot: Drop PE/COFF .reloc section Ard Biesheuvel
2023-09-12 9:01 ` [PATCH v2 14/15] x86/boot: Split off PE/COFF .data section Ard Biesheuvel
2023-09-12 9:01 ` [PATCH v2 15/15] x86/boot: Increase section and file alignment to 4k/512 Ard Biesheuvel
2023-09-15 9:22 ` [PATCH v2 00/15] x86/boot: Rework PE header generation Ingo Molnar
2023-09-15 11:30 ` Ingo Molnar
2023-09-15 13:21 ` Ard Biesheuvel
2023-09-15 13:28 ` Ard Biesheuvel
2023-09-16 9:10 ` Ingo Molnar
2023-09-16 19:14 ` Ard Biesheuvel
2023-09-17 17:50 ` Ingo Molnar
2023-10-03 2:02 ` Jan Hendrik Farr
2023-10-23 11:22 ` Ard Biesheuvel
2023-10-23 17:35 ` Jan Hendrik Farr
2023-10-24 8:21 ` Dave Young
2023-10-24 8:31 ` Dave Young [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALu+AoSPqDOAhwoLCYkGRnE96X6r7rpOwERmse+=YQyA4OW2ug@mail.gmail.com' \
--to=dyoung@redhat.com \
--cc=ardb@google.com \
--cc=ardb@kernel.org \
--cc=baskov@ispras.ru \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kernel@jfarr.cc \
--cc=kraxel@redhat.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mjg59@srcf.ucam.org \
--cc=pjones@redhat.com \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).