Message ID | 20230802154831.2147855-1-ardb@kernel.org |
---|---|
Headers | show |
Series | efi/x86: Avoid bare metal decompressor during EFI boot | expand |
On Sat, 5 Aug 2023 at 16:41, Borislav Petkov <bp@alien8.de> wrote: > > On Wed, Aug 02, 2023 at 05:48:08PM +0200, Ard Biesheuvel wrote: > > Update the x86 boot path to avoid the bare metal decompressor when > > booting via the EFI stub. The bare metal decompressor inherits the > > loader's 1:1 mapping of DRAM when entering in 64-bit mode, and assumes > > that all of it is mapped read/write/execute, which will no longer be the > > case on systems built to comply with recently tightened logo > > requirements (*). > > > > Changes since v7 [10]: > > My Zen1 box fails booting with those. It is related to memory encryption > because if I supply "mem_encrypt=off", it boots. > > The failure is (typing it off from the video from the BMC): > > /dev/root: Can't open blockdev > VFS: Cannot open root device "UUID=..." > Please append a correct "root=" boot option; > ... > > I'll bisect now but it is pretty clear which one is the culprit. > So this is the host booting, right? So is the position of the C bit perhaps getting detect incorrectly?
On Sat, 5 Aug 2023 at 23:07, Borislav Petkov <bp@alien8.de> wrote: > > On Sat, Aug 05, 2023 at 07:37:17PM +0200, Ard Biesheuvel wrote: > > So this is the host booting, right? > > Yes. > > > So is the position of the C bit perhaps getting detect incorrectly? > > I don't know yet. But the evildoer is someone else: > > 02d47ce2ae02 ("x86/head_64: Store boot_params pointer in callee save register") > > after bisection. More staring later as to why... > How bizarre. But that was a bonus patch anyway, so we could just drop it for now.
On Sun, 6 Aug 2023 at 00:19, Ard Biesheuvel <ardb@kernel.org> wrote: > > On Sat, 5 Aug 2023 at 23:07, Borislav Petkov <bp@alien8.de> wrote: > > > > On Sat, Aug 05, 2023 at 07:37:17PM +0200, Ard Biesheuvel wrote: > > > So this is the host booting, right? > > > > Yes. > > > > > So is the position of the C bit perhaps getting detect incorrectly? > > > > I don't know yet. But the evildoer is someone else: > > > > 02d47ce2ae02 ("x86/head_64: Store boot_params pointer in callee save register") > > > > after bisection. More staring later as to why... > > > > How bizarre. > > But that was a bonus patch anyway, so we could just drop it for now. I suspect this should fix the issue: --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -110,6 +110,7 @@ SYM_CODE_START_NOALIGN(startup_64) * programmed into CR3. */ leaq _text(%rip), %rdi + movq %r15, %rsi call __startup_64 /* Form the CR3 value being sure to include the CR3 modifier */
On Sun, Aug 06, 2023 at 12:05:25PM +0200, Ard Biesheuvel wrote: > I suspect this should fix the issue: > > --- a/arch/x86/kernel/head_64.S > +++ b/arch/x86/kernel/head_64.S > @@ -110,6 +110,7 @@ SYM_CODE_START_NOALIGN(startup_64) > * programmed into CR3. > */ > leaq _text(%rip), %rdi > + movq %r15, %rsi > call __startup_64 Yah, I was suspecting we're not passing boot_params properly somewhere. Aaand there it is. So yes, that fixes it. Lemme know when you've refreshed your branch so that I can continue testing. Thx.
On Sun, 6 Aug 2023 at 12:17, Borislav Petkov <bp@alien8.de> wrote: > > On Sun, Aug 06, 2023 at 12:05:25PM +0200, Ard Biesheuvel wrote: > > I suspect this should fix the issue: > > > > --- a/arch/x86/kernel/head_64.S > > +++ b/arch/x86/kernel/head_64.S > > @@ -110,6 +110,7 @@ SYM_CODE_START_NOALIGN(startup_64) > > * programmed into CR3. > > */ > > leaq _text(%rip), %rdi > > + movq %r15, %rsi > > call __startup_64 > > Yah, I was suspecting we're not passing boot_params properly somewhere. > Aaand there it is. > > So yes, that fixes it. > > Lemme know when you've refreshed your branch so that I can continue > testing. > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=x86-efistub-cleanup-v9
On Sun, Aug 06, 2023 at 12:21:36PM +0200, Ard Biesheuvel wrote:
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=x86-efistub-cleanup-v9
Ok, boots on all my machines.
Please send it once again to the ML so that I can pick it up and have
Link: tags refer to an official submission.
Thx.