From: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>
To: Kai Huang <kai.huang@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Andy Lutomirski <luto@kernel.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
X86 ML <x86@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Borislav Petkov <bp@alien8.de>,
Peter Zijlstra <peterz@infradead.org>,
David Howells <dhowells@redhat.com>,
Kees Cook <keescook@chromium.org>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
Alison Schofield <alison.schofield@intel.com>,
Linux-MM <linux-mm@kvack.org>, kvm list <kvm@vger.kernel.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH, RFC 45/62] mm: Add the encrypt_mprotect() system call for MKTME
Date: Tue, 18 Jun 2019 01:34:06 +0000 [thread overview]
Message-ID: <cbbc6af7-36f8-a81f-48b1-2ad4eefc2417@amd.com> (raw)
In-Reply-To: <1560815959.5187.57.camel@linux.intel.com>
T24gNi8xNy8xOSA2OjU5IFBNLCBLYWkgSHVhbmcgd3JvdGU6DQo+IE9uIE1vbiwgMjAxOS0wNi0x
NyBhdCAxMToyNyAtMDcwMCwgRGF2ZSBIYW5zZW4gd3JvdGU6DQo+PiBUb20gTGVuZGFja3ksIGNv
dWxkIHlvdSB0YWtlIGEgbG9vayBkb3duIGluIHRoZSBtZXNzYWdlIHRvIHRoZSB0YWxrIG9mDQo+
PiBTRVY/ICBJIHdhbnQgdG8gbWFrZSBzdXJlIEknbSBub3QgbWlzcmVwcmVzZW50aW5nIHdoYXQg
aXQgZG9lcyB0b2RheS4NCg0KU29ycnksIEknbSB0cmF2ZWxpbmcgdGhpcyB3ZWVrLCBzbyByZXNw
b25zZXMgd2lsbCBiZSBkZWxheWVkLi4uDQoNCj4+IC4uLg0KPj4NCj4+DQo+Pj4+IEkgYWN0dWFs
bHkgZG9uJ3QgY2FyZSBhbGwgdGhhdCBtdWNoIHdoaWNoIG9uZSB3ZSBlbmQgdXAgd2l0aC4gIEl0
J3Mgbm90DQo+Pj4+IGxpa2UgdGhlIGV4dHJhIHN5c2NhbGwgaW4gdGhlIHNlY29uZCBvcHRpb25z
IG1lYW5zIG11Y2guDQo+Pj4NCj4+PiBUaGUgYmVuZWZpdCBvZiB0aGUgc2Vjb25kIG9uZSBpcyB0
aGF0LCBpZiBzeXNfZW5jcnlwdCBpcyBhYnNlbnQsIGl0DQo+Pj4ganVzdCB3b3Jrcy4gIEluIHRo
ZSBmaXJzdCBtb2RlbCwgcHJvZ3JhbXMgbmVlZCBhIGZhbGxiYWNrIGJlY2F1c2UNCj4+PiB0aGV5
J2xsIHNlZ2ZhdWx0IG9mIG1wcm90ZWN0X2VuY3J5cHQoKSBnZXRzIEVOT1NZUy4NCj4+DQo+PiBX
ZWxsLCBieSB0aGUgdGltZSB0aGV5IGdldCBoZXJlLCB0aGV5IHdvdWxkIGhhdmUgYWxyZWFkeSBo
YWQgdG8gYWxsb2NhdGUNCj4+IGFuZCBzZXQgdXAgdGhlIGVuY3J5cHRpb24ga2V5LiAgSSBkb24n
dCB0aGluayB0aGlzIHdvdWxkIHJlYWxseSBiZSB0aGUNCj4+ICJub3JtYWwiIG1hbGxvYygpIHBh
dGgsIGZvciBpbnN0YW5jZS4NCj4+DQo+Pj4+ICBIb3cgZG8gd2UNCj4+Pj4gZXZlbnR1YWxseSBz
dGFjayBpdCBvbiB0b3Agb2YgcGVyc2lzdGVudCBtZW1vcnkgZmlsZXN5c3RlbXMgb3IgRGV2aWNl
DQo+Pj4+IERBWD8NCj4+Pg0KPj4+IEhvdyBkbyB3ZSBzdGFjayBhbm9ueW1vdXMgbWVtb3J5IG9u
IHRvcCBvZiBwZXJzaXN0ZW50IG1lbW9yeSBvciBEZXZpY2UNCj4+PiBEQVg/ICBJJ20gY29uZnVz
ZWQuDQo+Pg0KPj4gSWYgb3VyIGludGVyZmFjZSB0byBNS1RNRSBpczoNCj4+DQo+PiAJZmQgPSBv
cGVuKCIvZGV2L21rdG1lIik7DQo+PiAJcHRyID0gbW1hcChmZCk7DQo+Pg0KPj4gVGhlbiBpdCdz
IGhhcmQgdG8gY29tYmluZSB3aXRoIGFuIGludGVyZmFjZSB3aGljaCBpczoNCj4+DQo+PiAJZmQg
PSBvcGVuKCIvZGV2L2RheDEyMyIpOw0KPj4gCXB0ciA9IG1tYXAoZmQpOw0KPj4NCj4+IFdoZXJl
IGlmIHdlIGhhdmUgc29tZXRoaW5nIGxpa2UgbXByb3RlY3QoKSAob3IgbWFkdmlzZSgpIG9yIHNv
bWV0aGluZw0KPj4gZWxzZSB0YWtpbmcgcG9pbnRlciksIHdlIGNhbiBqdXN0IGRvOg0KPj4NCj4+
IAlmZCA9IG9wZW4oIi9kZXYvYW55dGhpbmc5ODciKTsNCj4+IAlwdHIgPSBtbWFwKGZkKTsNCj4+
IAlzeXNfZW5jcnlwdChwdHIpOw0KPj4NCj4+IE5vdywgd2UgbWlnaHQgbm90ICpkbyogaXQgdGhh
dCB3YXkgZm9yIGRheCwgZm9yIGluc3RhbmNlLCBidXQgSSdtIGp1c3QNCj4+IHNheWluZyB0aGF0
IGlmIHdlIGdvIHRoZSAvZGV2L21rdG1lIHJvdXRlLCB3ZSBuZXZlciBnZXQgYSBjaG9pY2UuDQo+
Pg0KPj4+IEkgdGhpbmsgdGhhdCwgaW4gdGhlIGxvbmcgcnVuLCB3ZSdyZSBnb2luZyB0byBoYXZl
IHRvIGVpdGhlciBleHBhbmQNCj4+PiB0aGUgY29yZSBtbSdzIGNvbmNlcHQgb2Ygd2hhdCAibWVt
b3J5IiBpcyBvciBqdXN0IGhhdmUgYSB3aG9sZQ0KPj4+IHBhcmFsbGVsIHNldCBvZiBtZWNoYW5p
c21zIGZvciBtZW1vcnkgdGhhdCBkb2Vzbid0IHdvcmsgbGlrZSBtZW1vcnkuDQo+Pg0KPj4gLi4u
DQo+Pj4gSSBleHBlY3QgdGhhdCBzb21lIGRheSBub3JtYWwgbWVtb3J5IHdpbGwgIGJlIGFibGUg
dG8gYmUgcmVwdXJwb3NlZCBhcw0KPj4+IFNHWCBwYWdlcyBvbiB0aGUgZmx5LCBhbmQgdGhhdCB3
aWxsIGFsc28gbG9vayBhIGxvdCBtb3JlIGxpa2UgU0VWIG9yDQo+Pj4gWFBGTyB0aGFuIGxpa2Ug
dGhlIHRoaXMgbW9kZWwgb2YgTUtUTUUuDQo+Pg0KPj4gSSB0aGluayB5b3UncmUgZHJhd2luZyB0
aGUgbGluZSBhdCBwYWdlcyB3aGVyZSB0aGUga2VybmVsIGNhbiBtYW5hZ2UNCj4+IGNvbnRlbnRz
IHZzLiBub3QgbWFuYWdlIGNvbnRlbnRzLiAgSSdtIG5vdCBzdXJlIHRoYXQncyB0aGUgcmlnaHQN
Cj4+IGRpc3RpbmN0aW9uIHRvIG1ha2UsIHRob3VnaC4gIFRoZSB0aGluZyB0aGF0IGlzIGltcG9y
dGFudCBpcyB3aGV0aGVyIHRoZQ0KPj4ga2VybmVsIGNhbiBtYW5hZ2UgdGhlIGxpZmV0aW1lIGFu
ZCBsb2NhdGlvbiBvZiB0aGUgZGF0YSBpbiB0aGUgcGFnZS4NCj4+DQo+PiBCYXNpY2FsbHk6IENh
biB0aGUga2VybmVsIGNob29zZSB3aGVyZSB0aGUgcGFnZSBjb21lcyBmcm9tIGFuZCBnZXQgdGhl
DQo+PiBwYWdlIGJhY2sgd2hlbiBpdCB3YW50cz8NCj4+DQo+PiBJIHJlYWxseSBkb24ndCBsaWtl
IHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoaW5ncyBsaWtlIHdpdGggU0VWIG9yIHdpdGgNCj4+IEtW
TSBkaXJlY3QgZGV2aWNlIGFzc2lnbm1lbnQgd2hlcmUgdGhlIHBoeXNpY2FsIGxvY2F0aW9uIGlz
IHF1aXRlIGxvY2tlZA0KPj4gZG93biBhbmQgdGhlIGtlcm5lbCByZWFsbHkgY2FuJ3QgbWFuYWdl
IHRoZSBtZW1vcnkuICBJJ20gdHJ5aW5nIHJlYWxseQ0KPj4gaGFyZCB0byBtYWtlIHN1cmUgZnV0
dXJlIGhhcmR3YXJlIGlzIG1vcmUgcGVybWlzc2l2ZSBhYm91dCBzdWNoIHRoaW5ncy4NCj4+ICBN
eSBob3BlIGlzIHRoYXQgdGhlc2UgYXJlIGEgdGVtcG9yYXJ5IGJsaXAgYW5kIG5vdCB0aGUgbmV3
IG5vcm1hbC4NCj4+DQo+Pj4gU28sIGlmIHdlIHVwc3RyZWFtIE1LVE1FIGFzIGFub255bW91cyBt
ZW1vcnkgd2l0aCBhIG1hZ2ljIGNvbmZpZw0KPj4+IHN5c2NhbGwsIEkgcHJlZGljdCB0aGF0LCBp
biBhIGZldyB5ZWFycywgaXQgd2lsbCBiZSBlbmQgdXAgaW5oZXJpdGluZw0KPj4+IGFsbCBkb3du
c2lkZXMgb2YgYm90aCBhcHByb2FjaGVzIHdpdGggZmV3IG9mIHRoZSB1cHNpZGVzLiAgUHJvZ3Jh
bXMNCj4+PiBsaWtlIFFFTVUgd2lsbCBuZWVkIHRvIGxlYXJuIHRvIG1hbmlwdWxhdGUgcGFnZXMg
dGhhdCBjYW4ndCBiZQ0KPj4+IGFjY2Vzc2VkIG91dHNpZGUgdGhlIFZNIHdpdGhvdXQgc3BlY2lh
bCBWTSBidXktaW4sIHNvIHRoZSBmYWN0IHRoYXQNCj4+PiBNS1RNRSBwYWdlcyBhcmUgZnVsbHkg
ZnVuY3Rpb25hbCBhbmQgY2FuIGJlIEdVUC1lZCB3b24ndCBiZSB2ZXJ5DQo+Pj4gdXNlZnVsLiAg
QW5kIHRoZSBWTSB3aWxsIGxlYXJuIGFib3V0IGFsbCB0aGVzZSB0aGluZ3MsIGJ1dCBNS1RNRSB3
b24ndA0KPj4+IHJlYWxseSBmaXQgaW4uDQo+Pg0KPj4gS2FpIEh1YW5nICh3aG8gaXMgb24gY2Mp
IGhhcyBiZWVuIGRvaW5nIHRoZSBRRU1VIGVuYWJsaW5nIGFuZCBtaWdodCB3YW50DQo+PiB0byB3
ZWlnaCBpbi4gIEknZCBhbHNvIGxvdmUgdG8gaGVhciBmcm9tIHRoZSBBTUQgZm9sa3MgaW4gY2Fz
ZSBJJ20gbm90DQo+PiBncm9ra2luZyBzb21lIGFzcGVjdCBvZiBTRVYuDQo+Pg0KPj4gQnV0LCBt
eSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQsIGV2ZW4gdG9kYXksIG5laXRoZXIgUUVNVSBub3IgdGhl
IGtlcm5lbA0KPj4gY2FuIHNlZSBTRVYtZW5jcnlwdGVkIGd1ZXN0IG1lbW9yeS4gIFNvIFFFTVUg
c2hvdWxkIGFscmVhZHkgdW5kZXJzdGFuZA0KPj4gaG93IHRvIG5vdCBpbnRlcmFjdCB3aXRoIGd1
ZXN0IG1lbW9yeS4gIEkgX2Fzc3VtZV8gaXQncyBhbHNvIGFscmVhZHkNCj4+IGRvaW5nIHRoaXMg
d2l0aCBhbm9ueW1vdXMgbWVtb3J5LCB3aXRob3V0IG5lZWRpbmcgL2Rldi9zbWUgb3Igc29tZXRo
aW5nLg0KPiANCj4gQ29ycmVjdCBuZWl0aGVyIFFlbXUgbm9yIGtlcm5lbCBjYW4gc2VlIFNFVi1l
bmNyeXB0ZWQgZ3Vlc3QgbWVtb3J5LiBRZW11IHJlcXVpcmVzIGd1ZXN0J3MNCj4gY29vcGVyYXRp
b24gd2hlbiBpdCBuZWVkcyB0byBpbnRlcmFjdHMgd2l0aCBndWVzdCwgaS5lLiB0byBzdXBwb3J0
IHZpcnR1YWwgRE1BIChvZiB2aXJ0dWFsIGRldmljZXMNCj4gaW4gU0VWLWd1ZXN0KSwgcWVtdSBy
ZXF1aXJlcyBTRVYtZ3Vlc3QgdG8gc2V0dXAgYm91bmNlIGJ1ZmZlciAod2hpY2ggd2lsbCBub3Qg
YmUgU0VWLWVuY3J5cHRlZA0KPiBtZW1vcnksIGJ1dCBzaGFyZWQgbWVtb3J5IGNhbiBiZSBhY2Nl
c3NlZCBmcm9tIGhvc3Qgc2lkZSB0b28pLCBzbyB0aGF0IGd1ZXN0IGtlcm5lbCBjYW4gY29weSBE
TUENCj4gZGF0YSBmcm9tIGJvdW5jZSBidWZmZXIgdG8gaXRzIG93biBTRVYtZW5jcnlwdGVkIG1l
bW9yeSBhZnRlciBxZW11L2hvc3Qga2VybmVsIHB1dHMgRE1BIGRhdGEgdG8NCj4gYm91bmNlIGJ1
ZmZlci4NCg0KVGhhdCBpcyBjb3JyZWN0LiBhbiBTRVYgZ3Vlc3QgbXVzdCB1c2UgdW4tZW5jcnlw
dGVkIG1lbW9yeSBpZiBpdCB3aXNoZXMNCmZvciB0aGUgaHlwZXJ2aXNvciB0byBiZSBhYmxlIHRv
IHNlZSBpdC4gQWxzbywgdG8gc3VwcG9ydCBETUEgaW50byB0aGUNCmd1ZXN0LCB0aGUgdGFyZ2V0
IG1lbW9yeSBtdXN0IGJlIHVuLWVuY3J5cHRlZCwgd2hpY2ggU0VWIGRvZXMgdGhyb3VnaCB0aGUN
CkRNQSBhcGkgYW5kIFNXSU9UTEIuDQoNClNNRSBtdXN0IGFsc28gdXNlIGJvdW5jZSBidWZmZXJz
IGlmIHRoZSBkZXZpY2UgZG9lcyBub3Qgc3VwcG9ydCA0OC1iaXQNCkRNQSwgc2luY2UgdGhlIGVu
Y3J5cHRpb24gYml0IGlzIGJpdCA0Ny4gQW55IGRldmljZSBzdXBwb3J0aW5nIERNQSBhYm92ZQ0K
dGhlIGVuY3J5cHRpb24gYml0IHBvc2l0aW9uIGNhbiBwZXJmb3JtIERNQSB3aXRob3V0IGJvdW5j
ZSBidWZmZXJzIHVuZGVyDQpTTUUuDQoNCj4gDQo+IEFuZCB5ZXMgZnJvbSBteSByZWFkaW5nIChi
ZXR0ZXIgdG8gaGF2ZSBBTUQgZ3V5cyB0byBjb25maXJtKSBTRVYgZ3Vlc3QgdXNlcyBhbm9ueW1v
dXMgbWVtb3J5LCBidXQgaXQNCj4gYWxzbyBwaW5zIGFsbCBndWVzdCBtZW1vcnkgKGJ5IGNhbGxp
bmcgR1VQIGZyb20gS1ZNIC0tIFNFViBzcGVjaWZpY2FsbHkgaW50cm9kdWNlZCAyIEtWTSBpb2N0
bHMgZm9yDQo+IHRoaXMgcHVycG9zZSksIHNpbmNlIFNFViBhcmNoaXRlY3R1cmFsbHkgY2Fubm90
IHN1cHBvcnQgc3dhcHBpbmcsIG1pZ3JhaXRvbiBvZiBTRVYtZW5jcnlwdGVkIGd1ZXN0DQo+IG1l
bW9yeSwgYmVjYXVzZSBTTUUvU0VWIGFsc28gdXNlcyBwaHlzaWNhbCBhZGRyZXNzIGFzICJ0d2Vh
ayIsIGFuZCB0aGVyZSdzIG5vIHdheSB0aGF0IGtlcm5lbCBjYW4NCj4gZ2V0IG9yIHVzZSBTRVYt
Z3Vlc3QncyBtZW1vcnkgZW5jcnlwdGlvbiBrZXkuIEluIG9yZGVyIHRvIHN3YXAvbWlncmF0ZSBT
RVYtZ3Vlc3QgbWVtb3J5LCB3ZSBuZWVkIFNHWA0KPiBFUEMgZXZpY3Rpb24vcmVsb2FkIHNpbWls
YXIgdGhpbmcsIHdoaWNoIFNFViBkb2Vzbid0IGhhdmUgdG9kYXkuDQoNClllcywgYWxsIHRoZSBn
dWVzdCBtZW1vcnkgaXMgY3VycmVudGx5IHBpbm5lZCBieSBjYWxsaW5nIEdVUCB3aGVuIGNyZWF0
aW5nDQphbiBTRVYgZ3Vlc3QuIFRoaXMgaXMgdG8gcHJldmVudCBwYWdlIG1pZ3JhdGlvbiBieSB0
aGUga2VybmVsLiBIb3dldmVyLA0KdGhlIHN1cHBvcnQgdG8gZG8gcGFnZSBtaWdyYXRpb24gaXMg
YXZhaWxhYmxlIGluIHRoZSAwLjE3IHZlcnNpb24gb2YgdGhlDQpTRVYgQVBJIHZpYSB0aGUgQ09Q
WSBjb21tbWFuZC4gVGhlIENPUFkgY29tbWFubmQgYWxsb3dzIGZvciBjb3B5aW5nIG9mDQphbiBl
bmNyeXB0ZWQgcGFnZSBmcm9tIG9uZSBsb2NhdGlvbiB0byBhbm90aGVyIHZpYSB0aGUgUFNQLiBU
aGUgc3VwcG9ydA0KZm9yIHRoaXMgaXMgbm90IHlldCBpbiB0aGUgTGludXgga2VybmVsLCBidXQg
d2UgYXJlIHdvcmtpbmcgb24gaXQuIFRoaXMNCndvdWxkIHJlbW92ZSB0aGUgcmVxdWlyZW1lbnQg
b2YgaGF2aW5nIHRvIHBpbiB0aGUgZ3Vlc3QgbWVtb3J5Lg0KDQpUaGUgU0VWIEFQSSBhbHNvIHN1
cHBvcnRzIG1pZ3JhdGlvbiBvZiBtZW1vcnkgdmlhIHRoZSBTRU5EXyogYW5kIFJFQ0VJVkVfKg0K
QVBJcyB0byBzdXBwb3J0IGxpdmUgbWlncmF0aW9uLg0KDQpTd2FwcGluZywgaG93ZXZlciwgaXMg
bm90IHlldCBzdXBwb3J0ZWQuDQoNClRoYW5rcywNClRvbQ0KDQo+IA0KPiBGcm9tIHRoaXMgcGVy
c3BlY3RpdmUsIEkgdGhpbmsgZHJpdmVyIHByb3Bvc2FsIGtpbmRhIG1ha2VzIHNlbnNlIHNpbmNl
IHdlIGFscmVhZHkgaGF2ZSBzZWN1cml0eQ0KPiBmZWF0dXJlIHdoaWNoIHVzZXMgbm9ybWFsIG1l
bW9yeSBzb21lIGtpbmQgbGlrZSAiZGV2aWNlIG1lbW9yeSIgKG5vIHN3YXAsIG5vIG1pZ3JhdGlv
biwgZXRjKSwgc28gaXQNCj4gbWFrZXMgc2Vuc2UgdGhhdCBNS1RNRSBqdXN0IGZvbGxvd3MgdGhh
dCAoYWx0aG91Z2ggZnJvbSBIVyBNS1RNRSBjYW4gc3VwcG9ydCBzd2FwLCBwYWdlIG1pZ3JhdGlv
biwNCj4gZXRjKS4gVGhlIGRvd25zaWRlIG9mIGRyaXZlciBwcm9wb3NhbCBmb3IgTUtUTUUgSSB0
aGluayBpcywgbGlrZSBEYXZlIG1lbnRpb25lZCwgaXQncyBoYXJkIChvciBub3QNCj4gc3VyZSB3
aGV0aGVyIGl0IGlzIHBvc3NpYmxlKSB0byBleHRlbmQgdG8gc3VwcG9ydCBOVkRJTU0gKGFuZCBm
aWxlIGJhY2tlZCBndWVzdCBtZW1vcnkpLCBzaW5jZSBmb3INCj4gdmlydHVhbCBOVkRJTU0sIFFl
bXUgbmVlZHMgdG8gY2FsbCBtbWFwIGFnYWluc3QgZmQgb2YgTlZESU1NLg0KPiANCj4gVGhhbmtz
LA0KPiAtS2FpDQo+IA0K
WARNING: multiple messages have this Message-ID (diff)
From: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>
To: Kai Huang <kai.huang@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Andy Lutomirski <luto@kernel.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
X86 ML <x86@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Borislav Petkov <bp@alien8.de>,
Peter Zijlstra <peterz@infradead.org>,
David Howells <dhowells@redhat.com>,
Kees Cook <keescook@chromium.org>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
Alison Schofield <alison.schofield@intel.com>,
Linux-MM <linux-mm@kvack.org>, kvm list <kvm@vger.kernel.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH, RFC 45/62] mm: Add the encrypt_mprotect() system call for MKTME
Date: Tue, 18 Jun 2019 01:34:06 +0000 [thread overview]
Message-ID: <cbbc6af7-36f8-a81f-48b1-2ad4eefc2417@amd.com> (raw)
In-Reply-To: <1560815959.5187.57.camel@linux.intel.com>
On 6/17/19 6:59 PM, Kai Huang wrote:
> On Mon, 2019-06-17 at 11:27 -0700, Dave Hansen wrote:
>> Tom Lendacky, could you take a look down in the message to the talk of
>> SEV? I want to make sure I'm not misrepresenting what it does today.
Sorry, I'm traveling this week, so responses will be delayed...
>> ...
>>
>>
>>>> I actually don't care all that much which one we end up with. It's not
>>>> like the extra syscall in the second options means much.
>>>
>>> The benefit of the second one is that, if sys_encrypt is absent, it
>>> just works. In the first model, programs need a fallback because
>>> they'll segfault of mprotect_encrypt() gets ENOSYS.
>>
>> Well, by the time they get here, they would have already had to allocate
>> and set up the encryption key. I don't think this would really be the
>> "normal" malloc() path, for instance.
>>
>>>> How do we
>>>> eventually stack it on top of persistent memory filesystems or Device
>>>> DAX?
>>>
>>> How do we stack anonymous memory on top of persistent memory or Device
>>> DAX? I'm confused.
>>
>> If our interface to MKTME is:
>>
>> fd = open("/dev/mktme");
>> ptr = mmap(fd);
>>
>> Then it's hard to combine with an interface which is:
>>
>> fd = open("/dev/dax123");
>> ptr = mmap(fd);
>>
>> Where if we have something like mprotect() (or madvise() or something
>> else taking pointer), we can just do:
>>
>> fd = open("/dev/anything987");
>> ptr = mmap(fd);
>> sys_encrypt(ptr);
>>
>> Now, we might not *do* it that way for dax, for instance, but I'm just
>> saying that if we go the /dev/mktme route, we never get a choice.
>>
>>> I think that, in the long run, we're going to have to either expand
>>> the core mm's concept of what "memory" is or just have a whole
>>> parallel set of mechanisms for memory that doesn't work like memory.
>>
>> ...
>>> I expect that some day normal memory will be able to be repurposed as
>>> SGX pages on the fly, and that will also look a lot more like SEV or
>>> XPFO than like the this model of MKTME.
>>
>> I think you're drawing the line at pages where the kernel can manage
>> contents vs. not manage contents. I'm not sure that's the right
>> distinction to make, though. The thing that is important is whether the
>> kernel can manage the lifetime and location of the data in the page.
>>
>> Basically: Can the kernel choose where the page comes from and get the
>> page back when it wants?
>>
>> I really don't like the current state of things like with SEV or with
>> KVM direct device assignment where the physical location is quite locked
>> down and the kernel really can't manage the memory. I'm trying really
>> hard to make sure future hardware is more permissive about such things.
>> My hope is that these are a temporary blip and not the new normal.
>>
>>> So, if we upstream MKTME as anonymous memory with a magic config
>>> syscall, I predict that, in a few years, it will be end up inheriting
>>> all downsides of both approaches with few of the upsides. Programs
>>> like QEMU will need to learn to manipulate pages that can't be
>>> accessed outside the VM without special VM buy-in, so the fact that
>>> MKTME pages are fully functional and can be GUP-ed won't be very
>>> useful. And the VM will learn about all these things, but MKTME won't
>>> really fit in.
>>
>> Kai Huang (who is on cc) has been doing the QEMU enabling and might want
>> to weigh in. I'd also love to hear from the AMD folks in case I'm not
>> grokking some aspect of SEV.
>>
>> But, my understanding is that, even today, neither QEMU nor the kernel
>> can see SEV-encrypted guest memory. So QEMU should already understand
>> how to not interact with guest memory. I _assume_ it's also already
>> doing this with anonymous memory, without needing /dev/sme or something.
>
> Correct neither Qemu nor kernel can see SEV-encrypted guest memory. Qemu requires guest's
> cooperation when it needs to interacts with guest, i.e. to support virtual DMA (of virtual devices
> in SEV-guest), qemu requires SEV-guest to setup bounce buffer (which will not be SEV-encrypted
> memory, but shared memory can be accessed from host side too), so that guest kernel can copy DMA
> data from bounce buffer to its own SEV-encrypted memory after qemu/host kernel puts DMA data to
> bounce buffer.
That is correct. an SEV guest must use un-encrypted memory if it wishes
for the hypervisor to be able to see it. Also, to support DMA into the
guest, the target memory must be un-encrypted, which SEV does through the
DMA api and SWIOTLB.
SME must also use bounce buffers if the device does not support 48-bit
DMA, since the encryption bit is bit 47. Any device supporting DMA above
the encryption bit position can perform DMA without bounce buffers under
SME.
>
> And yes from my reading (better to have AMD guys to confirm) SEV guest uses anonymous memory, but it
> also pins all guest memory (by calling GUP from KVM -- SEV specifically introduced 2 KVM ioctls for
> this purpose), since SEV architecturally cannot support swapping, migraiton of SEV-encrypted guest
> memory, because SME/SEV also uses physical address as "tweak", and there's no way that kernel can
> get or use SEV-guest's memory encryption key. In order to swap/migrate SEV-guest memory, we need SGX
> EPC eviction/reload similar thing, which SEV doesn't have today.
Yes, all the guest memory is currently pinned by calling GUP when creating
an SEV guest. This is to prevent page migration by the kernel. However,
the support to do page migration is available in the 0.17 version of the
SEV API via the COPY commmand. The COPY commannd allows for copying of
an encrypted page from one location to another via the PSP. The support
for this is not yet in the Linux kernel, but we are working on it. This
would remove the requirement of having to pin the guest memory.
The SEV API also supports migration of memory via the SEND_* and RECEIVE_*
APIs to support live migration.
Swapping, however, is not yet supported.
Thanks,
Tom
>
> From this perspective, I think driver proposal kinda makes sense since we already have security
> feature which uses normal memory some kind like "device memory" (no swap, no migration, etc), so it
> makes sense that MKTME just follows that (although from HW MKTME can support swap, page migration,
> etc). The downside of driver proposal for MKTME I think is, like Dave mentioned, it's hard (or not
> sure whether it is possible) to extend to support NVDIMM (and file backed guest memory), since for
> virtual NVDIMM, Qemu needs to call mmap against fd of NVDIMM.
>
> Thanks,
> -Kai
>
next prev parent reply other threads:[~2019-06-18 1:34 UTC|newest]
Thread overview: 324+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-08 14:43 [PATCH, RFC 00/62] Intel MKTME enabling Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 01/62] mm: Do no merge VMAs with different encryption KeyIDs Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 02/62] mm: Add helpers to setup zero page mappings Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-29 7:21 ` Mike Rapoport
2019-05-29 7:21 ` Mike Rapoport
2019-05-08 14:43 ` [PATCH, RFC 03/62] mm/ksm: Do not merge pages with different KeyIDs Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-10 18:07 ` Dave Hansen
2019-05-10 18:07 ` Dave Hansen
2019-05-13 14:27 ` Kirill A. Shutemov
2019-05-13 14:27 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 04/62] mm/page_alloc: Unify alloc_hugepage_vma() Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 05/62] mm/page_alloc: Handle allocation for encrypted memory Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-29 7:21 ` Mike Rapoport
2019-05-29 7:21 ` Mike Rapoport
2019-05-29 12:47 ` Kirill A. Shutemov
2019-05-29 12:47 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 06/62] mm/khugepaged: Handle encrypted pages Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 07/62] x86/mm: Mask out KeyID bits from page table entry pfn Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 08/62] x86/mm: Introduce variables to store number, shift and mask of KeyIDs Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 09/62] x86/mm: Preserve KeyID on pte_modify() and pgprot_modify() Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-06-14 9:15 ` Peter Zijlstra
2019-06-14 9:15 ` Peter Zijlstra
2019-06-14 13:03 ` Kirill A. Shutemov
2019-06-14 13:03 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 10/62] x86/mm: Detect MKTME early Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 11/62] x86/mm: Add a helper to retrieve KeyID for a page Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 12/62] x86/mm: Add a helper to retrieve KeyID for a VMA Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 13/62] x86/mm: Add hooks to allocate and free encrypted pages Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-06-14 9:34 ` Peter Zijlstra
2019-06-14 9:34 ` Peter Zijlstra
2019-06-14 11:04 ` Peter Zijlstra
2019-06-14 11:04 ` Peter Zijlstra
2019-06-14 13:28 ` Kirill A. Shutemov
2019-06-14 13:28 ` Kirill A. Shutemov
2019-06-14 13:43 ` Peter Zijlstra
2019-06-14 13:43 ` Peter Zijlstra
2019-06-14 22:41 ` Kirill A. Shutemov
2019-06-14 22:41 ` Kirill A. Shutemov
2019-06-17 9:25 ` Peter Zijlstra
2019-06-17 9:25 ` Peter Zijlstra
2019-06-14 13:14 ` Kirill A. Shutemov
2019-06-14 13:14 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 14/62] x86/mm: Map zero pages into encrypted mappings correctly Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 15/62] x86/mm: Rename CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 16/62] x86/mm: Allow to disable MKTME after enumeration Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 17/62] x86/mm: Calculate direct mapping size Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 18/62] x86/mm: Implement syncing per-KeyID direct mappings Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-06-14 9:51 ` Peter Zijlstra
2019-06-14 9:51 ` Peter Zijlstra
2019-06-14 22:43 ` Kirill A. Shutemov
2019-06-14 22:43 ` Kirill A. Shutemov
2019-06-17 9:27 ` Peter Zijlstra
2019-06-17 9:27 ` Peter Zijlstra
2019-06-17 14:43 ` Kirill A. Shutemov
2019-06-17 14:43 ` Kirill A. Shutemov
2019-06-17 14:51 ` Peter Zijlstra
2019-06-17 14:51 ` Peter Zijlstra
2019-06-17 15:17 ` Kirill A. Shutemov
2019-06-17 15:17 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 19/62] x86/mm: Handle encrypted memory in page_to_virt() and __pa() Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-06-14 11:10 ` Peter Zijlstra
2019-06-14 11:10 ` Peter Zijlstra
2019-05-08 14:43 ` [PATCH, RFC 20/62] mm/page_ext: Export lookup_page_ext() symbol Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-06-14 11:12 ` Peter Zijlstra
2019-06-14 11:12 ` Peter Zijlstra
2019-06-14 22:44 ` Kirill A. Shutemov
2019-06-14 22:44 ` Kirill A. Shutemov
2019-06-17 9:30 ` Peter Zijlstra
2019-06-17 9:30 ` Peter Zijlstra
2019-06-17 11:01 ` Kai Huang
2019-06-17 11:01 ` Kai Huang
2019-06-17 11:01 ` Kai Huang
2019-06-17 11:13 ` Huang, Kai
2019-06-17 11:13 ` Huang, Kai
2019-05-08 14:43 ` [PATCH, RFC 21/62] mm/rmap: Clear vma->anon_vma on unlink_anon_vmas() Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 22/62] x86/pconfig: Set a valid encryption algorithm for all MKTME commands Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 23/62] keys/mktme: Introduce a Kernel Key Service for MKTME Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 24/62] keys/mktme: Preparse the MKTME key payload Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 25/62] keys/mktme: Instantiate and destroy MKTME keys Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 26/62] keys/mktme: Move the MKTME payload into a cache aligned structure Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-06-14 11:35 ` Peter Zijlstra
2019-06-14 11:35 ` Peter Zijlstra
2019-06-14 17:10 ` Alison Schofield
2019-06-14 17:10 ` Alison Schofield
2019-05-08 14:43 ` [PATCH, RFC 27/62] keys/mktme: Strengthen the entropy of CPU generated MKTME keys Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 28/62] keys/mktme: Set up PCONFIG programming targets for " Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 29/62] keys/mktme: Program MKTME keys into the platform hardware Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 30/62] keys/mktme: Set up a percpu_ref_count for MKTME keys Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 31/62] keys/mktme: Require CAP_SYS_RESOURCE capability " Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 32/62] keys/mktme: Store MKTME payloads if cmdline parameter allows Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 33/62] acpi: Remove __init from acpi table parsing functions Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 34/62] acpi/hmat: Determine existence of an ACPI HMAT Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 35/62] keys/mktme: Require ACPI HMAT to register the MKTME Key Service Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 36/62] acpi/hmat: Evaluate topology presented in ACPI HMAT for MKTME Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 37/62] keys/mktme: Do not allow key creation in unsafe topologies Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 38/62] keys/mktme: Support CPU hotplug for MKTME key service Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:43 ` [PATCH, RFC 39/62] keys/mktme: Find new PCONFIG targets during memory hotplug Kirill A. Shutemov
2019-05-08 14:43 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 40/62] keys/mktme: Program new PCONFIG targets with MKTME keys Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 41/62] keys/mktme: Support memory hotplug for " Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 42/62] mm: Generalize the mprotect implementation to support extensions Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 43/62] syscall/x86: Wire up a system call for MKTME encryption keys Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-29 7:21 ` Mike Rapoport
2019-05-29 7:21 ` Mike Rapoport
2019-05-29 18:12 ` Alison Schofield
2019-05-29 18:12 ` Alison Schofield
2019-05-08 14:44 ` [PATCH, RFC 44/62] x86/mm: Set KeyIDs in encrypted VMAs for MKTME Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-06-14 11:44 ` Peter Zijlstra
2019-06-14 11:44 ` Peter Zijlstra
2019-06-14 17:33 ` Alison Schofield
2019-06-14 17:33 ` Alison Schofield
2019-06-14 18:26 ` Dave Hansen
2019-06-14 18:26 ` Dave Hansen
2019-06-14 18:46 ` Alison Schofield
2019-06-14 18:46 ` Alison Schofield
2019-06-14 19:11 ` Dave Hansen
2019-06-14 19:11 ` Dave Hansen
2019-06-17 9:10 ` Peter Zijlstra
2019-06-17 9:10 ` Peter Zijlstra
2019-05-08 14:44 ` [PATCH, RFC 45/62] mm: Add the encrypt_mprotect() system call " Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-06-14 11:47 ` Peter Zijlstra
2019-06-14 11:47 ` Peter Zijlstra
2019-06-14 17:35 ` Alison Schofield
2019-06-14 17:35 ` Alison Schofield
2019-06-14 11:51 ` Peter Zijlstra
2019-06-14 11:51 ` Peter Zijlstra
2019-06-15 0:32 ` Alison Schofield
2019-06-15 0:32 ` Alison Schofield
2019-06-17 9:08 ` Peter Zijlstra
2019-06-17 9:08 ` Peter Zijlstra
2019-06-17 15:07 ` Andy Lutomirski
2019-06-17 15:07 ` Andy Lutomirski
2019-06-17 15:07 ` Andy Lutomirski
2019-06-17 15:28 ` Dave Hansen
2019-06-17 15:28 ` Dave Hansen
2019-06-17 15:46 ` Andy Lutomirski
2019-06-17 15:46 ` Andy Lutomirski
2019-06-17 15:46 ` Andy Lutomirski
2019-06-17 18:27 ` Dave Hansen
2019-06-17 18:27 ` Dave Hansen
2019-06-17 19:12 ` Andy Lutomirski
2019-06-17 19:12 ` Andy Lutomirski
2019-06-17 19:12 ` Andy Lutomirski
2019-06-17 21:36 ` Dave Hansen
2019-06-17 21:36 ` Dave Hansen
2019-06-18 0:48 ` Kai Huang
2019-06-18 0:48 ` Kai Huang
2019-06-18 0:48 ` Kai Huang
2019-06-18 1:50 ` Andy Lutomirski
2019-06-18 1:50 ` Andy Lutomirski
2019-06-18 1:50 ` Andy Lutomirski
2019-06-18 2:11 ` Kai Huang
2019-06-18 2:11 ` Kai Huang
2019-06-18 2:11 ` Kai Huang
2019-06-18 4:24 ` Andy Lutomirski
2019-06-18 4:24 ` Andy Lutomirski
2019-06-18 4:24 ` Andy Lutomirski
2019-06-18 14:19 ` Dave Hansen
2019-06-18 14:19 ` Dave Hansen
2019-06-18 0:05 ` Kai Huang
2019-06-18 0:05 ` Kai Huang
2019-06-18 0:05 ` Kai Huang
2019-06-18 0:15 ` Andy Lutomirski
2019-06-18 0:15 ` Andy Lutomirski
2019-06-18 0:15 ` Andy Lutomirski
2019-06-18 1:35 ` Kai Huang
2019-06-18 1:35 ` Kai Huang
2019-06-18 1:35 ` Kai Huang
2019-06-18 1:43 ` Andy Lutomirski
2019-06-18 1:43 ` Andy Lutomirski
2019-06-18 1:43 ` Andy Lutomirski
2019-06-18 2:23 ` Kai Huang
2019-06-18 2:23 ` Kai Huang
2019-06-18 2:23 ` Kai Huang
2019-06-18 9:12 ` Peter Zijlstra
2019-06-18 9:12 ` Peter Zijlstra
2019-06-18 14:09 ` Dave Hansen
2019-06-18 14:09 ` Dave Hansen
2019-06-18 16:15 ` Kirill A. Shutemov
2019-06-18 16:15 ` Kirill A. Shutemov
2019-06-18 16:22 ` Dave Hansen
2019-06-18 16:22 ` Dave Hansen
2019-06-18 16:36 ` Andy Lutomirski
2019-06-18 16:36 ` Andy Lutomirski
2019-06-18 16:48 ` Dave Hansen
2019-06-18 16:48 ` Dave Hansen
2019-06-18 14:13 ` Dave Hansen
2019-06-18 14:13 ` Dave Hansen
2019-06-17 23:59 ` Kai Huang
2019-06-17 23:59 ` Kai Huang
2019-06-17 23:59 ` Kai Huang
2019-06-18 1:34 ` Lendacky, Thomas [this message]
2019-06-18 1:34 ` Lendacky, Thomas
2019-06-18 1:40 ` Andy Lutomirski
2019-06-18 1:40 ` Andy Lutomirski
2019-06-18 1:40 ` Andy Lutomirski
2019-06-18 2:02 ` Lendacky, Thomas
2019-06-18 2:02 ` Lendacky, Thomas
2019-06-18 4:19 ` Andy Lutomirski
2019-06-18 4:19 ` Andy Lutomirski
2019-06-18 4:19 ` Andy Lutomirski
2019-05-08 14:44 ` [PATCH, RFC 46/62] x86/mm: Keep reference counts on encrypted VMAs " Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-06-14 11:54 ` Peter Zijlstra
2019-06-14 11:54 ` Peter Zijlstra
2019-06-14 18:39 ` Alison Schofield
2019-06-14 18:39 ` Alison Schofield
2019-05-08 14:44 ` [PATCH, RFC 47/62] mm: Restrict MKTME memory encryption to anonymous VMAs Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-06-14 11:55 ` Peter Zijlstra
2019-06-14 11:55 ` Peter Zijlstra
2019-06-15 0:07 ` Alison Schofield
2019-06-15 0:07 ` Alison Schofield
2019-05-08 14:44 ` [PATCH, RFC 48/62] selftests/x86/mktme: Test the MKTME APIs Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 17:09 ` Alison Schofield
2019-05-08 17:09 ` Alison Schofield
2019-05-08 14:44 ` [PATCH, RFC 49/62] mm, x86: export several MKTME variables Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-06-14 11:56 ` Peter Zijlstra
2019-06-14 11:56 ` Peter Zijlstra
2019-06-17 3:14 ` Kai Huang
2019-06-17 3:14 ` Kai Huang
2019-06-17 3:14 ` Kai Huang
2019-06-17 7:46 ` Peter Zijlstra
2019-06-17 7:46 ` Peter Zijlstra
2019-06-17 8:39 ` Kai Huang
2019-06-17 8:39 ` Kai Huang
2019-06-17 8:39 ` Kai Huang
2019-06-17 11:25 ` Kirill A. Shutemov
2019-06-17 11:25 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 50/62] kvm, x86, mmu: setup MKTME keyID to spte for given PFN Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 51/62] iommu/vt-d: Support MKTME in DMA remapping Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-06-14 12:04 ` Peter Zijlstra
2019-06-14 12:04 ` Peter Zijlstra
2019-05-08 14:44 ` [PATCH, RFC 52/62] x86/mm: introduce common code for mem encryption Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 16:58 ` Christoph Hellwig
2019-05-08 16:58 ` Christoph Hellwig
2019-05-08 20:52 ` Jacob Pan
2019-05-08 20:52 ` Jacob Pan
2019-05-08 21:21 ` Kirill A. Shutemov
2019-05-08 21:21 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 53/62] x86/mm: Use common code for DMA memory encryption Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 54/62] x86/mm: Disable MKTME on incompatible platform configurations Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 55/62] x86/mm: Disable MKTME if not all system memory supports encryption Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 56/62] x86: Introduce CONFIG_X86_INTEL_MKTME Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 57/62] x86/mktme: Overview of Multi-Key Total Memory Encryption Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-29 7:21 ` Mike Rapoport
2019-05-29 7:21 ` Mike Rapoport
2019-05-29 18:13 ` Alison Schofield
2019-05-29 18:13 ` Alison Schofield
2019-07-14 18:16 ` Randy Dunlap
2019-07-14 18:16 ` Randy Dunlap
2019-07-15 9:02 ` Kirill A. Shutemov
2019-07-15 9:02 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 58/62] x86/mktme: Document the MKTME provided security mitigations Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 59/62] x86/mktme: Document the MKTME kernel configuration requirements Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 60/62] x86/mktme: Document the MKTME Key Service API Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 61/62] x86/mktme: Document the MKTME API for anonymous memory encryption Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-08 14:44 ` [PATCH, RFC 62/62] x86/mktme: Demonstration program using the MKTME APIs Kirill A. Shutemov
2019-05-08 14:44 ` Kirill A. Shutemov
2019-05-29 7:30 ` [PATCH, RFC 00/62] Intel MKTME enabling Mike Rapoport
2019-05-29 7:30 ` Mike Rapoport
2019-05-29 18:20 ` Alison Schofield
2019-05-29 18:20 ` Alison Schofield
2019-06-14 12:15 ` Peter Zijlstra
2019-06-14 12:15 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cbbc6af7-36f8-a81f-48b1-2ad4eefc2417@amd.com \
--to=thomas.lendacky@amd.com \
--cc=akpm@linux-foundation.org \
--cc=alison.schofield@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dhowells@redhat.com \
--cc=hpa@zytor.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=kai.huang@linux.intel.com \
--cc=keescook@chromium.org \
--cc=keyrings@vger.kernel.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.