On Tue, 24 Dec 2019 at 08:47, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > > > > On Dec 24, 2019, at 3:38 PM, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > > > On Tue, 24 Dec 2019 at 03:15, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > >> > >>> On Mon, Dec 23, 2019 at 7:23 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > >>> > >>> The EFI mixed mode entry code goes through the ordinary startup_32() > >>> routine before jumping into the kernel's EFI boot code in 64-bit > >>> mode. The 32-bit startup code must be entered with paging disabled, > >>> but this is not documented as a requirement for the EFI handover > >>> protocol, and so we should disable paging explicitly when entering > >>> the kernel from 32-bit EFI firmware. > >> > >> Does this mean that EFI is allowed to call the kernel with paging on > >> but the text identity-mapped? > > > > Yes. This is explicitly mentioned in the spec. Paging may be on or > > off, but all memory must be mapped 1:1 > > > >> Have you seen this happen in practice? > >> > > > > Yes. GRUB and OVMF both implement the EFI handover protocol, but OVMF > > doesn't disable paging before calling the 32-bit entry point, and so > > it explodes in startup_32(). GRUB calls the EFI handover entrypoint > > with paging disabled, and so then everything works fine. > > > >> If the kernel is entered with paging on and the text not > >> identity-mapped, this is going to blow up badly. > >> > > > > Not just text: all of system memory is guaranteed to be 1:1 mapped if > > paging is on when entering the kernel from EFI, so this should be > > safe. > > Note that this change only affects mixed mode configurations that use > > OVMF instead of GRUB. > > > > We are using OVMF/qemu in kernelCI for test coverage of the EFI stub > > for all architectures, and this is the missing puzzle piece to get it > > working in x86 mixed mode as well. > > Sounds good to me, then. > > I admit to being a bit confused, since I would have sworn that I’ve personally tested mixed mode with OVMF. Interesting that you should say that. I thought exactly the same, but after noticing that it didn't work, I went back years testing old kernels and old builds of OVMF, and no combination that I tried would actually work without a change like the one in this patch. This is using both KVM and emulation, so it doesn't seem likely that this is caused by a change in QEMU.
