From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C18F5802B8 for ; Wed, 22 Mar 2017 13:20:35 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 20A5B42BCB; Wed, 22 Mar 2017 20:20:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 20A5B42BCB Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 20A5B42BCB Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-105.phx2.redhat.com [10.3.116.105]) by smtp.corp.redhat.com (Postfix) with ESMTP id EFECC6046C; Wed, 22 Mar 2017 20:20:33 +0000 (UTC) To: Brijesh Singh , michael.d.kinney@intel.com, jordan.l.justen@intel.com, edk2-devel@ml01.01.org, liming.gao@intel.com References: <149013076154.27235.10725020825643505862.stgit@brijesh-build-machine> <149013077498.27235.15379321048646409782.stgit@brijesh-build-machine> Cc: brijesh.singh@amd.com, leo.duran@amd.com, Thomas.Lendacky@amd.com From: Laszlo Ersek Message-ID: <15681e6f-dd58-957a-067f-f1036b31c62d@redhat.com> Date: Wed, 22 Mar 2017 21:20:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149013077498.27235.15379321048646409782.stgit@brijesh-build-machine> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 22 Mar 2017 20:20:36 +0000 (UTC) Subject: Re: [RFC PATCH v2 02/10] OvmfPkg/ResetVector: add memory encryption mask when SEV is enabled X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:20:36 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/21/17 22:12, Brijesh Singh wrote: > SEV guest VMs have the concept of private and shared memory. Private > memory is encrypted with the guest-specific key, while shared memory > may be encrypted with hypervisor key. Certain types of memory (namely > instruction pages and guest page tables) are always treated as private > memory by the hardware. The C-bit in PTE indicate whether the page is > private or shared. The C-bit position for the PTE can be obtained from > CPUID Fn8000_001F[EBX]. > > When SEV is active, the BIOS is pre-encrypted by the Qemu launch sequence, > we must set the C-bit when building the page table for 64-bit or 32-bit > PAE mode. > > Signed-off-by: Brijesh Singh > --- > OvmfPkg/ResetVector/Ia32/PageTables64.asm | 62 +++++++++++++++++++++++++++++ > 1 file changed, 62 insertions(+) > > diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm b/OvmfPkg/ResetVector/Ia32/PageTables64.asm > index 6201cad..7083f6b 100644 > --- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm > +++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm > @@ -37,6 +37,47 @@ BITS 32 > PAGE_READ_WRITE + \ > PAGE_PRESENT) > > +; Check if Secure Encrypted Virtualization (SEV) feature > +; > +; If SEV is enabled, then EAX will contain Memory encryption bit position I suggest to say, in the comment here, that a valid eax will be at least 32, and 0 on "SEV unavailable or disabled". > +; > +CheckSevFeature: > + xor eax, eax I think this xor may not be necessary (there's no path out of this function that wouldn't set eax intentionally), but it doesn't hurt. (Sorry if I should have noticed this in v1 -- there's no need to resubmit just because of this.) In the below logic, which branch exactly (to NoSev) will be taken on Intel processors? > + > + ; Check if we have a valid (0x8000_001F) CPUID leaf > + mov eax, 0x80000000 > + cpuid > + cmp eax, 0x8000001f > + jl NoSev > + > + ; Check for memory encryption feature: > + ; CPUID Fn8000_001F[EAX] - Bit 1 > + ; > + mov eax, 0x8000001f > + cpuid > + bt eax, 1 > + jnc NoSev > + > + ; Check if memory encryption is enabled > + ; MSR_0xC0010131 - Bit 0 (SEV enabled) > + ; MSR_0xC0010131 - Bit 1 (SEV-ES enabled) > + mov ecx, 0xc0010131 > + rdmsr > + bt eax, 0 > + jnc NoSev Do we need to check SEV-ES specifically? bit1 is not tested. > + > + ; Get pte bit position to enable memory encryption > + ; CPUID Fn8000_001F[EBX] - Bits 5:0 > + ; > + mov eax, ebx > + and eax, 0x3f > + jmp SevExit > + > +NoSev: > + xor eax, eax > + > +SevExit: > + OneTimeCallRet CheckSevFeature > > ; > ; Modified: EAX, ECX Can you please update (or delete) this comment? I think EBX and EDX may be modified too. > @@ -60,18 +101,38 @@ clearPageTablesMemoryLoop: > mov dword[ecx * 4 + PT_ADDR (0) - 4], eax > loop clearPageTablesMemoryLoop > > + ; Check if its SEV-enabled Guest > + ; > + OneTimeCall CheckSevFeature > + xor edx, edx > + test eax, eax > + jz SevNotActive > + > + ; If SEV is enabled, Memory encryption bit is always above 31 > + mov ebx, 32 > + sub ebx, eax I apologize if I'm mistaken, but I think we want to decrease eax with 32 (i.e., with ebx), so that we get the C bit's position within the high address (= more significant) DWORD of the PTE. But, isn't the argument order for SUB reversed? To me the above seems to imply EBX := EBX - EAX, which appears wrong. ... I think we could even say sub eax, 32 The rest looks good to me. Thanks Laszlo > + bts edx, eax > + > +SevNotActive: > + > + ; > ; > ; Top level Page Directory Pointers (1 * 512GB entry) > ; > mov dword[PT_ADDR (0)], PT_ADDR (0x1000) + PAGE_PDP_ATTR > + mov dword[PT_ADDR (4)], edx > > ; > ; Next level Page Directory Pointers (4 * 1GB entries => 4GB) > ; > mov dword[PT_ADDR (0x1000)], PT_ADDR (0x2000) + PAGE_PDP_ATTR > + mov dword[PT_ADDR (0x1004)], edx > mov dword[PT_ADDR (0x1008)], PT_ADDR (0x3000) + PAGE_PDP_ATTR > + mov dword[PT_ADDR (0x100C)], edx > mov dword[PT_ADDR (0x1010)], PT_ADDR (0x4000) + PAGE_PDP_ATTR > + mov dword[PT_ADDR (0x1014)], edx > mov dword[PT_ADDR (0x1018)], PT_ADDR (0x5000) + PAGE_PDP_ATTR > + mov dword[PT_ADDR (0x101C)], edx > > ; > ; Page Table Entries (2048 * 2MB entries => 4GB) > @@ -83,6 +144,7 @@ pageTableEntriesLoop: > shl eax, 21 > add eax, PAGE_2M_PDE_ATTR > mov [ecx * 8 + PT_ADDR (0x2000 - 8)], eax > + mov [(ecx * 8 + PT_ADDR (0x2000 - 8)) + 4], edx > loop pageTableEntriesLoop > > ; > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel >