From: "Huang, Kai" <kai.huang@intel.com>
To: "luto@kernel.org" <luto@kernel.org>,
"Hansen, Dave" <dave.hansen@intel.com>
Cc: "kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"jmorris@namei.org" <jmorris@namei.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"willy@infradead.org" <willy@infradead.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"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>,
"Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>,
"bp@alien8.de" <bp@alien8.de>,
"Schofield, Alison" <alison.schofield@intel.com>,
Nakajima
Subject: Re: [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME)
Date: Fri, 07 Dec 2018 01:55:45 +0000 [thread overview]
Message-ID: <1544147742.28511.18.camel@intel.com> (raw)
In-Reply-To: <CALCETrU34U3berTaEQbvNt0rfCdsjwj+xDb8x7bgAMFHEo=eUw@mail.gmail.com>
DQo+IA0KPiBUTUUgaXRzZWxmIHByb3ZpZGVzIGEgdG9uIG9mIHByb3RlY3Rpb24gLS0geW91IGNh
bid0IGp1c3QgYmFyZ2UgaW50bw0KPiB0aGUgZGF0YWNlbnRlciwgcmVmcmlnZXJhdGUgdGhlIERJ
TU1zLCB3YWxrIGF3YXkgd2l0aCB0aGVtLCBhbmQgcmVhZA0KPiBvZmYgZXZlcnlvbmUncyBkYXRh
Lg0KPiANCj4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KSSB0aGluayB3ZSBjYW4gbWFrZSBz
dWNoIGFzc3VtcHRpb24gaW4gbW9zdCBjYXNlcywgYnV0IEkgdGhpbmsgaXQncyBiZXR0ZXIgdGhh
dCB3ZSBkb24ndCBtYWtlIGFueQ0KYXNzdW1wdGlvbiBhdCBhbGwuIEZvciBleGFtcGxlLCB0aGUg
YWRtaW4gb2YgZGF0YSBjZW50ZXIgKG9yIGFueW9uZSkgd2hvIGhhcyBwaHlzaWNhbCBhY2Nlc3Mg
dG8NCnNlcnZlcnMgbWF5IGRvIHNvbWV0aGluZyBtYWxpY2lvdXMuIEkgYW0gbm90IGV4cGVydCBi
dXQgdGhlcmUgc2hvdWxkIGJlIG90aGVyIHBoeXNpY2FsIGF0dGFjaw0KbWV0aG9kcyBiZXNpZGVz
IGNvbGRib290IGF0dGFjaywgaWYgdGhlIG1hbGljaW91cyBlbXBsb3llZSBjYW4gZ2V0IHBoeXNp
Y2FsIGFjY2VzcyB0byBzZXJ2ZXIgdy9vDQpiZWluZyBkZXRlY3RlZC4NCg0KPiANCj4gPiANCj4g
PiBCdXQsIEkgdGhpbmsgd2hhdCB5b3UncmUgaW1wbHlpbmcgaXMgdGhhdCB0aGUgc2VjdXJpdHkg
cHJvcGVydGllcyBvZg0KPiA+IHVzZXItc3VwcGxpZWQga2V5cyBjYW4gb25seSBiZSAqd29yc2Uq
IHRoYW4gdXNpbmcgQ1BVLWdlbmVyYXRlZCBrZXlzDQo+ID4gKGFzc3VtaW5nIHRoZSBDUFUgZG9l
cyBhIGdvb2Qgam9iIGdlbmVyYXRpbmcgaXQpLiAgU28sIHdoeSBib3RoZXINCj4gPiBhbGxvd2lu
ZyB1c2VyLXNwZWNpZmllZCBrZXlzIGluIHRoZSBmaXJzdCBwbGFjZT8NCj4gDQo+IFRoYXQgdG9v
IDopDQoNCkkgdGhpbmsgb25lIHVzYWdlIG9mIHVzZXItc3BlY2lmaWVkIGtleSBpcyBmb3IgTlZE
SU1NLCBzaW5jZSBDUFUga2V5IHdpbGwgYmUgZ29uZSBhZnRlciBtYWNoaW5lDQpyZWJvb3QsIHRo
ZXJlZm9yZSBpZiBOVkRJTU0gaXMgZW5jcnlwdGVkIGJ5IENQVSBrZXkgd2UgYXJlIG5vdCBhYmxl
IHRvIHJldHJpZXZlIGl0IG9uY2UNCnNodXRkb3duL3JlYm9vdCwgZXRjLg0KDQpUaGVyZSBhcmUg
c29tZSBvdGhlciB1c2UgY2FzZXMgdGhhdCBhbHJlYWR5IHJlcXVpcmUgdGVuYW50IHRvIHNlbmQg
a2V5IHRvIENTUC4gRm9yIGV4YW1wbGUsIHRoZSBWTQ0KaW1hZ2UgY2FuIGJlIHByb3ZpZGVkIGJ5
IHRlbmFudCBhbmQgZW5jcnlwdGVkIGJ5IHRlbmFudCdzIG93biBrZXksIGFuZCB0ZW5hbnQgbmVl
ZHMgdG8gc2VuZCBrZXkgdG8NCkNTUCB3aGVuIGFza2luZyBDU1AgdG8gcnVuIHRoYXQgZW5jcnlw
dGVkIGltYWdlLiBCdXQgdGVuYW50IHdpbGwgbmVlZCB0byB0cnVzdCBDU1AgaW4gc3VjaCBjYXNl
LA0Kd2hpY2ggYnJpbmdzIHVzIHdoeSB0ZW5hbnQgd2FudHMgdG8gdXNlIGhpcyBvd24gaW1hZ2Ug
YXQgZmlyc3QgcGxhY2UgKEkgaGF2ZSB0byBzYXkgSSBteXNlbGYgaXMgbm90DQpjb252aW5jZWQg
dGhlIHZhbHVlIG9mIHN1Y2ggdXNlIGNhc2UpLiBJIHRoaW5rIHRoZXJlIGFyZSB0d28gbGV2ZWxz
IG9mIHRydXN0aW5lc3MgaW52b2x2ZWQgaGVyZTogMSkNCnRlbmFudCBuZWVkcyB0byB0cnVzdCBD
U1AgYW55d2F5OyAyKSBidXQgQ1NQIG5lZWRzIHRvIGNvbnZpbmNlIHRlbmFudCB0aGF0IENTUCBj
YW4gYmUgdHJ1c3RlZCwgaWUsDQpieSBwcm92aW5nIGl0IGNhbiBwcmV2ZW50IHBvdGVudGlhbCBh
dHRhY2sgZnJvbSBtYWxpY2lvdXMgZW1wbG95ZWUgKGllLCBieSByYWlzaW5nIGJhciBieSB1c2lu
Zw0KTUtUTUUpLCBldGMuDQoNClRoYW5rcywNCi1LYWk
WARNING: multiple messages have this Message-ID (diff)
From: "Huang, Kai" <kai.huang@intel.com>
To: "luto@kernel.org" <luto@kernel.org>,
"Hansen, Dave" <dave.hansen@intel.com>
Cc: "kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"jmorris@namei.org" <jmorris@namei.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"willy@infradead.org" <willy@infradead.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"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>,
"Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>,
"bp@alien8.de" <bp@alien8.de>,
"Schofield, Alison" <alison.schofield@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME)
Date: Fri, 7 Dec 2018 01:55:45 +0000 [thread overview]
Message-ID: <1544147742.28511.18.camel@intel.com> (raw)
In-Reply-To: <CALCETrU34U3berTaEQbvNt0rfCdsjwj+xDb8x7bgAMFHEo=eUw@mail.gmail.com>
>
> TME itself provides a ton of protection -- you can't just barge into
> the datacenter, refrigerate the DIMMs, walk away with them, and read
> off everyone's data.
>
> Am I missing something?
I think we can make such assumption in most cases, but I think it's better that we don't make any
assumption at all. For example, the admin of data center (or anyone) who has physical access to
servers may do something malicious. I am not expert but there should be other physical attack
methods besides coldboot attack, if the malicious employee can get physical access to server w/o
being detected.
>
> >
> > But, I think what you're implying is that the security properties of
> > user-supplied keys can only be *worse* than using CPU-generated keys
> > (assuming the CPU does a good job generating it). So, why bother
> > allowing user-specified keys in the first place?
>
> That too :)
I think one usage of user-specified key is for NVDIMM, since CPU key will be gone after machine
reboot, therefore if NVDIMM is encrypted by CPU key we are not able to retrieve it once
shutdown/reboot, etc.
There are some other use cases that already require tenant to send key to CSP. For example, the VM
image can be provided by tenant and encrypted by tenant's own key, and tenant needs to send key to
CSP when asking CSP to run that encrypted image. But tenant will need to trust CSP in such case,
which brings us why tenant wants to use his own image at first place (I have to say I myself is not
convinced the value of such use case). I think there are two levels of trustiness involved here: 1)
tenant needs to trust CSP anyway; 2) but CSP needs to convince tenant that CSP can be trusted, ie,
by proving it can prevent potential attack from malicious employee (ie, by raising bar by using
MKTME), etc.
Thanks,
-Kai
WARNING: multiple messages have this Message-ID (diff)
From: "Huang, Kai" <kai.huang@intel.com>
To: "luto@kernel.org" <luto@kernel.org>,
"Hansen, Dave" <dave.hansen@intel.com>
Cc: "kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"jmorris@namei.org" <jmorris@namei.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"willy@infradead.org" <willy@infradead.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"dhowells@redhat.com" <dhowells@redhat.com>,
"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>,
"Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>,
"bp@alien8.de" <bp@alien8.de>,
"Schofield, Alison" <alison.schofield@intel.com>, Nakajima,
Subject: Re: [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME)
Date: Fri, 7 Dec 2018 01:55:45 +0000 [thread overview]
Message-ID: <1544147742.28511.18.camel@intel.com> (raw)
In-Reply-To: <CALCETrU34U3berTaEQbvNt0rfCdsjwj+xDb8x7bgAMFHEo=eUw@mail.gmail.com>
>
> TME itself provides a ton of protection -- you can't just barge into
> the datacenter, refrigerate the DIMMs, walk away with them, and read
> off everyone's data.
>
> Am I missing something?
I think we can make such assumption in most cases, but I think it's better that we don't make any
assumption at all. For example, the admin of data center (or anyone) who has physical access to
servers may do something malicious. I am not expert but there should be other physical attack
methods besides coldboot attack, if the malicious employee can get physical access to server w/o
being detected.
>
> >
> > But, I think what you're implying is that the security properties of
> > user-supplied keys can only be *worse* than using CPU-generated keys
> > (assuming the CPU does a good job generating it). So, why bother
> > allowing user-specified keys in the first place?
>
> That too :)
I think one usage of user-specified key is for NVDIMM, since CPU key will be gone after machine
reboot, therefore if NVDIMM is encrypted by CPU key we are not able to retrieve it once
shutdown/reboot, etc.
There are some other use cases that already require tenant to send key to CSP. For example, the VM
image can be provided by tenant and encrypted by tenant's own key, and tenant needs to send key to
CSP when asking CSP to run that encrypted image. But tenant will need to trust CSP in such case,
which brings us why tenant wants to use his own image at first place (I have to say I myself is not
convinced the value of such use case). I think there are two levels of trustiness involved here: 1)
tenant needs to trust CSP anyway; 2) but CSP needs to convince tenant that CSP can be trusted, ie,
by proving it can prevent potential attack from malicious employee (ie, by raising bar by using
MKTME), etc.
Thanks,
-Kai
next prev parent reply other threads:[~2018-12-07 1:55 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
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 [this message]
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=1544147742.28511.18.camel@intel.com \
--to=kai.huang@intel.com \
--cc=alison.schofield@intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dhowells@redhat.com \
--cc=hpa@zytor.com \
--cc=jarkko.sakkinen@intel.com \
--cc=jmorris@namei.org \
--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=willy@infradead.org \
--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.