From: Laszlo Ersek <lersek@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: edk2-devel@lists.sourceforge.net,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [edk2] SetVirtualAddressMap and NX bit
Date: Wed, 31 Jul 2013 14:10:04 +0200 [thread overview]
Message-ID: <51F8FE9C.6070207@redhat.com> (raw)
In-Reply-To: <20130716151236.GF4402@pd.tnic>
(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
next parent reply other threads:[~2013-07-31 12:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130716151236.GF4402@pd.tnic>
2013-07-31 12:10 ` Laszlo Ersek [this message]
2013-08-01 17:27 ` [Qemu-devel] [edk2] SetVirtualAddressMap and NX bit Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F8FE9C.6070207@redhat.com \
--to=lersek@redhat.com \
--cc=bp@alien8.de \
--cc=edk2-devel@lists.sourceforge.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).