On Mon, 8 Apr 2024 at 14:37, Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Apr 08, 2024 at 08:49:21AM +0200, Ard Biesheuvel wrote:
From: Ard Biesheuvel ardb@kernel.org
[ Commit cd0d9d92c8bb46e77de62efd7df13069ddd61e7d upstream ]
The early SME/SEV code parses the command line very early, in order to decide whether or not memory encryption should be enabled, which needs to occur even before the initial page tables are created.
This is problematic for a number of reasons:
- this early code runs from the 1:1 mapping provided by the decompressor or firmware, which uses a different translation than the one assumed by the linker, and so the code needs to be built in a special way;
- parsing external input while the entire kernel image is still mapped writable is a bad idea in general, and really does not belong in security minded code;
- the current code ignores the built-in command line entirely (although this appears to be the case for the entire decompressor)
Given that the decompressor/EFI stub is an intrinsic part of the x86 bootable kernel image, move the command line parsing there and out of the core kernel. This removes the need to build lib/cmdline.o in a special way, or to use RIP-relative LEA instructions in inline asm blocks.
This involves a new xloadflag in the setup header to indicate that mem_encrypt=on appeared on the kernel command line.
Signed-off-by: Ard Biesheuvel ardb@kernel.org Signed-off-by: Borislav Petkov (AMD) bp@alien8.de Tested-by: Tom Lendacky thomas.lendacky@amd.com Link: https://lore.kernel.org/r/20240227151907.387873-17-ardb+git@google.com Signed-off-by: Ard Biesheuvel ardb@kernel.org
arch/x86/boot/compressed/misc.c | 15 +++++++++ arch/x86/include/uapi/asm/bootparam.h | 1 + arch/x86/lib/Makefile | 13 -------- arch/x86/mm/mem_encrypt_identity.c | 32 ++------------------ drivers/firmware/efi/libstub/x86-stub.c | 3 ++ 5 files changed, 22 insertions(+), 42 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c index f711f2a85862..c6136a1be283 100644 --- a/arch/x86/boot/compressed/misc.c +++ b/arch/x86/boot/compressed/misc.c @@ -357,6 +357,19 @@ unsigned long decompress_kernel(unsigned char *outbuf, unsigned long virt_addr, return entry; }
+/*
- Set the memory encryption xloadflag based on the mem_encrypt= command line
- parameter, if provided.
- */
+static void parse_mem_encrypt(struct setup_header *hdr) +{
int on = cmdline_find_option_bool("mem_encrypt=on");int off = cmdline_find_option_bool("mem_encrypt=off");if (on > off)hdr->xloadflags |= XLF_MEM_ENCRYPTION;+}
/*
- The compressed kernel image (ZO), has been moved so that its position
- is against the end of the buffer used to hold the uncompressed kernel
@@ -387,6 +400,8 @@ asmlinkage __visible void *extract_kernel(void *rmode, unsigned char *output) /* Clear flags intended for solely in-kernel use. */ boot_params->hdr.loadflags &= ~KASLR_FLAG;
parse_mem_encrypt(&boot_params->hdr);sanitize_boot_params(boot_params); if (boot_params->screen_info.orig_video_mode == 7) {This patch didn't apply on 6.6.y, so I applied it by hand, but it turns out there is no "boot_parms" on 6.6.y, so it breaks the build.
If you apply it by hand, it will be called boot_params_ptr, and that indeed does not exist yet on 6.6.y. The patch accounts for that.
However, it is bizarre that this fails to apply, given that I generated the patches from a tree based on 6.6.25. Does it conflict with something else you have queued up?
So I've dropped this one from the 6.6.y tree now, if you can submit it in a form that at least compiles, I'll take it :)
Happy to do so, but I'll need another base if 6.6.25 is not sufficient.