Re: [Qemu-devel] [edk2] SetVirtualAddressMap and NX bit

Re: [Qemu-devel] [edk2] SetVirtualAddressMap and NX bit

[Laszlo Ersek]

(CC'ing qemu-devel)

On 07/16/13 17:12, Borislav Petkov wrote:> (this time after I subscribed to the ML)
>
> Hi guys,
>
> I've been playing with mapping EFI runtime regions in a topdown manner
> in Linux for purposes of using EFI in a kexec'ed kernel. For that I've
> been using EFI BIOS built from edk2 sources, svn revision r14165 from
> March this year in qemu.
>
> Here's the problem I'm observing: I'm handing down a prepared virtual
> map to SetVirtualAddressMap which has, a.o., the following
> EFI_RUNTIME_SERVICES_CODE mapping:
>
> [   47.371000] __lookup_address_in_pgd: address: 0xfffffffefdd6d000
> [   47.373000] __lookup_address_in_pgd:         pgd: 0x2a0d067 (0xffff88000009cff8)
> [   47.375000] __lookup_address_in_pgd:         pud: 0x7c818063 (0xffff880002a0dfd8)
> [   47.377000] __lookup_address_in_pgd:         pmd: 0x7c823063 (0xffff88007c818f70)
> [   47.379000] __lookup_address_in_pgd:         pte: 0x7fb12063 (0xffff88007c823b68)
>
> i.e., virtual address 0xfffffffefdd6d000 maps to physical address
> 0x7fb12063.
>
> After SetVirtualAddressMap finishes, the mapping has changed to
>
> [   47.383000] efi: efi_enter_virtual_mode: phys_efi_set_virtual_address_map succeeded
> [   47.385000] __lookup_address_in_pgd: address: 0xfffffffefdd6d000
> [   47.387000] __lookup_address_in_pgd:         pgd: 0x2a0d067 (0xffff88000009cff8)
> [   47.389000] __lookup_address_in_pgd:         pud: 0x7c818063 (0xffff880002a0dfd8)
> [   47.391000] __lookup_address_in_pgd:         pmd: 0x7c823063 (0xffff88007c818f70)
> [   47.393000] __lookup_address_in_pgd:         pte: 0x800000007fb12163 (0xffff88007c823b68)
>
> and the PTE has gotten the NX bit set even though it is part of
> EFI_RUNTIME_SERVICES_CODE mapping which should be executable.
>
> The same thing doesn't happen on baremetal, on the Dell box I have
> here.
>
> Is this known? Do I need to rebuild the OVMF.id BIOS?
>
> I appreciate any suggestions,

See the end of efi_enter_virtual_mode() (the call to
runtime_code_page_mkexec()), and

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a2172e25
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c083eb2
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4de0d4a6
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9cd2b07c

These give me the impression that NX gets set by default during
remapping, and that it is cleared afterwards only when some conditions
hold.

Maybe __supported_pte_mask is set up differently (x86_configure_nx()) in
the kexec'd kernel, when it runs on qemu.

Does TCG vs. KVM make a difference?

Just random ideas...

Thanks
Laszlo

Re: [Qemu-devel] [edk2] SetVirtualAddressMap and NX bit

[Borislav Petkov]

+ Matt.

On Wed, Jul 31, 2013 at 02:10:04PM +0200, Laszlo Ersek wrote:
> Just random ideas...

First of all, thanks for looking. You made me look too and find the fun
:-)

The fact that you guys didn't say "Oh yeah, we do this because... " but
simply shruggingly suggested ideas should've been enough to give me the
hint to look in our own backyard and maybe to permit the possibility of
the kernel doing something funny. And it does, indeed!

And for that you need to look at SetVirtualAddressMap() itself or
rather, how we call it:

phys_efi_set_virtual_address_map
|-> efi_call_phys_prelog
|-> efi_call_phys4(efi_phys.set_virtual_address_map
|-> efi_call_phys_epilog

Now guess what those pre- and epi- things do. Right:

efi_call_phys_prelog does early_code_mapping_set_exec(1) and
efi_call_phys_epilog does early_code_mapping_set_exec(0) and we end up
with that PTE's NX bit set:

before:
> [   47.379000] __lookup_address_in_pgd:         pte: 0x7fb12063 (0xffff88007c823b68)

after:
> [   47.393000] __lookup_address_in_pgd:         pte: 0x800000007fb12163 (0xffff88007c823b68)

What is still missing from the big picture is why the PTE in my
pagetable (not the kernel's pagetable) gets that bit set??

I mean, the EFI code is using pgd_offset_k() which looks at init_mm and
my PGD is a different one. And I guess the explanation for that would
also clarify why this doesn't happen on baremetal so probably it has
something to do with the nested page table thingy.

Oh well...

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--