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 305B58034C for ; Thu, 23 Mar 2017 09:54:50 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 91B7AEC0A1; Thu, 23 Mar 2017 16:54:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 91B7AEC0A1 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 91B7AEC0A1 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-84.phx2.redhat.com [10.3.116.84]) by smtp.corp.redhat.com (Postfix) with ESMTP id A9EDB7FCC2; Thu, 23 Mar 2017 16:54:48 +0000 (UTC) To: Brijesh Singh References: <149013076154.27235.10725020825643505862.stgit@brijesh-build-machine> <149013077498.27235.15379321048646409782.stgit@brijesh-build-machine> <15681e6f-dd58-957a-067f-f1036b31c62d@redhat.com> Cc: "Kinney, Michael D" , "Justen, Jordan L" , edk2-devel@ml01.01.org, "Gao, Liming" , brijesh.singh@amd.com, Leo Duran , Tom Lendacky From: Laszlo Ersek Message-ID: <2b2716f5-69f9-de81-ac64-246c8e5a49df@redhat.com> Date: Thu, 23 Mar 2017 17:54:46 +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: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 23 Mar 2017 16:54:50 +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: Thu, 23 Mar 2017 16:54:50 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/23/17 17:48, Brijesh Singh wrote: > On Thu, Mar 23, 2017 at 11:16 AM, Laszlo Ersek wrote: > >> On 03/23/17 16:05, Brijesh Singh wrote: >>> On Wed, Mar 22, 2017 at 3:20 PM, Laszlo Ersek wrote: >> >>>> In the below logic, which branch exactly (to NoSev) will be taken on >>>> Intel processors? >>>> >>>> >>> The below check should branch to NoSev on Intel processor >>> (please note that 0x8000_001F is new leaf and may not exist on older AMD >>> processor hence we will also branch to NoSev on AMD processor which does >>> not support this leaf) >>> >>> *; Check if we have a valid (0x8000_001F) CPUID leaf >>> **mov eax, 0x80000000 >>> **cpuid >>> **cmp eax, 0x8000001f >>> **jl NoSev* >> >> Yes, I figured that maybe this "highest supported cpuid leaf" check >> would catch Intel processors. >> >> But, what prevents a future Intel processor from exposing such a high >> CPUID leaf, for a completely different purpose? Should we not perform >> some kind of vendor-id check? (I'm quite unfamiliar with CPUID, as you >> can tell, I just seem to recall a comment (from Liming perhaps?) for one >> of your MdeModulePkg patches, where he said that directly using a >> software-defined CPUID leaf (?) would not be portable across all CPU >> vendors, or some such.) >> >> > > I had similar question in my mind. Before creating the patch I checked > with > AMD architecture team. The response was, CPUID 0x8000_001F definition > is fixed for x86 architecture. So, if Intel ever decides to report this > CPUID leaf > then it will comply to exact same definition. OK, this looks safe then. Can you please add it as a comment to the code? Thanks! Laszlo > > I think vendor check is weak, e.g user could change the vendor string > through the qemu property which will break this loop. Because of this, I > wanted > to avoid any kind of vendor string or hypervisor defined CPUID checks > inside the code. > > BTW, in my previous patches I was using KVM software defined CPUID leaf and > I > got rid of it because hypervisor's are flexiable to define that CPUID in > whatever > way they want. > > -Brijesh >