From mboxrd@z Thu Jan  1 00:00:00 1970
From: Brijesh Singh <brijesh.singh@amd.com>
Subject: Re: [RFC PATCH v2 12/32] x86: Add early boot support when running
 with SEV active
Date: Fri, 10 Mar 2017 10:35:30 -0600
Message-ID: <1fe1e177-f588-fe5a-dc13-e9fde00e8958@amd.com>
References: <148846752022.2349.13667498174822419498.stgit@brijesh-build-machine>
 <148846768878.2349.15757532025749214650.stgit@brijesh-build-machine>
 <20170309140748.tg67yo2jmc5ahck3@pd.tnic>
 <5d62b16f-16ef-1bd7-1551-f0c4c43573f4@redhat.com>
 <20170309162942.jwtb3l33632zhbaz@pd.tnic>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: <brijesh.singh@amd.com>, <simon.guinot@sequanux.org>,
	<linux-efi@vger.kernel.org>, <kvm@vger.kernel.org>, <rkrcmar@redhat.com>,
	<matt@codeblueprint.co.uk>, <linux-pci@vger.kernel.org>,
	<linus.walleij@linaro.org>, <gary.hook@amd.com>, <linux-mm@kvack.org>,
	<paul.gortmaker@windriver.com>, <hpa@zytor.com>, <cl@linux.com>,
	<dan.j.williams@intel.com>, <aarcange@redhat.com>, <sfr@canb.auug.org.au>,
	<andriy.shevchenko@linux.intel.com>, <herbert@gondor.apana.org.au>,
	<bhe@redhat.com>, <xemul@parallels.com>, <joro@8bytes.org>, <x86@kernel.org>,
	<peterz@infradead.org>, <piotr.luc@intel.com>, <mingo@redhat.com>,
	<msalter@redhat.com>, <ross.zwisler@linux.intel.com>, <dyoung@redhat.com>,
	<thomas.lendacky@amd.com>, <jroedel@suse.de>, <keescook@chromium.org>,
	<arnd@arndb.de>, <toshi.kani@hpe.com>, <mathieu.desnoyers@efficios.com>,
	<luto@kernel.org>, <devel@linuxdriverproject.org>, <bhel
To: Borislav Petkov <bp@suse.de>, Paolo Bonzini <pbonzini@redhat.com>
Return-path: <owner-linux-mm@kvack.org>
In-Reply-To: <20170309162942.jwtb3l33632zhbaz@pd.tnic>
Sender: owner-linux-mm@kvack.org
List-Id: linux-crypto.vger.kernel.org

Hi Boris and Paolo,

On 03/09/2017 10:29 AM, Borislav Petkov wrote:
> On Thu, Mar 09, 2017 at 05:13:33PM +0100, Paolo Bonzini wrote:
>> This is not how you check if running under a hypervisor; you should
>> check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx.  This in turn
>> tells you if leaf 0x40000000 is valid.
>
> Ah, good point, I already do that in the microcode loader :)
>
>         /*
>          * CPUID(1).ECX[31]: reserved for hypervisor use. This is still not
>          * completely accurate as xen pv guests don't see that CPUID bit set but
>          * that's good enough as they don't land on the BSP path anyway.
>          */
>         if (native_cpuid_ecx(1) & BIT(31))
>                 return *res;
>
>> That said, the main issue with this function is that it hardcodes the
>> behavior for KVM.  It is possible that another hypervisor defines its
>> 0x40000001 leaf in such a way that KVM_FEATURE_SEV has a different meaning.
>>
>> Instead, AMD should define a "well-known" bit in its own space (i.e.
>> 0x800000xx) that is only used by hypervisors that support SEV.  This is
>> similar to how Intel defined one bit in leaf 1 to say "is leaf
>> 0x40000000 valid".
>>
>>> +	if (eax > 0x40000000) {
>>> +		eax = 0x40000001;
>>> +		ecx = 0;
>>> +		native_cpuid(&eax, &ebx, &ecx, &edx);
>>> +		if (!(eax & BIT(KVM_FEATURE_SEV)))
>>> +			goto out;
>>> +
>>> +		eax = 0x8000001f;
>>> +		ecx = 0;
>>> +		native_cpuid(&eax, &ebx, &ecx, &edx);
>>> +		if (!(eax & 1))
>
> Right, so this is testing CPUID_0x8000001f_ECX(0)[0], SME. Why not
> simply set that bit for the guest too, in kvm?
>

CPUID_8000_001F[EAX] indicates whether the feature is supported.
CPUID_0x8000001F[EAX]:
  * Bit 0 - SME supported
  * Bit 1 - SEV supported
  * Bit 3 - SEV-ES supported

We can use MSR_K8_SYSCFG[MemEncryptionModeEnc] to check if memory encryption is enabled.
Currently, KVM returns zero when guest OS read MSR_K8_SYSCFG. I can update my patch sets
to set this bit for SEV enabled guests.

We could update this patch to use the below logic:

  * CPUID(0) - Check for AuthenticAMD
  * CPID(1) - Check if under hypervisor
  * CPUID(0x80000000) - Check for highest supported leaf
  * CPUID(0x8000001F).EAX - Check for SME and SEV support
  * rdmsr (MSR_K8_SYSCFG)[MemEncryptionModeEnc] - Check if SMEE is set


Paolo,

One question, do we need "AuthenticAMD" check when we are running under hypervisor ?
I was looking at qemu code and found that qemu exposes parameters to change the CPU
vendor id. The above check will fail if user changes the vendor id while launching
the SEV guest.

-Brijesh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933746AbdCJQgX (ORCPT <rfc822;w@1wt.eu>);
        Fri, 10 Mar 2017 11:36:23 -0500
Received: from mail-by2nam01on0060.outbound.protection.outlook.com ([104.47.34.60]:12061
        "EHLO NAM01-BY2-obe.outbound.protection.outlook.com"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S933582AbdCJQfz (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 10 Mar 2017 11:35:55 -0500
Authentication-Results: davemloft.net; dkim=none (message not signed)
 header.d=none;davemloft.net; dmarc=none action=none header.from=amd.com;
Subject: Re: [RFC PATCH v2 12/32] x86: Add early boot support when running
 with SEV active
To: Borislav Petkov <bp@suse.de>, Paolo Bonzini <pbonzini@redhat.com>
References: <148846752022.2349.13667498174822419498.stgit@brijesh-build-machine>
 <148846768878.2349.15757532025749214650.stgit@brijesh-build-machine>
 <20170309140748.tg67yo2jmc5ahck3@pd.tnic>
 <5d62b16f-16ef-1bd7-1551-f0c4c43573f4@redhat.com>
 <20170309162942.jwtb3l33632zhbaz@pd.tnic>
CC: <brijesh.singh@amd.com>, <simon.guinot@sequanux.org>,
        <linux-efi@vger.kernel.org>, <kvm@vger.kernel.org>,
        <rkrcmar@redhat.com>, <matt@codeblueprint.co.uk>,
        <linux-pci@vger.kernel.org>, <linus.walleij@linaro.org>,
        <gary.hook@amd.com>, <linux-mm@kvack.org>,
        <paul.gortmaker@windriver.com>, <hpa@zytor.com>, <cl@linux.com>,
        <dan.j.williams@intel.com>, <aarcange@redhat.com>,
        <sfr@canb.auug.org.au>, <andriy.shevchenko@linux.intel.com>,
        <herbert@gondor.apana.org.au>, <bhe@redhat.com>, <xemul@parallels.com>,
        <joro@8bytes.org>, <x86@kernel.org>, <peterz@infradead.org>,
        <piotr.luc@intel.com>, <mingo@redhat.com>, <msalter@redhat.com>,
        <ross.zwisler@linux.intel.com>, <dyoung@redhat.com>,
        <thomas.lendacky@amd.com>, <jroedel@suse.de>, <keescook@chromium.org>,
        <arnd@arndb.de>, <toshi.kani@hpe.com>,
        <mathieu.desnoyers@efficios.com>, <luto@kernel.org>,
        <devel@linuxdriverproject.org>, <bhelgaas@google.com>,
        <tglx@linutronix.de>, <mchehab@kernel.org>, <iamjoonsoo.kim@lge.com>,
        <labbott@fedoraproject.org>, <tony.luck@intel.com>,
        <alexandre.bounine@idt.com>, <kuleshovmail@gmail.com>,
        <linux-kernel@vger.kernel.org>, <mcgrof@kernel.org>, <mst@redhat.com>,
        <linux-crypto@vger.kernel.org>, <tj@kernel.org>,
        <akpm@linux-foundation.org>, <davem@davemloft.net>
From: Brijesh Singh <brijesh.singh@amd.com>
Message-ID: <1fe1e177-f588-fe5a-dc13-e9fde00e8958@amd.com>
Date: Fri, 10 Mar 2017 10:35:30 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <20170309162942.jwtb3l33632zhbaz@pd.tnic>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [165.204.77.1]
X-ClientProxiedBy: BN6PR03CA0054.namprd03.prod.outlook.com (10.173.137.16) To
 MWHPR12MB1613.namprd12.prod.outlook.com (10.172.56.14)
X-MS-Office365-Filtering-Correlation-Id: d75363cb-da1b-4b19-ef68-08d467d37e50
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081);SRVR:MWHPR12MB1613;
X-Microsoft-Exchange-Diagnostics: 1;MWHPR12MB1613;3:5X/Q/c2XKO3RkPgxYpelOygAlau2hpoGccl8tqASo9RqCMibqqdw54Fhaac4+glD1+KQPqqwg23VJaKtm0Hz2IrQp1kisd3lCp1gwlv3YxTQMG6FEvxTWmk+YQjMAhSOIXgeljUga7Rni9Ai1pMGG+MQENXDhrFYwvC2QBe9XXC3PE7ONQGRwoLwh3ly7TVgcwxRQDtouE1TKRXsjcDUoHPSglgUaj5sVdhD3BhGOHwPRpyuWANIDYjhU4/IU+1x6uuGt7kn+gTkHvtgNVNKLI7JOfe6J5AAMDyyl+Mo8UE=;25:l/7RGKD0B9TCD/8MzV5mrJoqQFvEFFj18Igt13zexEPWlGAa44Gu0Dha0ph5NoysryXt/SLlskclgw/uXmchtDq4Up+T6JKqBVYnsWfqttUKfZIPA704D2IRcdUoCprJtki/DDUSbwv2qPqYHSj8exdpbBgqZY8Xd9hlAjZUszM0zt63ugV2eidzfp08Zzv+V15KG05ymhcCO6mbyU1L/oA0OUd5TlDPoIqMbnRtI/BYt+fYrEQqan7EbycDKsDk4wZ2A7GkFTDSCAuL9v2bHklzRMjpylzaz4Rhd5e4XXzcuqNEC7el9d4b8IXTOE7JwD/l34BCKlqGGUlFhGNq5uDswUx6BTVKWut3uNrzBM7L0hV/5uvYKPhTil0WQN+qrbNf1l+rovfuUP5TahUqoD06XGaBbWvgWTDPKNvnZB9G81t4mLgKewIWLLIiSuEANSBzHjGVE7uG0/sCOslW0w==
X-Microsoft-Exchange-Diagnostics: 1;MWHPR12MB1613;31:fQkiYylxiVT+GpGGhp+CfKuWsFNVh70wN1/tFqHPIUzl13w/9Nwlr5NrCuXQkBu2DJM1KHahZcKnjIdZiPJDZjr/x5GU8jDFxUC64QQO1sb6nzdg4Stq8xpWq+tf+O8OZL63v72i0jzsysJ+Vah0WBBKPI/YjqgWXCOyOpTsaB0giJciOWLBw1f02vzvp+QpjhmwgOhBaiAH7zb1rcjUfuHEzWI1XSXKlvwt/thfSwum1Fac9x0e8U+FDco+7td6;20:DzNnzc9SZ7VXfBUo/iNIwf/kaOeWFRvmeoLxyotJYKaWNyt8m06Zqf3hLCeXoX5DQFMbdJ/UTgaWmr7QfwNTgfMIiFVoZqw+sM7Lh1G7bLOlBpGEkaXQv2XxIHolYNlESEG0pKp3Mb5j5Ja9VGeR76plZbL6P40zN/Y/TH2BYKFA7lssx7K1OCM6+XY8L/rnQVpkQB67jOkXtdcKf121tpsj+QBo5zpj3hhDony04e9JwUXvibEDIFZqLWX1wNINY/7S5VG+y/1zhgZQBs9hnwcDLibwhZqNCzAddsgWRLmKGUzcdXQmTPBh7/Nw00qKQbpm3eUIPKbi9RIT5nWEV8VBYC69TvcNOzqQVAaXax6DNPhnrWrlk3x18MEuGvpvERiE1c5xXm49wYeWmkVGFdbMjvNidLOe0kthp3yut00f7xEDEbLk97xUTPVqUflFE+r8HQ+nY2YoxuLqHF0gG5a6uM9GUEIVoeFOGwWXZ84XUXpd1jD4ypSCkSZNHtvX
X-Microsoft-Antispam-PRVS: <MWHPR12MB1613BC333FB5724A565D2631E5200@MWHPR12MB1613.namprd12.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(6072148);SRVR:MWHPR12MB1613;BCL:0;PCL:0;RULEID:;SRVR:MWHPR12MB1613;
X-Microsoft-Exchange-Diagnostics: 1;MWHPR12MB1613;4:ylBj7gPzO+G2u8AsoIUJZy0q6DsspQA9xdc97l6PpiD1Bttp2E0B4oW61c5usXuPjrNYLB5FqGzbILJ/ryqJVTcODYW0sfe2PnzPjYhzds87nXcXKAvaV5++XtwFjapaRcO1/p6nMPsIPZLfuqTc9UjFDhOdR806SB4BjFiS+lXss0Pi699N1PAJ/palPKSp+npyUm3WAt9k/O9TVnqe361yD/ze9A+IIx60014dnRFqMpuO7M7JE1gwhLnjs+yiF6ICMdIXaZA3SlFcIZR9DqWIDOyTsL0DNqIwVp0w1X1wzJUJSnWUlSj9y4fMiz7ZN7S5LMIZ4u3prZ6j5mblJ3tF2liF58b0aZblkXJtsf+01nCEPnMA//w75Dk3GG4zkcvvH9/S/UQYJzzld37XyPtYodstXI7xotwiKxh3WRTRn4/f+Wi352oCQyDSRIa+O8a2Ga91qEgZWGSLPj+jD92FAEt4TB7vz9SowtRSVpRTDhQM1b5AYCSgseH6O6wRWvcnWi3BRw2D1PEJsH7ECExPXBcYynGMdtY5TkOVY8Cr9YsfUL+bue897OeyTgg8Er+SuI+CwXGkezbgekmQXcVIj1TStBfu57u0bvT9Ho0eBgGO50IdxkMOr2BM6qGd
X-Forefront-PRVS: 02426D11FE
X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(39410400002)(39850400002)(39840400002)(39450400003)(39860400002)(377454003)(24454002)(57704003)(3846002)(7416002)(7406005)(2906002)(31686004)(6116002)(7366002)(54356999)(76176999)(93886004)(33646002)(81166006)(86362001)(31696002)(50466002)(305945005)(50986999)(83506001)(230700001)(189998001)(7736002)(65806001)(77096006)(65956001)(6246003)(36756003)(47776003)(6486002)(8676002)(5660300001)(25786008)(66066001)(23676002)(4001350100001)(6666003)(53936002)(38730400002)(2950100002)(54906002)(65826007)(42186005)(4326008)(90366009)(229853002)(64126003)(53546006)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:MWHPR12MB1613;H:[10.236.136.62];FPR:;SPF:None;MLV:sfv;LANG:en;
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjEyTUIxNjEzOzIzOlBUUUJyQTNJc0xBUVhFZkxiMVVyb3g0bmlv?=
 =?utf-8?B?SU9SU2VLRkdzZmdFc1o3QUlSREdhTDJ4NnNKQWNJajd2ZkVXbjBYNzIxdTdr?=
 =?utf-8?B?YlRVcTNxTnRzSThIdWtaOTM0N3ZWcVczRXVuQnJnemloeHcwcTY5KzJuL255?=
 =?utf-8?B?aW56TGxwalpVVjd2QlJxOGtmcGZsYzFJeFRyMzVKWHFnWXJzTFhwVFlXL1Rs?=
 =?utf-8?B?MjJodWxiR3ZLQkNhWld2eHhycTN6UE4rd2JkSkNzMXBiOUQ4YU1rMTJtb3hW?=
 =?utf-8?B?Y3BNWkZoa3FhcmsxdHdOOTVGL01QcDZIWkFYR2ZtbFNNT1hLQ0Fxc2R6N25D?=
 =?utf-8?B?NkdkL3A3eENYaTdrR3VTd0JKMVNkMUQvanhVYkYrdUhOTE8yV0FVVW50emsr?=
 =?utf-8?B?VmNCOFd2T0g1WWJFdWkraEE1bUgzYmR6cTBDRUgxaTYwenVtcXNMTk43QURm?=
 =?utf-8?B?bkZmVDRjWkNuMkZQTFAwTFlwc1kvRFNPN2NVcE10QmFrZXBnRkQvZ3B6U3N6?=
 =?utf-8?B?eTMyc1p1TDNpMmZGdG9Ncmx4SUs2SWc4M0QzTkZVeVY4aTgxQnRaT1V0N2hz?=
 =?utf-8?B?ZlJpSVUwY1M2L0l2MHhGaGF5d21TbjJNM3J3NXVnS1h3RWw1Z1ExV2JhcFRB?=
 =?utf-8?B?TWdZMzZMRGZ6L0t1Um5pclpvM1NFUmxnZHlCcE9vcldkbSs3VktydndOYWZk?=
 =?utf-8?B?RER4QnhvTVBmK3I1Q3pReEl1NFNndTRYSWdzd0YwYVRaTDZhR3krOVlZQU9R?=
 =?utf-8?B?TmlMZk5FOTZxVWtCNXhRVDB4eW9MeHBYNzg4SEhDT1J3anlyS3ZLWFFSVnVF?=
 =?utf-8?B?SU03Sm4yQWt0WktuTGUxM1VPT2ZqUk5CU0F6WHpqSjE2RXZQdkcyYVVNYXN5?=
 =?utf-8?B?VlRMM09pWW9GNlNOeHFaYnExN1dFNE55KzJyRXM3RS83OFdFNi96R1RhYlZG?=
 =?utf-8?B?OFVpWGtvUzlqNTBTVjFWVVdyc1FaWGMyeG9zUFdnUDN6WEhQMG5DUFBoWmdW?=
 =?utf-8?B?bXFjL0pER0UyVkdWZjAycDBwZ0oyejVHTXErVmpZWHAwK0hVN255LzRMVDJ5?=
 =?utf-8?B?d21Vd3ZwaXl0clB5TjRpSHBIU0l3MEhHZUxwODJBbkQ0L0xja0xua3pBZUJT?=
 =?utf-8?B?SU9wdkJ3R0NRczUyNmQwc00xcjRDMVJTOU4wenBSeGJlZ1hVK0RnM0JsK2M2?=
 =?utf-8?B?R2tSVHdDcFJuRzRBVTJ1TGRrSmdOMDZJckRWTFd2bWliaituL3h5NU9QVC9Q?=
 =?utf-8?B?d3JseEFRZkd0aG8wR1ROVFkyWTBuOEgzaVAyTGtNRTQxOWtIYTk1c2hKZDF0?=
 =?utf-8?B?V1VYSldhQ25xdHltU3owSUljVVVNQWVROU9Scy8xc3pmOEFYOERHMzN5TExR?=
 =?utf-8?B?amx2aUlUVVFHbFhsVG5ZUXZEeUlaV2o5RTRrVGx0L2oyOXNxTkxPYng2OHVV?=
 =?utf-8?B?YlBnbDViMm1wZEw0aDh5RzQ1dTIwZXl2WTNxV2lmYTVSYW1lYTdtenlWaElk?=
 =?utf-8?B?TDlKbC9BT1BUTzBpdzdOZ3ZRSVA4UWlxemdSV2FBUVJXbGMvZG5qaG9NdHVY?=
 =?utf-8?B?TnFvdnF6SlhFeGt1T1FIVTFLaW8xN2pMZ0ZvTG5ua2JqUWtxdzh6cmhjUmM4?=
 =?utf-8?B?cVNpbWhBVjdtTXk4d3V5ZXRlTmlFOEVsRmlENTc4dHdrOFFyV1lORWc1ejlj?=
 =?utf-8?B?OElBdHR6TWFVcGIwVjVSeTBLMitoYXlKVmtPeEl0OEtCazYvUXFLUVZEeHFY?=
 =?utf-8?B?dXFWb1dtR3EyZVFNNTlZUU1QcHlJRFN2TWNuTW43VTQwTWVYamlqMXlpd1RD?=
 =?utf-8?B?elJ1ZElNT1NwRlQ3OFRNZ3BoSE1EUTFaL01FVndEMFozNVhhZTlWdWtuSjZo?=
 =?utf-8?Q?tBF5h5YW6Tkj8bTG12PiQxf2HXtknUyw?=
X-Microsoft-Exchange-Diagnostics: 1;MWHPR12MB1613;6:/M1kl2SpgEKKJ/agwp9pPffOun1BQcO9YF+UGarI1a35g16jiw1EJg9no2SXs5VAwRipoxh9riZ0aEIbwWOXAAoZeZ4yd3di2f33CpMk0JyKAH7P7sznQWPVfPFAzp5jy5MyIzY0KUKqhjGc1QauFfoQvij3gAr/3VrhTnKzs7SRgbJGUeeodfW6QUMPacBJXsPCXX2IhD5RoYekhIjFciz3d9HHXCZwpzYzU3mU/nDxMSyxYmGPxT2sdkjvUg9ZtBfl87xeavJBJc9vvRx/Th/Na/q2IPV3aIx3E8Z90mS3ZRMeKaJnfe1nR2WNgTUbrBgtePc9wD2c4W5NXty3paclHasEEAzsNBXpiim3A+C/D2AZMkeY2qYS/L5VnAR/+YhSZEtFZAEBckfc4PEvj/0VVNnbq1Sj8/lZ8zRx9p8=;5:J4GFhgn2mOvfbr8ONPYwkQwW0YvUALbeKskZmxD9dyG7xpFUi/0naZDELYpYQ7jkp+FzaWi/ZrKAILMqSDkMr91JTGEe5zI+P4rIABu4uuvfIfbmQKIrtD1JpBZ/8zRidnOzEbdoXU+az/UhKeNFY0yvvZsFF4/0gh0zegRl4Oc=;24:fC1Nx3OAdRRRE/rkEeX29b7h5CQNRq3Vbufk1jkmvk0CRrjH9wNxyMwZxXNJtzkjXQ1/IwO93gY/j9Dcya+gOEWDPO+ui33mFkYGTAq8KyY=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1;MWHPR12MB1613;7:+SylSRBDwYOOVrCp5ZSoU6IN0et/L3gqKbF25g3T4NPyMDEJs63SMtqpgGYZI9lce7qYTV0X7OqDQR5KELc5PDuc0AewI+MDeATCiUpQMDMeF4oR1ZUOAEvCK1drb/l1QLbWkbVQB6Q3C8edHYh129aaru2ux35jwhttvpV3fnWZIcG4dXn1ibNvx07J7O1wAqfvjvQ9NAikl3Ad0Gr3KF3K09l/Hfl5A2eswT2MdzhaKwukdaUj+wxt+nkt7bwporjOhYyWLRFXZIyl5L/5hVr27M3K6mkA6XyjzdwuhLXMBUfEBwALDpEeSg7ZewTJK/V9+sEL0piVzZh4x94UJA==;20:rH2C9yk861y+0tgY8UQ4lkqNeYUFw1obge9hxXsULnk95ukjnI6v0jO63OMVzcwHk4IHARrB3Z1d9IbPFOxeEtWrQm/cW4S/czUCdqZ5pr1gzwsHdGlFXChiiqagTQ9/folWfXQLXM/fvEnGXoiegK7YS9LiJxj5jxVSBTNm6+prnYKj0/peWoQIL7Oa8iCGv7n7RIPnullu97YrmtZmq0nmi/xJ4r8Y4FrQf58eMJqT5P7PbrpYTSg1kbcVWCqk
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2017 16:35:35.1087 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR12MB1613
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Boris and Paolo,

On 03/09/2017 10:29 AM, Borislav Petkov wrote:
> On Thu, Mar 09, 2017 at 05:13:33PM +0100, Paolo Bonzini wrote:
>> This is not how you check if running under a hypervisor; you should
>> check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx.  This in turn
>> tells you if leaf 0x40000000 is valid.
>
> Ah, good point, I already do that in the microcode loader :)
>
>         /*
>          * CPUID(1).ECX[31]: reserved for hypervisor use. This is still not
>          * completely accurate as xen pv guests don't see that CPUID bit set but
>          * that's good enough as they don't land on the BSP path anyway.
>          */
>         if (native_cpuid_ecx(1) & BIT(31))
>                 return *res;
>
>> That said, the main issue with this function is that it hardcodes the
>> behavior for KVM.  It is possible that another hypervisor defines its
>> 0x40000001 leaf in such a way that KVM_FEATURE_SEV has a different meaning.
>>
>> Instead, AMD should define a "well-known" bit in its own space (i.e.
>> 0x800000xx) that is only used by hypervisors that support SEV.  This is
>> similar to how Intel defined one bit in leaf 1 to say "is leaf
>> 0x40000000 valid".
>>
>>> +	if (eax > 0x40000000) {
>>> +		eax = 0x40000001;
>>> +		ecx = 0;
>>> +		native_cpuid(&eax, &ebx, &ecx, &edx);
>>> +		if (!(eax & BIT(KVM_FEATURE_SEV)))
>>> +			goto out;
>>> +
>>> +		eax = 0x8000001f;
>>> +		ecx = 0;
>>> +		native_cpuid(&eax, &ebx, &ecx, &edx);
>>> +		if (!(eax & 1))
>
> Right, so this is testing CPUID_0x8000001f_ECX(0)[0], SME. Why not
> simply set that bit for the guest too, in kvm?
>

CPUID_8000_001F[EAX] indicates whether the feature is supported.
CPUID_0x8000001F[EAX]:
  * Bit 0 - SME supported
  * Bit 1 - SEV supported
  * Bit 3 - SEV-ES supported

We can use MSR_K8_SYSCFG[MemEncryptionModeEnc] to check if memory encryption is enabled.
Currently, KVM returns zero when guest OS read MSR_K8_SYSCFG. I can update my patch sets
to set this bit for SEV enabled guests.

We could update this patch to use the below logic:

  * CPUID(0) - Check for AuthenticAMD
  * CPID(1) - Check if under hypervisor
  * CPUID(0x80000000) - Check for highest supported leaf
  * CPUID(0x8000001F).EAX - Check for SME and SEV support
  * rdmsr (MSR_K8_SYSCFG)[MemEncryptionModeEnc] - Check if SMEE is set


Paolo,

One question, do we need "AuthenticAMD" check when we are running under hypervisor ?
I was looking at qemu code and found that qemu exposes parameters to change the CPU
vendor id. The above check will fail if user changes the vendor id while launching
the SEV guest.

-Brijesh

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Brijesh Singh <brijesh.singh@amd.com>
Subject: Re: [RFC PATCH v2 12/32] x86: Add early boot support when running
 with SEV active
Date: Fri, 10 Mar 2017 10:35:30 -0600
Message-ID: <1fe1e177-f588-fe5a-dc13-e9fde00e8958@amd.com>
References: <148846752022.2349.13667498174822419498.stgit@brijesh-build-machine>
 <148846768878.2349.15757532025749214650.stgit@brijesh-build-machine>
 <20170309140748.tg67yo2jmc5ahck3@pd.tnic>
 <5d62b16f-16ef-1bd7-1551-f0c4c43573f4@redhat.com>
 <20170309162942.jwtb3l33632zhbaz@pd.tnic>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <owner-linux-mm@kvack.org>
In-Reply-To: <20170309162942.jwtb3l33632zhbaz@pd.tnic>
Sender: owner-linux-mm@kvack.org
To: Borislav Petkov <bp@suse.de>, Paolo Bonzini <pbonzini@redhat.com>
Cc: brijesh.singh@amd.com, simon.guinot@sequanux.org, linux-efi@vger.kernel.org, kvm@vger.kernel.org, rkrcmar@redhat.com, matt@codeblueprint.co.uk, linux-pci@vger.kernel.org, linus.walleij@linaro.org, gary.hook@amd.com, linux-mm@kvack.org, paul.gortmaker@windriver.com, hpa@zytor.com, cl@linux.com, dan.j.williams@intel.com, aarcange@redhat.com, sfr@canb.auug.org.au, andriy.shevchenko@linux.intel.com, herbert@gondor.apana.org.au, bhe@redhat.com, xemul@parallels.com, joro@8bytes.org, x86@kernel.org, peterz@infradead.org, piotr.luc@intel.com, mingo@redhat.com, msalter@redhat.com, ross.zwisler@linux.intel.com, dyoung@redhat.com, thomas.lendacky@amd.com, jroedel@suse.de, keescook@chromium.org, arnd@arndb.de, toshi.kani@hpe.com, mathieu.desnoyers@efficios.com, luto@kernel.org, devel@linuxdriverproject.org, bhel
List-Id: linux-efi@vger.kernel.org

Hi Boris and Paolo,

On 03/09/2017 10:29 AM, Borislav Petkov wrote:
> On Thu, Mar 09, 2017 at 05:13:33PM +0100, Paolo Bonzini wrote:
>> This is not how you check if running under a hypervisor; you should
>> check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx.  This in turn
>> tells you if leaf 0x40000000 is valid.
>
> Ah, good point, I already do that in the microcode loader :)
>
>         /*
>          * CPUID(1).ECX[31]: reserved for hypervisor use. This is still not
>          * completely accurate as xen pv guests don't see that CPUID bit set but
>          * that's good enough as they don't land on the BSP path anyway.
>          */
>         if (native_cpuid_ecx(1) & BIT(31))
>                 return *res;
>
>> That said, the main issue with this function is that it hardcodes the
>> behavior for KVM.  It is possible that another hypervisor defines its
>> 0x40000001 leaf in such a way that KVM_FEATURE_SEV has a different meaning.
>>
>> Instead, AMD should define a "well-known" bit in its own space (i.e.
>> 0x800000xx) that is only used by hypervisors that support SEV.  This is
>> similar to how Intel defined one bit in leaf 1 to say "is leaf
>> 0x40000000 valid".
>>
>>> +	if (eax > 0x40000000) {
>>> +		eax = 0x40000001;
>>> +		ecx = 0;
>>> +		native_cpuid(&eax, &ebx, &ecx, &edx);
>>> +		if (!(eax & BIT(KVM_FEATURE_SEV)))
>>> +			goto out;
>>> +
>>> +		eax = 0x8000001f;
>>> +		ecx = 0;
>>> +		native_cpuid(&eax, &ebx, &ecx, &edx);
>>> +		if (!(eax & 1))
>
> Right, so this is testing CPUID_0x8000001f_ECX(0)[0], SME. Why not
> simply set that bit for the guest too, in kvm?
>

CPUID_8000_001F[EAX] indicates whether the feature is supported.
CPUID_0x8000001F[EAX]:
  * Bit 0 - SME supported
  * Bit 1 - SEV supported
  * Bit 3 - SEV-ES supported

We can use MSR_K8_SYSCFG[MemEncryptionModeEnc] to check if memory encryption is enabled.
Currently, KVM returns zero when guest OS read MSR_K8_SYSCFG. I can update my patch sets
to set this bit for SEV enabled guests.

We could update this patch to use the below logic:

  * CPUID(0) - Check for AuthenticAMD
  * CPID(1) - Check if under hypervisor
  * CPUID(0x80000000) - Check for highest supported leaf
  * CPUID(0x8000001F).EAX - Check for SME and SEV support
  * rdmsr (MSR_K8_SYSCFG)[MemEncryptionModeEnc] - Check if SMEE is set


Paolo,

One question, do we need "AuthenticAMD" check when we are running under hypervisor ?
I was looking at qemu code and found that qemu exposes parameters to change the CPU
vendor id. The above check will fail if user changes the vendor id while launching
the SEV guest.

-Brijesh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-pf0-f199.google.com (mail-pf0-f199.google.com [209.85.192.199])
	by kanga.kvack.org (Postfix) with ESMTP id 9302928092C
	for <linux-mm@kvack.org>; Fri, 10 Mar 2017 11:35:45 -0500 (EST)
Received: by mail-pf0-f199.google.com with SMTP id 67so170723162pfg.0
        for <linux-mm@kvack.org>; Fri, 10 Mar 2017 08:35:45 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0081.outbound.protection.outlook.com. [104.47.34.81])
        by mx.google.com with ESMTPS id q87si3409727pfk.243.2017.03.10.08.35.44
        for <linux-mm@kvack.org>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
        Fri, 10 Mar 2017 08:35:44 -0800 (PST)
Subject: Re: [RFC PATCH v2 12/32] x86: Add early boot support when running
 with SEV active
References: <148846752022.2349.13667498174822419498.stgit@brijesh-build-machine>
 <148846768878.2349.15757532025749214650.stgit@brijesh-build-machine>
 <20170309140748.tg67yo2jmc5ahck3@pd.tnic>
 <5d62b16f-16ef-1bd7-1551-f0c4c43573f4@redhat.com>
 <20170309162942.jwtb3l33632zhbaz@pd.tnic>
From: Brijesh Singh <brijesh.singh@amd.com>
Message-ID: <1fe1e177-f588-fe5a-dc13-e9fde00e8958@amd.com>
Date: Fri, 10 Mar 2017 10:35:30 -0600
MIME-Version: 1.0
In-Reply-To: <20170309162942.jwtb3l33632zhbaz@pd.tnic>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: Borislav Petkov <bp@suse.de>, Paolo Bonzini <pbonzini@redhat.com>
Cc: brijesh.singh@amd.com, simon.guinot@sequanux.org, linux-efi@vger.kernel.org, kvm@vger.kernel.org, rkrcmar@redhat.com, matt@codeblueprint.co.uk, linux-pci@vger.kernel.org, linus.walleij@linaro.org, gary.hook@amd.com, linux-mm@kvack.org, paul.gortmaker@windriver.com, hpa@zytor.com, cl@linux.com, dan.j.williams@intel.com, aarcange@redhat.com, sfr@canb.auug.org.au, andriy.shevchenko@linux.intel.com, herbert@gondor.apana.org.au, bhe@redhat.com, xemul@parallels.com, joro@8bytes.org, x86@kernel.org, peterz@infradead.org, piotr.luc@intel.com, mingo@redhat.com, msalter@redhat.com, ross.zwisler@linux.intel.com, dyoung@redhat.com, thomas.lendacky@amd.com, jroedel@suse.de, keescook@chromium.org, arnd@arndb.de, toshi.kani@hpe.com, mathieu.desnoyers@efficios.com, luto@kernel.org, devel@linuxdriverproject.org, bhelgaas@google.com, tglx@linutronix.de, mchehab@kernel.org, iamjoonsoo.kim@lge.com, labbott@fedoraproject.org, tony.luck@intel.com, alexandre.bounine@idt.com, kuleshovmail@gmail.com, linux-kernel@vger.kernel.org, mcgrof@kernel.org, mst@redhat.com, linux-crypto@vger.kernel.org, tj@kernel.org, akpm@linux-foundation.org, davem@davemloft.net

Hi Boris and Paolo,

On 03/09/2017 10:29 AM, Borislav Petkov wrote:
> On Thu, Mar 09, 2017 at 05:13:33PM +0100, Paolo Bonzini wrote:
>> This is not how you check if running under a hypervisor; you should
>> check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx.  This in turn
>> tells you if leaf 0x40000000 is valid.
>
> Ah, good point, I already do that in the microcode loader :)
>
>         /*
>          * CPUID(1).ECX[31]: reserved for hypervisor use. This is still not
>          * completely accurate as xen pv guests don't see that CPUID bit set but
>          * that's good enough as they don't land on the BSP path anyway.
>          */
>         if (native_cpuid_ecx(1) & BIT(31))
>                 return *res;
>
>> That said, the main issue with this function is that it hardcodes the
>> behavior for KVM.  It is possible that another hypervisor defines its
>> 0x40000001 leaf in such a way that KVM_FEATURE_SEV has a different meaning.
>>
>> Instead, AMD should define a "well-known" bit in its own space (i.e.
>> 0x800000xx) that is only used by hypervisors that support SEV.  This is
>> similar to how Intel defined one bit in leaf 1 to say "is leaf
>> 0x40000000 valid".
>>
>>> +	if (eax > 0x40000000) {
>>> +		eax = 0x40000001;
>>> +		ecx = 0;
>>> +		native_cpuid(&eax, &ebx, &ecx, &edx);
>>> +		if (!(eax & BIT(KVM_FEATURE_SEV)))
>>> +			goto out;
>>> +
>>> +		eax = 0x8000001f;
>>> +		ecx = 0;
>>> +		native_cpuid(&eax, &ebx, &ecx, &edx);
>>> +		if (!(eax & 1))
>
> Right, so this is testing CPUID_0x8000001f_ECX(0)[0], SME. Why not
> simply set that bit for the guest too, in kvm?
>

CPUID_8000_001F[EAX] indicates whether the feature is supported.
CPUID_0x8000001F[EAX]:
  * Bit 0 - SME supported
  * Bit 1 - SEV supported
  * Bit 3 - SEV-ES supported

We can use MSR_K8_SYSCFG[MemEncryptionModeEnc] to check if memory encryption is enabled.
Currently, KVM returns zero when guest OS read MSR_K8_SYSCFG. I can update my patch sets
to set this bit for SEV enabled guests.

We could update this patch to use the below logic:

  * CPUID(0) - Check for AuthenticAMD
  * CPID(1) - Check if under hypervisor
  * CPUID(0x80000000) - Check for highest supported leaf
  * CPUID(0x8000001F).EAX - Check for SME and SEV support
  * rdmsr (MSR_K8_SYSCFG)[MemEncryptionModeEnc] - Check if SMEE is set


Paolo,

One question, do we need "AuthenticAMD" check when we are running under hypervisor ?
I was looking at qemu code and found that qemu exposes parameters to change the CPU
vendor id. The above check will fail if user changes the vendor id while launching
the SEV guest.

-Brijesh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>