From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V4VCO-0007g6-92 for qemu-devel@nongnu.org; Wed, 31 Jul 2013 08:08:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V4VCD-0000Yb-S3 for qemu-devel@nongnu.org; Wed, 31 Jul 2013 08:08:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48214) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V4VCD-0000YN-Gv for qemu-devel@nongnu.org; Wed, 31 Jul 2013 08:08:01 -0400 Message-ID: <51F8FE9C.6070207@redhat.com> Date: Wed, 31 Jul 2013 14:10:04 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <20130716151236.GF4402@pd.tnic> In-Reply-To: <20130716151236.GF4402@pd.tnic> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [edk2] SetVirtualAddressMap and NX bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Borislav Petkov Cc: edk2-devel@lists.sourceforge.net, "qemu-devel@nongnu.org" (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