qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [edk2] SetVirtualAddressMap and NX bit
Date: Wed, 31 Jul 2013 14:10:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130621 Thunderbird/17.0.7

(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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]