From: "Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>
To: "tglx@linutronix.de" <tglx@linutronix.de>,
"Schofield, Alison" <alison.schofield@intel.com>,
"dhowells@redhat.com" <dhowells@redhat.com>
Cc: "kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"jmorris@namei.org" <jmorris@namei.org>,
"Huang, Kai" <kai.huang@intel.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"luto@kernel.org" <luto@kernel.org>,
"bp@alien8.de" <bp@alien8.de>,
Hansen, Jun
Subject: Re: [RFC v2 05/13] x86/mm: Set KeyIDs in encrypted VMAs
Date: Thu, 06 Dec 2018 08:37:15 +0000 [thread overview]
Message-ID: <fedb2e7fa0ffb9ee80ca2e8228f2d674781babbd.camel@intel.com> (raw)
In-Reply-To: <f0ff967e2015a9dffceef22ac52ecd736a1ddb7e.1543903910.git.alison.schofield@intel.com>
T24gTW9uLCAyMDE4LTEyLTAzIGF0IDIzOjM5IC0wODAwLCBBbGlzb24gU2Nob2ZpZWxkIHdyb3Rl
Og0KPiBNS1RNRSBhcmNoaXRlY3R1cmUgcmVxdWlyZXMgdGhlIEtleUlEIHRvIGJlIHBsYWNlZCBp
biBQVEUgYml0cyA1MTo0Ni4NCj4gVG8gY3JlYXRlIGFuIGVuY3J5cHRlZCBWTUEsIHBsYWNlIHRo
ZSBLZXlJRCBpbiB0aGUgdXBwZXIgYml0cyBvZg0KPiB2bV9wYWdlX3Byb3QgdGhhdCBtYXRjaGVz
IHRoZSBwb3NpdGlvbiBvZiB0aG9zZSBQVEUgYml0cy4NCj4gDQo+IFdoZW4gdGhlIFZNQSBpcyBh
c3NpZ25lZCBhIEtleUlEIGl0IGlzIGFsd2F5cyBjb25zaWRlcmVkIGEgS2V5SUQNCj4gY2hhbmdl
LiBUaGUgVk1BIGlzIGVpdGhlciBnb2luZyBmcm9tIG5vdCBlbmNyeXB0ZWQgdG8gZW5jcnlwdGVk
LA0KPiBvciBmcm9tIGVuY3J5cHRlZCB3aXRoIGFueSBLZXlJRCB0byBlbmNyeXB0ZWQgd2l0aCBh
bnkgb3RoZXIgS2V5SUQuDQo+IFRvIG1ha2UgdGhlIGNoYW5nZSBzYWZlbHksIHJlbW92ZSB0aGUg
dXNlciBwYWdlcyBoZWxkIGJ5IHRoZSBWTUENCj4gYW5kIHVubGluayB0aGUgVk1BJ3MgYW5vbnlt
b3VzIGNoYWluLg0KPiANCj4gQ2hhbmdlLUlkOiBJNjc2MDU2NTI1YzQ5Yzg4MDM4OTgzMTVhMTBi
MTk2ZWY1YTVjNTQxNQ0KDQpSZW1vdmUuDQoNCj4gU2lnbmVkLW9mZi1ieTogQWxpc29uIFNjaG9m
aWVsZCA8YWxpc29uLnNjaG9maWVsZEBpbnRlbC5jb20+DQo+IFNpZ25lZC1vZmYtYnk6IEtpcmls
bCBBLiBTaHV0ZW1vdiA8a2lyaWxsLnNodXRlbW92QGxpbnV4LmludGVsLmNvbT4NCj4gLS0tDQo+
ICBhcmNoL3g4Ni9pbmNsdWRlL2FzbS9ta3RtZS5oIHwgIDQgKysrKw0KPiAgYXJjaC94ODYvbW0v
bWt0bWUuYyAgICAgICAgICB8IDI2ICsrKysrKysrKysrKysrKysrKysrKysrKysrDQo+ICBpbmNs
dWRlL2xpbnV4L21tLmggICAgICAgICAgIHwgIDYgKysrKysrDQo+ICAzIGZpbGVzIGNoYW5nZWQs
IDM2IGluc2VydGlvbnMoKykNCj4gDQo+IGRpZmYgLS1naXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9ta3RtZS5oIGIvYXJjaC94ODYvaW5jbHVkZS9hc20vbWt0bWUuaA0KPiBpbmRleCBkYmI0OTkw
OWQ2NjUuLmRlM2U1MjlmM2FiMCAxMDA2NDQNCj4gLS0tIGEvYXJjaC94ODYvaW5jbHVkZS9hc20v
bWt0bWUuaA0KPiArKysgYi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9ta3RtZS5oDQo+IEBAIC0yNCw2
ICsyNCwxMCBAQCBleHRlcm4gaW50IG1rdG1lX21hcF9rZXlpZF9mcm9tX2tleSh2b2lkICprZXkp
Ow0KPiAgZXh0ZXJuIHZvaWQgKm1rdG1lX21hcF9rZXlfZnJvbV9rZXlpZChpbnQga2V5aWQpOw0K
PiAgZXh0ZXJuIGludCBta3RtZV9tYXBfZ2V0X2ZyZWVfa2V5aWQodm9pZCk7DQo+ICANCj4gKy8q
IFNldCB0aGUgZW5jcnlwdGlvbiBrZXlpZCBiaXRzIGluIGEgVk1BICovDQo+ICtleHRlcm4gdm9p
ZCBtcHJvdGVjdF9zZXRfZW5jcnlwdChzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKnZtYSwgaW50IG5l
d2tleWlkLA0KPiArCQkJCXVuc2lnbmVkIGxvbmcgc3RhcnQsIHVuc2lnbmVkIGxvbmcgZW5kKTsN
Cj4gKw0KPiAgREVDTEFSRV9TVEFUSUNfS0VZX0ZBTFNFKG1rdG1lX2VuYWJsZWRfa2V5KTsNCj4g
IHN0YXRpYyBpbmxpbmUgYm9vbCBta3RtZV9lbmFibGVkKHZvaWQpDQo+ICB7DQo+IGRpZmYgLS1n
aXQgYS9hcmNoL3g4Ni9tbS9ta3RtZS5jIGIvYXJjaC94ODYvbW0vbWt0bWUuYw0KPiBpbmRleCAz
NDIyNGQ0ZTNmNDUuLmUzZmRmN2I0ODE3MyAxMDA2NDQNCj4gLS0tIGEvYXJjaC94ODYvbW0vbWt0
bWUuYw0KPiArKysgYi9hcmNoL3g4Ni9tbS9ta3RtZS5jDQo+IEBAIC0xLDUgKzEsNiBAQA0KPiAg
I2luY2x1ZGUgPGxpbnV4L21tLmg+DQo+ICAjaW5jbHVkZSA8bGludXgvaGlnaG1lbS5oPg0KPiAr
I2luY2x1ZGUgPGxpbnV4L3JtYXAuaD4NCj4gICNpbmNsdWRlIDxhc20vbWt0bWUuaD4NCj4gICNp
bmNsdWRlIDxhc20vc2V0X21lbW9yeS5oPg0KPiAgDQo+IEBAIC0xMzEsNiArMTMyLDMxIEBAIGlu
dCBta3RtZV9tYXBfZ2V0X2ZyZWVfa2V5aWQodm9pZCkNCj4gIAlyZXR1cm4gMDsNCj4gIH0NCj4g
IA0KPiArLyogU2V0IHRoZSBlbmNyeXB0aW9uIGtleWlkIGJpdHMgaW4gYSBWTUEgKi8NCg0KTWF5
YmUgcHJvcGVyIGtkb2M/DQoNCj4gK3ZvaWQgbXByb3RlY3Rfc2V0X2VuY3J5cHQoc3RydWN0IHZt
X2FyZWFfc3RydWN0ICp2bWEsIGludCBuZXdrZXlpZCwNCj4gKwkJCSAgdW5zaWduZWQgbG9uZyBz
dGFydCwgdW5zaWduZWQgbG9uZyBlbmQpDQo+ICt7DQo+ICsJaW50IG9sZGtleWlkID0gdm1hX2tl
eWlkKHZtYSk7DQo+ICsJcGdwcm90dmFsX3QgbmV3cHJvdDsNCj4gKw0KPiArCS8qIFVubWFwIHBh
Z2VzIHdpdGggb2xkIEtleUlEIGlmIHRoZXJlJ3MgYW55LiAqLw0KPiArCXphcF9wYWdlX3Jhbmdl
KHZtYSwgc3RhcnQsIGVuZCAtIHN0YXJ0KTsNCj4gKw0KPiArCWlmIChvbGRrZXlpZCA9PSBuZXdr
ZXlpZCkNCj4gKwkJcmV0dXJuOw0KPiArDQo+ICsJbmV3cHJvdCA9IHBncHJvdF92YWwodm1hLT52
bV9wYWdlX3Byb3QpOw0KPiArCW5ld3Byb3QgJj0gfm1rdG1lX2tleWlkX21hc2s7DQo+ICsJbmV3
cHJvdCB8PSAodW5zaWduZWQgbG9uZyluZXdrZXlpZCA8PCBta3RtZV9rZXlpZF9zaGlmdDsNCj4g
Kwl2bWEtPnZtX3BhZ2VfcHJvdCA9IF9fcGdwcm90KG5ld3Byb3QpOw0KPiArDQo+ICsJLyoNCg0K
Tm8gZW1wdHkgY29tbWVudCBsaW5lLg0KDQo+ICsJICogVGhlIFZNQSBkb2Vzbid0IGhhdmUgYW55
IGluaGVyaXRlZCBwYWdlcy4NCj4gKwkgKiBTdGFydCBhbm9uIFZNQSB0cmVlIGZyb20gc2NyYXRj
aC4NCj4gKwkgKi8NCj4gK30NCj4gKw0KPiAgLyogUHJlcGFyZSBwYWdlIHRvIGJlIHVzZWQgZm9y
IGVuY3J5cHRpb24uIENhbGxlZCBmcm9tIHBhZ2UgYWxsb2NhdG9yLiAqLw0KPiAgdm9pZCBfX3By
ZXBfZW5jcnlwdGVkX3BhZ2Uoc3RydWN0IHBhZ2UgKnBhZ2UsIGludCBvcmRlciwgaW50IGtleWlk
LCBib29sDQo+IHplcm8pDQo+ICB7DQo+IGRpZmYgLS1naXQgYS9pbmNsdWRlL2xpbnV4L21tLmgg
Yi9pbmNsdWRlL2xpbnV4L21tLmgNCj4gaW5kZXggMTMwOTc2MWJiNmQwLi5lMmQ4N2U5MmNhNzQg
MTAwNjQ0DQo+IC0tLSBhL2luY2x1ZGUvbGludXgvbW0uaA0KPiArKysgYi9pbmNsdWRlL2xpbnV4
L21tLmgNCj4gQEAgLTI4MDYsNSArMjgwNiwxMSBAQCB2b2lkIF9faW5pdCBzZXR1cF9ucl9ub2Rl
X2lkcyh2b2lkKTsNCj4gIHN0YXRpYyBpbmxpbmUgdm9pZCBzZXR1cF9ucl9ub2RlX2lkcyh2b2lk
KSB7fQ0KPiAgI2VuZGlmDQo+ICANCj4gKyNpZm5kZWYgQ09ORklHX1g4Nl9JTlRFTF9NS1RNRQ0K
PiArc3RhdGljIGlubGluZSB2b2lkIG1wcm90ZWN0X3NldF9lbmNyeXB0KHN0cnVjdCB2bV9hcmVh
X3N0cnVjdCAqdm1hLA0KPiArCQkJCQlpbnQgbmV3a2V5aWQsDQo+ICsJCQkJCXVuc2lnbmVkIGxv
bmcgc3RhcnQsDQo+ICsJCQkJCXVuc2lnbmVkIGxvbmcgZW5kKSB7fQ0KDQpBZGQgYSBuZXcgbGlu
ZSBhbmQNCg0Kew0KfQ0KDQoNCj4gKyNlbmRpZiAvKiBDT05GSUdfWDg2X0lOVEVMX01LVE1FICov
DQo+ICAjZW5kaWYgLyogX19LRVJORUxfXyAqLw0KPiAgI2VuZGlmIC8qIF9MSU5VWF9NTV9IICov
DQoNCi9KYXJra28NCg=
WARNING: multiple messages have this Message-ID (diff)
From: "Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>
To: "tglx@linutronix.de" <tglx@linutronix.de>,
"Schofield, Alison" <alison.schofield@intel.com>,
"dhowells@redhat.com" <dhowells@redhat.com>
Cc: "kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"jmorris@namei.org" <jmorris@namei.org>,
"Huang, Kai" <kai.huang@intel.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"luto@kernel.org" <luto@kernel.org>,
"bp@alien8.de" <bp@alien8.de>,
"Hansen, Dave" <dave.hansen@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: [RFC v2 05/13] x86/mm: Set KeyIDs in encrypted VMAs
Date: Thu, 6 Dec 2018 08:37:15 +0000 [thread overview]
Message-ID: <fedb2e7fa0ffb9ee80ca2e8228f2d674781babbd.camel@intel.com> (raw)
In-Reply-To: <f0ff967e2015a9dffceef22ac52ecd736a1ddb7e.1543903910.git.alison.schofield@intel.com>
On Mon, 2018-12-03 at 23:39 -0800, Alison Schofield wrote:
> MKTME architecture requires the KeyID to be placed in PTE bits 51:46.
> To create an encrypted VMA, place the KeyID in the upper bits of
> vm_page_prot that matches the position of those PTE bits.
>
> When the VMA is assigned a KeyID it is always considered a KeyID
> change. The VMA is either going from not encrypted to encrypted,
> or from encrypted with any KeyID to encrypted with any other KeyID.
> To make the change safely, remove the user pages held by the VMA
> and unlink the VMA's anonymous chain.
>
> Change-Id: I676056525c49c8803898315a10b196ef5a5c5415
Remove.
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
> arch/x86/include/asm/mktme.h | 4 ++++
> arch/x86/mm/mktme.c | 26 ++++++++++++++++++++++++++
> include/linux/mm.h | 6 ++++++
> 3 files changed, 36 insertions(+)
>
> diff --git a/arch/x86/include/asm/mktme.h b/arch/x86/include/asm/mktme.h
> index dbb49909d665..de3e529f3ab0 100644
> --- a/arch/x86/include/asm/mktme.h
> +++ b/arch/x86/include/asm/mktme.h
> @@ -24,6 +24,10 @@ extern int mktme_map_keyid_from_key(void *key);
> extern void *mktme_map_key_from_keyid(int keyid);
> extern int mktme_map_get_free_keyid(void);
>
> +/* Set the encryption keyid bits in a VMA */
> +extern void mprotect_set_encrypt(struct vm_area_struct *vma, int newkeyid,
> + unsigned long start, unsigned long end);
> +
> DECLARE_STATIC_KEY_FALSE(mktme_enabled_key);
> static inline bool mktme_enabled(void)
> {
> diff --git a/arch/x86/mm/mktme.c b/arch/x86/mm/mktme.c
> index 34224d4e3f45..e3fdf7b48173 100644
> --- a/arch/x86/mm/mktme.c
> +++ b/arch/x86/mm/mktme.c
> @@ -1,5 +1,6 @@
> #include <linux/mm.h>
> #include <linux/highmem.h>
> +#include <linux/rmap.h>
> #include <asm/mktme.h>
> #include <asm/set_memory.h>
>
> @@ -131,6 +132,31 @@ int mktme_map_get_free_keyid(void)
> return 0;
> }
>
> +/* Set the encryption keyid bits in a VMA */
Maybe proper kdoc?
> +void mprotect_set_encrypt(struct vm_area_struct *vma, int newkeyid,
> + unsigned long start, unsigned long end)
> +{
> + int oldkeyid = vma_keyid(vma);
> + pgprotval_t newprot;
> +
> + /* Unmap pages with old KeyID if there's any. */
> + zap_page_range(vma, start, end - start);
> +
> + if (oldkeyid == newkeyid)
> + return;
> +
> + newprot = pgprot_val(vma->vm_page_prot);
> + newprot &= ~mktme_keyid_mask;
> + newprot |= (unsigned long)newkeyid << mktme_keyid_shift;
> + vma->vm_page_prot = __pgprot(newprot);
> +
> + /*
No empty comment line.
> + * The VMA doesn't have any inherited pages.
> + * Start anon VMA tree from scratch.
> + */
> +}
> +
> /* Prepare page to be used for encryption. Called from page allocator. */
> void __prep_encrypted_page(struct page *page, int order, int keyid, bool
> zero)
> {
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 1309761bb6d0..e2d87e92ca74 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2806,5 +2806,11 @@ void __init setup_nr_node_ids(void);
> static inline void setup_nr_node_ids(void) {}
> #endif
>
> +#ifndef CONFIG_X86_INTEL_MKTME
> +static inline void mprotect_set_encrypt(struct vm_area_struct *vma,
> + int newkeyid,
> + unsigned long start,
> + unsigned long end) {}
Add a new line and
{
}
> +#endif /* CONFIG_X86_INTEL_MKTME */
> #endif /* __KERNEL__ */
> #endif /* _LINUX_MM_H */
/Jarkko
WARNING: multiple messages have this Message-ID (diff)
From: "Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>
To: "tglx@linutronix.de" <tglx@linutronix.de>,
"Schofield, Alison" <alison.schofield@intel.com>,
"dhowells@redhat.com" <dhowells@redhat.com>
Cc: "kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"jmorris@namei.org" <jmorris@namei.org>,
"Huang, Kai" <kai.huang@intel.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"luto@kernel.org" <luto@kernel.org>,
"bp@alien8.de" <bp@alien8.de>, Hansen,,
Jun
Subject: Re: [RFC v2 05/13] x86/mm: Set KeyIDs in encrypted VMAs
Date: Thu, 6 Dec 2018 08:37:15 +0000 [thread overview]
Message-ID: <fedb2e7fa0ffb9ee80ca2e8228f2d674781babbd.camel@intel.com> (raw)
In-Reply-To: <f0ff967e2015a9dffceef22ac52ecd736a1ddb7e.1543903910.git.alison.schofield@intel.com>
On Mon, 2018-12-03 at 23:39 -0800, Alison Schofield wrote:
> MKTME architecture requires the KeyID to be placed in PTE bits 51:46.
> To create an encrypted VMA, place the KeyID in the upper bits of
> vm_page_prot that matches the position of those PTE bits.
>
> When the VMA is assigned a KeyID it is always considered a KeyID
> change. The VMA is either going from not encrypted to encrypted,
> or from encrypted with any KeyID to encrypted with any other KeyID.
> To make the change safely, remove the user pages held by the VMA
> and unlink the VMA's anonymous chain.
>
> Change-Id: I676056525c49c8803898315a10b196ef5a5c5415
Remove.
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
> arch/x86/include/asm/mktme.h | 4 ++++
> arch/x86/mm/mktme.c | 26 ++++++++++++++++++++++++++
> include/linux/mm.h | 6 ++++++
> 3 files changed, 36 insertions(+)
>
> diff --git a/arch/x86/include/asm/mktme.h b/arch/x86/include/asm/mktme.h
> index dbb49909d665..de3e529f3ab0 100644
> --- a/arch/x86/include/asm/mktme.h
> +++ b/arch/x86/include/asm/mktme.h
> @@ -24,6 +24,10 @@ extern int mktme_map_keyid_from_key(void *key);
> extern void *mktme_map_key_from_keyid(int keyid);
> extern int mktme_map_get_free_keyid(void);
>
> +/* Set the encryption keyid bits in a VMA */
> +extern void mprotect_set_encrypt(struct vm_area_struct *vma, int newkeyid,
> + unsigned long start, unsigned long end);
> +
> DECLARE_STATIC_KEY_FALSE(mktme_enabled_key);
> static inline bool mktme_enabled(void)
> {
> diff --git a/arch/x86/mm/mktme.c b/arch/x86/mm/mktme.c
> index 34224d4e3f45..e3fdf7b48173 100644
> --- a/arch/x86/mm/mktme.c
> +++ b/arch/x86/mm/mktme.c
> @@ -1,5 +1,6 @@
> #include <linux/mm.h>
> #include <linux/highmem.h>
> +#include <linux/rmap.h>
> #include <asm/mktme.h>
> #include <asm/set_memory.h>
>
> @@ -131,6 +132,31 @@ int mktme_map_get_free_keyid(void)
> return 0;
> }
>
> +/* Set the encryption keyid bits in a VMA */
Maybe proper kdoc?
> +void mprotect_set_encrypt(struct vm_area_struct *vma, int newkeyid,
> + unsigned long start, unsigned long end)
> +{
> + int oldkeyid = vma_keyid(vma);
> + pgprotval_t newprot;
> +
> + /* Unmap pages with old KeyID if there's any. */
> + zap_page_range(vma, start, end - start);
> +
> + if (oldkeyid == newkeyid)
> + return;
> +
> + newprot = pgprot_val(vma->vm_page_prot);
> + newprot &= ~mktme_keyid_mask;
> + newprot |= (unsigned long)newkeyid << mktme_keyid_shift;
> + vma->vm_page_prot = __pgprot(newprot);
> +
> + /*
No empty comment line.
> + * The VMA doesn't have any inherited pages.
> + * Start anon VMA tree from scratch.
> + */
> +}
> +
> /* Prepare page to be used for encryption. Called from page allocator. */
> void __prep_encrypted_page(struct page *page, int order, int keyid, bool
> zero)
> {
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 1309761bb6d0..e2d87e92ca74 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2806,5 +2806,11 @@ void __init setup_nr_node_ids(void);
> static inline void setup_nr_node_ids(void) {}
> #endif
>
> +#ifndef CONFIG_X86_INTEL_MKTME
> +static inline void mprotect_set_encrypt(struct vm_area_struct *vma,
> + int newkeyid,
> + unsigned long start,
> + unsigned long end) {}
Add a new line and
{
}
> +#endif /* CONFIG_X86_INTEL_MKTME */
> #endif /* __KERNEL__ */
> #endif /* _LINUX_MM_H */
/Jarkko
next prev parent reply other threads:[~2018-12-06 8:37 UTC|newest]
Thread overview: 198+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-04 7:39 [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME) Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-04 7:39 ` [RFC v2 01/13] x86/mktme: Document the MKTME APIs Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-05 18:11 ` Andy Lutomirski
2018-12-05 18:11 ` Andy Lutomirski
2018-12-05 19:22 ` Alison Schofield
2018-12-05 19:22 ` Alison Schofield
2018-12-05 23:35 ` Andy Lutomirski
2018-12-05 23:35 ` Andy Lutomirski
2018-12-06 8:04 ` Sakkinen, Jarkko
2018-12-06 8:04 ` Sakkinen, Jarkko
2018-12-06 8:04 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 02/13] mm: Generalize the mprotect implementation to support extensions Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-06 8:08 ` Sakkinen, Jarkko
2018-12-06 8:08 ` Sakkinen, Jarkko
2018-12-06 8:08 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 03/13] syscall/x86: Wire up a new system call for memory encryption keys Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-04 7:39 ` [RFC v2 04/13] x86/mm: Add helper functions for MKTME " Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-04 9:14 ` Peter Zijlstra
2018-12-04 9:14 ` Peter Zijlstra
2018-12-05 5:49 ` Alison Schofield
2018-12-05 5:49 ` Alison Schofield
2018-12-04 15:35 ` Andy Lutomirski
2018-12-04 15:35 ` Andy Lutomirski
2018-12-05 5:52 ` Alison Schofield
2018-12-05 5:52 ` Alison Schofield
2018-12-06 8:31 ` Sakkinen, Jarkko
2018-12-06 8:31 ` Sakkinen, Jarkko
2018-12-06 8:31 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 05/13] x86/mm: Set KeyIDs in encrypted VMAs Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-06 8:37 ` Sakkinen, Jarkko [this message]
2018-12-06 8:37 ` Sakkinen, Jarkko
2018-12-06 8:37 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 06/13] mm: Add the encrypt_mprotect() system call Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-06 8:38 ` Sakkinen, Jarkko
2018-12-06 8:38 ` Sakkinen, Jarkko
2018-12-06 8:38 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 07/13] x86/mm: Add helpers for reference counting encrypted VMAs Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-04 8:58 ` Peter Zijlstra
2018-12-04 8:58 ` Peter Zijlstra
2018-12-05 5:28 ` Alison Schofield
2018-12-05 5:28 ` Alison Schofield
2018-12-04 7:39 ` [RFC v2 08/13] mm: Use reference counting for " Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-04 7:39 ` [RFC v2 09/13] mm: Restrict memory encryption to anonymous VMA's Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-04 9:10 ` Peter Zijlstra
2018-12-04 9:10 ` Peter Zijlstra
2018-12-05 5:30 ` Alison Schofield
2018-12-05 5:30 ` Alison Schofield
2018-12-05 9:07 ` Peter Zijlstra
2018-12-05 9:07 ` Peter Zijlstra
2018-12-04 7:39 ` [RFC v2 10/13] keys/mktme: Add the MKTME Key Service type for memory encryption Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-06 8:51 ` Sakkinen, Jarkko
2018-12-06 8:51 ` Sakkinen, Jarkko
2018-12-06 8:51 ` Sakkinen, Jarkko
2018-12-06 8:54 ` Sakkinen, Jarkko
2018-12-06 8:54 ` Sakkinen, Jarkko
2018-12-06 8:54 ` Sakkinen, Jarkko
2018-12-06 15:11 ` Dave Hansen
2018-12-06 15:11 ` Dave Hansen
2018-12-06 22:56 ` Sakkinen, Jarkko
2018-12-06 22:56 ` Sakkinen, Jarkko
2018-12-04 7:39 ` [RFC v2 11/13] keys/mktme: Program memory encryption keys on a system wide basis Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-04 9:21 ` Peter Zijlstra
2018-12-04 9:21 ` Peter Zijlstra
2018-12-04 9:50 ` Kirill A. Shutemov
2018-12-04 9:50 ` Kirill A. Shutemov
2018-12-05 5:44 ` Alison Schofield
2018-12-05 5:44 ` Alison Schofield
2018-12-05 5:43 ` Alison Schofield
2018-12-05 5:43 ` Alison Schofield
2018-12-05 9:10 ` Peter Zijlstra
2018-12-05 9:10 ` Peter Zijlstra
2018-12-05 17:26 ` Alison Schofield
2018-12-05 17:26 ` Alison Schofield
2018-12-04 7:39 ` [RFC v2 12/13] keys/mktme: Save MKTME data if kernel cmdline parameter allows Alison Schofield
2018-12-04 7:39 ` Alison Schofield
2018-12-04 9:22 ` Peter Zijlstra
2018-12-04 9:22 ` Peter Zijlstra
2018-12-07 2:14 ` Huang, Kai
2018-12-07 2:14 ` Huang, Kai
2018-12-07 3:42 ` Alison Schofield
2018-12-07 3:42 ` Alison Schofield
2018-12-07 6:39 ` Jarkko Sakkinen
2018-12-07 6:39 ` Jarkko Sakkinen
2018-12-07 6:45 ` Jarkko Sakkinen
2018-12-07 6:45 ` Jarkko Sakkinen
2018-12-07 11:47 ` Kirill A. Shutemov
2018-12-07 11:47 ` Kirill A. Shutemov
2018-12-04 7:40 ` [RFC v2 13/13] keys/mktme: Support CPU Hotplug for MKTME keys Alison Schofield
2018-12-04 7:40 ` Alison Schofield
2018-12-04 9:28 ` Peter Zijlstra
2018-12-04 9:28 ` Peter Zijlstra
2018-12-05 5:32 ` Alison Schofield
2018-12-05 5:32 ` Alison Schofield
2018-12-04 9:31 ` Peter Zijlstra
2018-12-04 9:31 ` Peter Zijlstra
2018-12-05 5:36 ` Alison Schofield
2018-12-05 5:36 ` Alison Schofield
2018-12-04 9:25 ` [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME) Peter Zijlstra
2018-12-04 9:25 ` Peter Zijlstra
2018-12-04 9:46 ` Kirill A. Shutemov
2018-12-04 9:46 ` Kirill A. Shutemov
2018-12-05 20:32 ` Sakkinen, Jarkko
2018-12-05 20:32 ` Sakkinen, Jarkko
2018-12-05 20:32 ` Sakkinen, Jarkko
2018-12-06 11:22 ` Kirill A. Shutemov
2018-12-06 11:22 ` Kirill A. Shutemov
2018-12-06 14:59 ` Dave Hansen
2018-12-06 14:59 ` Dave Hansen
2018-12-07 10:12 ` Huang, Kai
2018-12-07 10:12 ` Huang, Kai
2018-12-06 21:23 ` Sakkinen, Jarkko
2018-12-06 21:23 ` Sakkinen, Jarkko
2018-12-06 21:23 ` Sakkinen, Jarkko
2018-12-07 11:54 ` Kirill A. Shutemov
2018-12-07 11:54 ` Kirill A. Shutemov
2018-12-04 19:19 ` Andy Lutomirski
2018-12-04 19:19 ` Andy Lutomirski
2018-12-04 20:00 ` Andy Lutomirski
2018-12-04 20:00 ` Andy Lutomirski
2018-12-04 20:32 ` Dave Hansen
2018-12-04 20:32 ` Dave Hansen
2018-12-05 22:19 ` Sakkinen, Jarkko
2018-12-05 22:19 ` Sakkinen, Jarkko
2018-12-07 2:05 ` Huang, Kai
2018-12-07 2:05 ` Huang, Kai
2018-12-07 6:48 ` Jarkko Sakkinen
2018-12-07 6:48 ` Jarkko Sakkinen
2018-12-07 11:57 ` Kirill A. Shutemov
2018-12-07 11:57 ` Kirill A. Shutemov
2018-12-07 21:59 ` Sakkinen, Jarkko
2018-12-07 21:59 ` Sakkinen, Jarkko
2018-12-07 21:59 ` Sakkinen, Jarkko
2018-12-07 23:45 ` Sakkinen, Jarkko
2018-12-07 23:45 ` Sakkinen, Jarkko
2018-12-07 23:45 ` Sakkinen, Jarkko
2018-12-07 23:48 ` Andy Lutomirski
2018-12-07 23:48 ` Andy Lutomirski
2018-12-08 1:33 ` Huang, Kai
2018-12-08 1:33 ` Huang, Kai
2018-12-08 1:33 ` Huang, Kai
2018-12-08 3:53 ` Sakkinen, Jarkko
2018-12-08 3:53 ` Sakkinen, Jarkko
2018-12-08 3:53 ` Sakkinen, Jarkko
2018-12-12 15:31 ` Sakkinen, Jarkko
2018-12-12 15:31 ` Sakkinen, Jarkko
2018-12-12 15:31 ` Sakkinen, Jarkko
2018-12-12 16:29 ` Andy Lutomirski
2018-12-12 16:29 ` Andy Lutomirski
2018-12-12 16:43 ` Sakkinen, Jarkko
2018-12-12 16:43 ` Sakkinen, Jarkko
2018-12-12 23:27 ` Huang, Kai
2018-12-12 23:27 ` Huang, Kai
2018-12-13 5:49 ` Sakkinen, Jarkko
2018-12-13 5:49 ` Sakkinen, Jarkko
2018-12-13 5:52 ` Sakkinen, Jarkko
2018-12-13 5:52 ` Sakkinen, Jarkko
2018-12-12 23:24 ` Huang, Kai
2018-12-12 23:24 ` Huang, Kai
2018-12-07 23:35 ` Eric Rannaud
2018-12-07 23:35 ` Eric Rannaud
2018-12-05 23:49 ` Dave Hansen
2018-12-05 23:49 ` Dave Hansen
2018-12-06 1:09 ` Andy Lutomirski
2018-12-06 1:09 ` Andy Lutomirski
2018-12-06 1:25 ` Dan Williams
2018-12-06 1:25 ` Dan Williams
2018-12-06 15:39 ` Dave Hansen
2018-12-06 15:39 ` Dave Hansen
2018-12-06 19:10 ` Andy Lutomirski
2018-12-06 19:10 ` Andy Lutomirski
2018-12-06 19:31 ` Dave Hansen
2018-12-06 19:31 ` Dave Hansen
2018-12-07 1:55 ` Huang, Kai
2018-12-07 1:55 ` Huang, Kai
2018-12-07 1:55 ` Huang, Kai
2018-12-07 4:23 ` Dave Hansen
2018-12-07 4:23 ` Dave Hansen
2018-12-07 23:53 ` Andy Lutomirski
2018-12-07 23:53 ` Andy Lutomirski
2018-12-08 1:11 ` Dave Hansen
2018-12-08 1:11 ` Dave Hansen
2018-12-08 2:07 ` Huang, Kai
2018-12-08 2:07 ` Huang, Kai
2018-12-05 20:30 ` Sakkinen, Jarkko
2018-12-05 20:30 ` Sakkinen, Jarkko
2018-12-05 20:30 ` Sakkinen, Jarkko
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=fedb2e7fa0ffb9ee80ca2e8228f2d674781babbd.camel@intel.com \
--to=jarkko.sakkinen@intel.com \
--cc=alison.schofield@intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dhowells@redhat.com \
--cc=hpa@zytor.com \
--cc=jmorris@namei.org \
--cc=kai.huang@intel.com \
--cc=keyrings@vger.kernel.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.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.