From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when
 SEV is active
Date: Thu, 22 Sep 2016 14:49:22 -0500
Message-ID: <e162ecbf-f0b5-9a38-fdf6-7f097e20c5ad@amd.com>
References: <147190820782.9523.4967724730957229273.stgit@brijesh-build-machine>
 <147190832511.9523.10850626471583956499.stgit@brijesh-build-machine>
 <20160922143545.3kl7khff6vqk7b2t@pd.tnic>
 <464461b7-1efb-0af1-dd3e-eb919a2578e9@redhat.com>
 <20160922145947.52v42l7p7dl7u3r4@pd.tnic>
 <938ee0cf-85e6-eefa-7df9-9d5e09ed7a9d@redhat.com>
 <20160922170718.34d4ppockeurrg25@pd.tnic>
 <1a22afee-a146-414c-6f58-66a942f7aab9@amd.com>
 <20160922191138.lnp4ac3cfkiebjo3@pd.tnic>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Cc: Paolo Bonzini <pbonzini@redhat.com>, Brijesh Singh
	<brijesh.singh@amd.com>, <simon.guinot@sequanux.org>,
	<linux-efi@vger.kernel.org>, <kvm@vger.kernel.org>, <rkrcmar@redhat.com>,
	<matt@codeblueprint.co.uk>, <linus.walleij@linaro.org>, <linux-mm@kvack.org>,
	<paul.gortmaker@windriver.com>, <hpa@zytor.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>,
	<mingo@redhat.com>, <msalter@redhat.com>, <ross.zwisler@linux.intel.com>,
	<dyoung@redhat.com>, <jroedel@suse.de>, <keescook@chromium.org>,
	<toshi.kani@hpe.com>, <mathieu.desnoyers@efficios.com>,
	<devel@linuxdriverproject.org>, <tglx@linutronix.de>, <mchehab@kernel.org>,
	<iamjoonsoo.kim@lge.com>, <labbott@fedoraproject.org>, <tony.luck@intel.com>,
	<alexan
To: Borislav Petkov <bp@suse.de>
Return-path: <owner-linux-mm@kvack.org>
In-Reply-To: <20160922191138.lnp4ac3cfkiebjo3@pd.tnic>
Sender: owner-linux-mm@kvack.org
List-Id: linux-crypto.vger.kernel.org

On 09/22/2016 02:11 PM, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 02:04:27PM -0500, Tom Lendacky wrote:
>> That's not what I mean here.  If the BIOS sets the SMEE bit in the
>> SYS_CFG msr then, even if the encryption bit is never used, there is
>> still a reduction in physical address space.
> 
> I thought that reduction is the reservation of bits for the SME mask.
> 
> What other reduction is there?

There is a reduction in physical address space for the SME mask and the
bits used to aid in identifying the ASID associated with the memory
request. This allows for the memory controller to determine the key to
be used for the encryption operation (host/hypervisor key vs. an SEV
guest key).

Thanks,
Tom

> 
>> Transparent SME (TSME) will be a BIOS option that will result in the
>> memory controller performing encryption no matter what. In this case
>> all data will be encrypted without a reduction in physical address
>> space.
> 
> Now I'm confused: aren't we reducing the address space with the SME
> mask?
> 
> Or what reduction do you mean?
> 

--
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 S964922AbcIVTtg (ORCPT <rfc822;w@1wt.eu>);
        Thu, 22 Sep 2016 15:49:36 -0400
Received: from mail-cys01nam02on0046.outbound.protection.outlook.com ([104.47.37.46]:24848
        "EHLO NAM02-CY1-obe.outbound.protection.outlook.com"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S1756385AbcIVTtb (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 22 Sep 2016 15:49:31 -0400
Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=Thomas.Lendacky@amd.com; 
Subject: Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when
 SEV is active
To: Borislav Petkov <bp@suse.de>
References: <147190820782.9523.4967724730957229273.stgit@brijesh-build-machine>
 <147190832511.9523.10850626471583956499.stgit@brijesh-build-machine>
 <20160922143545.3kl7khff6vqk7b2t@pd.tnic>
 <464461b7-1efb-0af1-dd3e-eb919a2578e9@redhat.com>
 <20160922145947.52v42l7p7dl7u3r4@pd.tnic>
 <938ee0cf-85e6-eefa-7df9-9d5e09ed7a9d@redhat.com>
 <20160922170718.34d4ppockeurrg25@pd.tnic>
 <1a22afee-a146-414c-6f58-66a942f7aab9@amd.com>
 <20160922191138.lnp4ac3cfkiebjo3@pd.tnic>
CC: Paolo Bonzini <pbonzini@redhat.com>,
        Brijesh Singh <brijesh.singh@amd.com>, <simon.guinot@sequanux.org>,
        <linux-efi@vger.kernel.org>, <kvm@vger.kernel.org>,
        <rkrcmar@redhat.com>, <matt@codeblueprint.co.uk>,
        <linus.walleij@linaro.org>, <linux-mm@kvack.org>,
        <paul.gortmaker@windriver.com>, <hpa@zytor.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>, <mingo@redhat.com>,
        <msalter@redhat.com>, <ross.zwisler@linux.intel.com>,
        <dyoung@redhat.com>, <jroedel@suse.de>, <keescook@chromium.org>,
        <toshi.kani@hpe.com>, <mathieu.desnoyers@efficios.com>,
        <devel@linuxdriverproject.org>, <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>,
        <linux-crypto@vger.kernel.org>, <akpm@linux-foundation.org>,
        <davem@davemloft.net>
From: Tom Lendacky <thomas.lendacky@amd.com>
Message-ID: <e162ecbf-f0b5-9a38-fdf6-7f097e20c5ad@amd.com>
Date: Thu, 22 Sep 2016 14:49:22 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160922191138.lnp4ac3cfkiebjo3@pd.tnic>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [165.204.77.1]
X-ClientProxiedBy: SN1PR01CA0034.prod.exchangelabs.com (10.165.224.44) To
 DM5PR12MB1148.namprd12.prod.outlook.com (10.168.236.143)
X-MS-Office365-Filtering-Correlation-Id: db14f5c0-e971-491f-0151-08d3e32190b6
X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1148;2:8M/SHxSP9HvrDRxyviy/+l4dCTekqG64gSNwRj7nSJnNFUdIwt8N+OrQc+GJbMZ0faFlbbEDonio9dLOFLCHgBXmDZn5Dzbtqdrf3qYC7jZGQIIkyk56HIG53H+LZT78tGtOUc20vPi9FLuC0j9z2vKnEOn7tcTrXxZ+Dv9u01U19Zkth+zX7vouuEbhYHqT;3:oHPFQClIinF6HxJevIqag6Atp03EOD3/UCLDzCo0pCz7S3RtDzRE68J935o4JDnc138d2SNrVExlVTf2ZmjDsvM2/v4mJteA67qPQ3lPG+ECRYMiSSHvomPddtH7nu9Z;25:Ks+3dabSWZ6/hpfBwJawAPIdS7EUjzVirNFqJkROMBu/Geam8xAHtgAufK9esOaTopOPBNs8Mq8jhAlrEHGU/afqQ5VZYWIY3v62d+nTID3b2WaKSSu5iON1iOgN8XPouWwIP32Sj6ylzzBJW6INDP3/uSK2KMCevn2IpfP4B0ADQWR8E1wyi7jYDONVORH7hkkyvcQIejm4pzMLiuWd+nhZ+4J4V5uFd7S0Dlaix4V6cts2DuO9OyS7l30zSTjWp3qa5b+aiNOylFjo6UfTX1JH0IaS1zLGSdISnVqxPWQC+SCL+pHDt1NdCigrrRDv6M4HVWAAhlDUWbTvuHOZVW12iS0s1tR7XFg4sdFwfFBjtM+rcw5K1X6oBsMV2OSv8MSaeFGHP9sdYk2QyCTzM5iC3xobqFkl6rfpCvMvrJQ=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR12MB1148;
X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1148;31:ajuCmPT1+q3+CgdVIlbQsIDIgOB/VxdfufwMv7TOThilHIInOTgOnz5Hkz1bf92hzlnUIxylBsZkYYB3WZpM23WQxvHt7578HVAGfPjeHCUehfZ+NFROAa/8hKHWlToQXtnGhZ4LhuPunirdY7NFKhYoaBsc8uTZx+LmRiBJvNII/1BaacAZ/6iQ89dNIV8gjOUMqtw5r57d4lKxew69vvtuVQu9P9j/mNM5YRyWtj4=;20:4KfD/U7/nEih9iXSP9a7KsAEXD93+i+lO4xgM5jScHryvm+UlouYYOmJ2RSZGOhxsbi19mIAMKb3iXxKfRzOGjc+FWQI7m345pb0Xn0u3pdxoj1u3rwaWg7J5BRaXwGVN1ea89vOr/ed0DZp6S0i92msYwhu+Y8VL6KzkJ8asJ2YYqnx1cTtHu0RLhSD/FByj9Ecc4fxekIroeBL+BO09pdwvy+Hf/tloRmhiESuBoQulaq2q90GGlGt4ns3jndnJojlYSUACMFbNRGFOikjWttptnocysKWoqp+v8TaqzyMaxmWo52RR+Nnzs3UEvfhmkny6bfBc5uMJloGG0tHXhroqxWO6A0iB2YNmKVFEJsvjscXFBKbuXNB4mhPYVnyf7e23HgS71+llWYETHh5Dqo6v6L2gNVCMOZNkbNCgG3IZKPD2dkpHXiYudzNIO7XhejSwmcjy/RWFvKpnOTPIEGOEFBOffj4han8yhgNmMxKcehYq/9QeDYGpkmUuryn
X-Microsoft-Antispam-PRVS: <DM5PR12MB114868703105057591041998ECC90@DM5PR12MB1148.namprd12.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:DM5PR12MB1148;BCL:0;PCL:0;RULEID:;SRVR:DM5PR12MB1148;
X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1148;4:P7/xirNgMlifMxOW/DE8LI1YIT7ki9UZK9ZNMJvCRYrlcT+9QWV5hMYx10iYtsfIhb0L4x/VKs/Q8e9vX2a27LK2LWSJAlQGRgRH7GZXFALWq8EwpnM1DWnju7HkSmc008YZ7CXmFx3YIMzvYBpnKLu1yJRArWith6MTMi0cNaBhU8JGbBs8DReUNP6/33E3sNxbRhXeZQRl8ig7itQtH5qPFadW9W4XHtdwoysq/T23XGSJCH0O0bsbaYjYixBgD8dL+5Q5zKkzU7Su+XJSk+RoKFdVD4uLzwRIwwWpw83uX3/DUm/YRj9TxBp6JeKdrRLFY2b9F/F0X2qpyq938lj7+72takevnU2Zauhp4+8dz9oS/f7Q9MVISMDLAdKI3RkLg9XGetZtrzTMVuFCgg==
X-Forefront-PRVS: 0073BFEF03
X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(199003)(377454003)(189002)(24454002)(33646002)(68736007)(101416001)(42186005)(6116002)(86362001)(31686004)(92566002)(7846002)(586003)(105586002)(76176999)(50986999)(4001350100001)(93886004)(189998001)(106356001)(31696002)(7736002)(36756003)(110136003)(54356999)(97736004)(3846002)(77096005)(64126003)(2950100001)(83506001)(4326007)(305945005)(7406005)(7416002)(2906002)(5660300001)(23676002)(81166006)(65806001)(66066001)(8676002)(65826007)(65956001)(47776003)(50466002)(230700001)(81156014)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:DM5PR12MB1148;H:[10.236.18.82];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en;
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjEyTUIxMTQ4OzIzOmlmK2ZlS2J1aTA2K0F4NHlGSGJUbnFVZWdW?=
 =?utf-8?B?N0grT2hVZmRtWnhKRm13V2plVjBWVDRVdFIrRnZBTlhUWVdTWWxOLytYcFBW?=
 =?utf-8?B?ZXFQaU5SelhRNVAxNE5mMXJlckRmQWl4MkFieU1lY2E4bEJkQXhHN3FVTS94?=
 =?utf-8?B?djZ2NjVNT0hCVXF4N0NvTkRZcGhId0oySWNJMHpCdi9ibTNPQnRSTGErUTJz?=
 =?utf-8?B?UkFSVWl2aDJkYW5QWkh2QVJmREdiWUhlUk8wQ0VkUnl0THpmRnFrK3lWQU5E?=
 =?utf-8?B?VzFRdmkwNjlVL295a2lWOHN3RWt0M0MwMFNGL0hJL05ZS0J1Y2ZLNG9vZzla?=
 =?utf-8?B?VlpaMGRaa2FSKy94TFlsd2R5NWdESGRONXhtTWVBYkk4bnFhazRNQ1o5ZStL?=
 =?utf-8?B?cmQ4dUtRRFlxc0JUL29ONktSck8zSWNmL2V6TTVteXFuWkxleEZpWnlzb08v?=
 =?utf-8?B?YkVFL0RlVk5pNDNNdmNPUXc4amx1SjlaTVNLMmZHWnI1SXpIVW96VWhyc3lP?=
 =?utf-8?B?SWk3WERpVTBuSUc3STZOM1MvMkZaaXBCVTBudWZ4NkxpQ2lCM3NyK0pFcVVu?=
 =?utf-8?B?Zko5ZFhtbW9SQ1l6VG9qSlR5QVNiWnpwN2VDa2UyWmNkUFBXQ1BwMTFhM2Ro?=
 =?utf-8?B?SkJzdDQ4Q0p5TGcxdUNkLzlPdTJGYlJVYUc4VmRTb0JHck9VS0lSSnpFdjhz?=
 =?utf-8?B?cGVwbnFxa1FKYXhYUkt3d0dobk5KS2lUNVNDLzNuS0JQT1UrSWVUQlE2cWFx?=
 =?utf-8?B?VDc4ODNEZ3RsS0E4WGZsWlp0bWFJUWRjOG1zS1JrQ0xXaXdvZHF2NTNoR3BM?=
 =?utf-8?B?b3JFeExnd2pPckp6QlIydUdMemhUWEZGUks0YjYvcmZOak9wdC9QUHJ2eEZi?=
 =?utf-8?B?MXdiQjBMVVBJZ0hPbGhzNXZnTG16S3ZLN0xrNys2N0hqSjBwNzBYb3J1SUlT?=
 =?utf-8?B?bmFEMzE3d2VjdGk1ZVVkWEZmV0hyWURvVW1ZY2VPajNmYTh2ZjZBa1h2bTZy?=
 =?utf-8?B?OHRSYjZEaEY1S0F1VS8xWmEraEtXNkJxOXZvVWhFb0tVdTZRSDhITTZJS2VL?=
 =?utf-8?B?cE9wTklYT3dMMFBvZEhHYUdueU1PcHVtRllUVWh3anBZMUYwODdRSmRMbkND?=
 =?utf-8?B?L3dIZTRWVUJFOTBxVFVGSCtyRWJtUkdFdVQvUW1DU0ZMSHh4MVloWTNzdUs1?=
 =?utf-8?B?ZzB4NGNaR3JsbVppSG9pVm9Iak0zTFJqL0RlMlZiZHBsc256MEVNUVlJSmls?=
 =?utf-8?B?NW0xb3pPMENaYnNkWFFOZHlxRTB5NXBybis2azRDK2RsZWFPcndacFRXQ2xr?=
 =?utf-8?B?SjYwOXdyR1NJV25uUldhZkt3Mnl4Y0pRUHUxaWlIOTJRSGlLUnFSTWVCejZX?=
 =?utf-8?B?SVRuRjRRbUo1RFJGSEY2RkNDNXJyY3JTUFhSVHYzQTNTQ3BPdE9xdGNFeGVH?=
 =?utf-8?B?b2VEQTZCaHZtODJJR3FRanNHVkU2TUd4aFg5bHZVdWJBT2dVWVl3TkhXYWpF?=
 =?utf-8?B?QkhXRDFEK25oT1FYTUZXT2VPYkxTWTI3Y0gvZk9KYXV3NnZLelBjYXIxaEtB?=
 =?utf-8?B?cUFLcitoWTZvcFhIbEhVOEhPNnYzR0xTdHVTY2NTTkwycEdjaFhzeHFmSmpI?=
 =?utf-8?B?SHlUb2phcVE4TDlaUk43ak4vZnpNOXpPQW5lbEJXZktOZEEzaXJWZ1lKZ3Js?=
 =?utf-8?B?U1FUK28xYlA3TjNHNXVxb2xFRCtKT25VcFZCcmozVW1qZXlweExnYm9mbkVD?=
 =?utf-8?Q?OM9KoUzzbLmC+Z+zVm9xFxKcZ55qS5kFzqGSI=3D?=
X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1148;6:6QkXLmMLEKa1dcpl+24NIxJCloohvX/MIUlIqv6JdKECPxv5TP/TksXa0B/OTGd/pOrnuDd8ADQzHSdM7Y6IERYw4K2vq8sit4v3HunKBDcBapjeJuDK8NW41CqUg+y7JJOWhXH/QMfEWGPEugqe1/vd8qp5rwhbQuPvUIX7QsOM3hS3t4aoS5ERYNb4/7dpLj+7PHe8ZlidIL3VjHvBf4WD7e+F1DmUC+AlYxQM40rv4Nrkx5SejG9wk8XVoQvv8BTbDNfXVRf70IF4ORobkJHeuoGyjigP5ES2QKqaPhEzBQvd3/UOPf7ZDYApDSzMCUjobm8Yeh0TLh3R/fQNYA==;5:WCCIqN4yPzxyPmVk94WaigQJjQRr/NYzfT8RFvZ4YoSydJEFxNkx0//bF26/XSglnj2YWoJGBeCreiJfRxuIl3SDGSH/7shedzRPwTdP3MYDK81n7kmc8EVNTvopTFirkHL454z9HKLAxmHTXUyhtg==;24:g+yx6sShFHGVdztNgEFNnzlg0jgzRuunk1N4kvIkks484ZnSui62LC1ZtV/eejyYwe5iPqC39wqn0Oj2EeRKPk37ULBsiK0Is1JXXbbBvdY=;7:yqRr0pN4RV4DVwS7mKs5FQs1R9KzGmS6Qkr3Y98fGywcyIb6G6FTffcLd7tBIqcoySm4Wxn2RSvoxv8ctnogUy9xVqoUUb6Ext87HQLe4H2mk8b5z3uzGkTt592iS4FAycOHd79qmTYChr4ssg+dfc5Y7oEiXN62gJhEDuUGaBr+cXyqeX8omDJ0pytGKVv+LqlMynyDhRsto5UgW3YNtNwRIBAx1hStknxyEWjz8QUWoBf1TuvQhoTxYaOyt2/yZrgRVovZl2ZBJ47d3eDOKRQBQotg63xadBaaQLwVZX36ZwIKn7cm2GxOEQyobUTP
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1148;20:AdiLVgl3Ktf9yuBmmTDym+kxccYdiwWXx2H89BvdTVBhdWyXDQcPUQkBo917yu8WANJGQ8Ffp6dIUagzZtEA1GUNyODgI9FiJCyoaZ2Ko9oh6MZBrjx8+UybBxNXe4GdX9w0iwOxtILQfbgcZso/tZ7HR3YhE5csErv3pZzSH9BbN4Lblkn83GP9L60NH4BAnjfXeUPzr0veVvB2PVqYe6c7imxXC5TxypJpVtqi9JC8UriE22Tyiy8z/rjJ8gxa
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2016 19:49:27.2189
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1148
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 09/22/2016 02:11 PM, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 02:04:27PM -0500, Tom Lendacky wrote:
>> That's not what I mean here.  If the BIOS sets the SMEE bit in the
>> SYS_CFG msr then, even if the encryption bit is never used, there is
>> still a reduction in physical address space.
> 
> I thought that reduction is the reservation of bits for the SME mask.
> 
> What other reduction is there?

There is a reduction in physical address space for the SME mask and the
bits used to aid in identifying the ASID associated with the memory
request. This allows for the memory controller to determine the key to
be used for the encryption operation (host/hypervisor key vs. an SEV
guest key).

Thanks,
Tom

> 
>> Transparent SME (TSME) will be a BIOS option that will result in the
>> memory controller performing encryption no matter what. In this case
>> all data will be encrypted without a reduction in physical address
>> space.
> 
> Now I'm confused: aren't we reducing the address space with the SME
> mask?
> 
> Or what reduction do you mean?
> 

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when
 SEV is active
Date: Thu, 22 Sep 2016 14:49:22 -0500
Message-ID: <e162ecbf-f0b5-9a38-fdf6-7f097e20c5ad@amd.com>
References: <147190820782.9523.4967724730957229273.stgit@brijesh-build-machine>
 <147190832511.9523.10850626471583956499.stgit@brijesh-build-machine>
 <20160922143545.3kl7khff6vqk7b2t@pd.tnic>
 <464461b7-1efb-0af1-dd3e-eb919a2578e9@redhat.com>
 <20160922145947.52v42l7p7dl7u3r4@pd.tnic>
 <938ee0cf-85e6-eefa-7df9-9d5e09ed7a9d@redhat.com>
 <20160922170718.34d4ppockeurrg25@pd.tnic>
 <1a22afee-a146-414c-6f58-66a942f7aab9@amd.com>
 <20160922191138.lnp4ac3cfkiebjo3@pd.tnic>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Return-path: <owner-linux-mm@kvack.org>
In-Reply-To: <20160922191138.lnp4ac3cfkiebjo3@pd.tnic>
Sender: owner-linux-mm@kvack.org
To: Borislav Petkov <bp@suse.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Brijesh Singh <brijesh.singh@amd.com>, simon.guinot@sequanux.org, linux-efi@vger.kernel.org, kvm@vger.kernel.org, rkrcmar@redhat.com, matt@codeblueprint.co.uk, linus.walleij@linaro.org, linux-mm@kvack.org, paul.gortmaker@windriver.com, hpa@zytor.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, mingo@redhat.com, msalter@redhat.com, ross.zwisler@linux.intel.com, dyoung@redhat.com, jroedel@suse.de, keescook@chromium.org, toshi.kani@hpe.com, mathieu.desnoyers@efficios.com, devel@linuxdriverproject.org, tglx@linutronix.de, mchehab@kernel.org, iamjoonsoo.kim@lge.com, labbott@fedoraproject.org, tony.luck@intel.com, alexan
List-Id: linux-efi@vger.kernel.org

On 09/22/2016 02:11 PM, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 02:04:27PM -0500, Tom Lendacky wrote:
>> That's not what I mean here.  If the BIOS sets the SMEE bit in the
>> SYS_CFG msr then, even if the encryption bit is never used, there is
>> still a reduction in physical address space.
> 
> I thought that reduction is the reservation of bits for the SME mask.
> 
> What other reduction is there?

There is a reduction in physical address space for the SME mask and the
bits used to aid in identifying the ASID associated with the memory
request. This allows for the memory controller to determine the key to
be used for the encryption operation (host/hypervisor key vs. an SEV
guest key).

Thanks,
Tom

> 
>> Transparent SME (TSME) will be a BIOS option that will result in the
>> memory controller performing encryption no matter what. In this case
>> all data will be encrypted without a reduction in physical address
>> space.
> 
> Now I'm confused: aren't we reducing the address space with the SME
> mask?
> 
> Or what reduction do you mean?
> 

--
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-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71])
	by kanga.kvack.org (Postfix) with ESMTP id E7B9428025D
	for <linux-mm@kvack.org>; Thu, 22 Sep 2016 15:49:32 -0400 (EDT)
Received: by mail-oi0-f71.google.com with SMTP id i193so227785193oib.3
        for <linux-mm@kvack.org>; Thu, 22 Sep 2016 12:49:32 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0053.outbound.protection.outlook.com. [104.47.37.53])
        by mx.google.com with ESMTPS id o204si3014007oib.40.2016.09.22.12.49.30
        for <linux-mm@kvack.org>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
        Thu, 22 Sep 2016 12:49:31 -0700 (PDT)
Subject: Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when
 SEV is active
References: <147190820782.9523.4967724730957229273.stgit@brijesh-build-machine>
 <147190832511.9523.10850626471583956499.stgit@brijesh-build-machine>
 <20160922143545.3kl7khff6vqk7b2t@pd.tnic>
 <464461b7-1efb-0af1-dd3e-eb919a2578e9@redhat.com>
 <20160922145947.52v42l7p7dl7u3r4@pd.tnic>
 <938ee0cf-85e6-eefa-7df9-9d5e09ed7a9d@redhat.com>
 <20160922170718.34d4ppockeurrg25@pd.tnic>
 <1a22afee-a146-414c-6f58-66a942f7aab9@amd.com>
 <20160922191138.lnp4ac3cfkiebjo3@pd.tnic>
From: Tom Lendacky <thomas.lendacky@amd.com>
Message-ID: <e162ecbf-f0b5-9a38-fdf6-7f097e20c5ad@amd.com>
Date: Thu, 22 Sep 2016 14:49:22 -0500
MIME-Version: 1.0
In-Reply-To: <20160922191138.lnp4ac3cfkiebjo3@pd.tnic>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.org>
To: Borislav Petkov <bp@suse.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Brijesh Singh <brijesh.singh@amd.com>, simon.guinot@sequanux.org, linux-efi@vger.kernel.org, kvm@vger.kernel.org, rkrcmar@redhat.com, matt@codeblueprint.co.uk, linus.walleij@linaro.org, linux-mm@kvack.org, paul.gortmaker@windriver.com, hpa@zytor.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, mingo@redhat.com, msalter@redhat.com, ross.zwisler@linux.intel.com, dyoung@redhat.com, jroedel@suse.de, keescook@chromium.org, toshi.kani@hpe.com, mathieu.desnoyers@efficios.com, devel@linuxdriverproject.org, 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, linux-crypto@vger.kernel.org, akpm@linux-foundation.org, davem@davemloft.net

On 09/22/2016 02:11 PM, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 02:04:27PM -0500, Tom Lendacky wrote:
>> That's not what I mean here.  If the BIOS sets the SMEE bit in the
>> SYS_CFG msr then, even if the encryption bit is never used, there is
>> still a reduction in physical address space.
> 
> I thought that reduction is the reservation of bits for the SME mask.
> 
> What other reduction is there?

There is a reduction in physical address space for the SME mask and the
bits used to aid in identifying the ASID associated with the memory
request. This allows for the memory controller to determine the key to
be used for the encryption operation (host/hypervisor key vs. an SEV
guest key).

Thanks,
Tom

> 
>> Transparent SME (TSME) will be a BIOS option that will result in the
>> memory controller performing encryption no matter what. In this case
>> all data will be encrypted without a reduction in physical address
>> space.
> 
> Now I'm confused: aren't we reducing the address space with the SME
> mask?
> 
> Or what reduction do you mean?
> 

--
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>