Re: [PATCH v3 0/6] efi/x86: add support for generic EFI mixed mode boot

From: Arvind Sankar <nivedita@alum.mit.edu>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
	linux-efi <linux-efi@vger.kernel.org>,
	Hans de Goede <hdegoede@redhat.com>,
	the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [PATCH v3 0/6] efi/x86: add support for generic EFI mixed mode boot
Date: Sun, 1 Mar 2020 15:54:20 -0500	[thread overview]
Message-ID: <20200301205419.GA2116204@rani.riverdale.lan> (raw)
In-Reply-To: <CAKv+Gu87vexrXoofKdoFNEcr_Zw1dwe6pXz3DHhJ4NGZG=8SiA@mail.gmail.com>

On Sun, Mar 01, 2020 at 09:41:33PM +0100, Ard Biesheuvel wrote:
> On Sun, 1 Mar 2020 at 21:20, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Sun, 1 Mar 2020 at 21:02, Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Sun, 1 Mar 2020 at 21:00, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> > > >
> > > > On Sun, Mar 01, 2020 at 08:36:42PM +0100, Ard Biesheuvel wrote:
> > > > > On Sun, 1 Mar 2020 at 18:22, Arvind Sankar <nivedita@alum.mit.edu> wrote:
> > > > > >
> > > > > > On Sun, Mar 01, 2020 at 12:15:10PM -0500, Arvind Sankar wrote:
> > > > > > > What I'm doing is creating an x86-64 defconfig based on tip:efi/core,
> > > > > > > and then running it via
> > > > > > >
> > > > > > > $ qemu-system-x86_64 -cpu Haswell -pflash qemu/OVMF_64.fd \
> > > > > >                                                  ^^^^^^^
> > > > > > That OVMF_64.fd is incorrect copy/paste from a different run, the panic
> > > > > > case is using OVMF-mixed-mode-compat-section.fd.
> > > > > > >   -drive file=fat:rw:qemu/boot -nographic -m 3072
> > > > >
> > > > > Thanks for the patch. Interestingly, I don't even make it to the point
> > > > > where it crashes, and I end up in an ASSERT() in the firmware:
> > > > >
> > > > > ASSERT_EFI_ERROR (Status = Not Found)
> > > > > ASSERT /home/ardbie01/build/edk2/MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.c(347):
> > > > > !EFI_ERROR (Status)
> > > > >
> > > > > which appears to be a result of the fact that the memory map passed to
> > > > > SetVirtualAddressMap() does not cover some function pointer that gets
> > > > > converted in that code.
> > > > >
> > > > > I don't remember - does mixed mode even work in general with 3 GB of memory?
> > > >
> > > > Oh -- is there some option to enable debugging assertions? I did see
> > > > that it crashed somewhere inside SetVirtualMap (i.e. we called it and
> > > > it never returned).
> > > >
> > >
> > > The ASSERT()s are always active, but you don't see them if you don't
> > > expose the debugcon
> > >
> > > > For some reason, with nokaslr on the command line, I can't get this to
> > > > crash. All the addresses seem to be within 4Gb, so it ought to work, no?
> > >
> > > The issue is in the memory map we compile and send back to the firware
> > > - apparently, that ends up wrong for some reason.
> >
> > BTW I uploaded another version which uses Loadimage/Startimage (and
> > the .compat section) for mixed mode kernels passed to QEMU via the
> > command line
> >
> > https://people.linaro.org/~ard.biesheuvel/OVMF-mixed-mode-compat-section-cmdline.fd
> 
> I see this in the memory map
> 
> [    0.000000] efi: mem47: [Conventional Memory|   |  |  |  |  |  |  |
>  |   |WB|WT|WC|UC] range=[0x0000000100000000-0x000000013fffffff]
> (1024MB)
> 
> so it looks like qemu-system-x86_64 puts the memory in a weird place?
> Or is this expected?

Mine ended here:
[    0.000000] efi: mem45: [Memory Mapped I/O  |RUN|  |  |  |  |  |  |  |   |  |  |  |UC] range=[0x00000000ffc00000-0x00000000ffffffff] (4MB)
are you running with -m 3072 or more?

If you get memory mapped above 4Gb you will almost certainly crash in
the call to SetVirtualMemoryMap, but that's usually because the memmap
you pass in is above 4Gb and can't be accessed by the firmware at all.