> 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.
