On Thu, 1 Feb 2024 at 17:23, Kevin Loughlin <kevinloughlin@xxxxxxxxxx> wrote: > > On Tue, Jan 30, 2024 at 11:32 PM Borislav Petkov <bp@xxxxxxxxx> wrote: > > > > On Mon, Jan 29, 2024 at 07:05:04PM +0100, Ard Biesheuvel wrote: > > > From: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > > > > Parse the mem_encrypt= command line parameter from the EFI stub if > > > CONFIG_ARCH_HAS_MEM_ENCRYPT=y, so that it can be passed to the early > > > boot code by the arch code in the stub. > > > > I guess all systems which do memory encryption are EFI systems anyway so > > we should not worry about the old ones... > > There is at least one non-EFI firmware supporting memory encryption: > Oak stage0 firmware [0]. However, I think Ard's patch seems simple > enough to adopt in non-EFI firmware(s) if needed. I merely wanted to > point out the existence of non-EFI memory encryption systems for > potential future cases (ex: reviewing more complex patches at the > firmware interface). > > [0] https://github.com/project-oak/oak/tree/main/stage0_bin > The second patch in this series actually implements the mem_encrypt= parsing for both EFI and non-EFI boot. I just broke this out in a separate patch because it affects architectures other than x86.
