diff for duplicates of <1544147742.28511.18.camel@intel.com> diff --git a/a/1.txt b/N1/1.txt index 2eb28f3..e1c94ea 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,33 +1,38 @@ -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 + +> +> 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 diff --git a/a/content_digest b/N1/content_digest index b31d0b3..6471192 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,7 +4,7 @@ "ref\0CALCETrU34U3berTaEQbvNt0rfCdsjwj+xDb8x7bgAMFHEo=eUw@mail.gmail.com\0" "From\0Huang, Kai <kai.huang@intel.com>\0" "Subject\0Re: [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME)\0" - "Date\0Fri, 07 Dec 2018 01:55:45 +0000\0" + "Date\0Fri, 7 Dec 2018 01:55:45 +0000\0" "To\0luto@kernel.org <luto@kernel.org>" Hansen " Dave <dave.hansen@intel.com>\0" @@ -27,41 +27,47 @@ bp@alien8.de <bp@alien8.de> Schofield Alison <alison.schofield@intel.com> - " Nakajima\0" + Nakajima + " Jun <jun.nakajima@intel.com>\0" "\00:1\0" "b\0" - "DQo+IA0KPiBUTUUgaXRzZWxmIHByb3ZpZGVzIGEgdG9uIG9mIHByb3RlY3Rpb24gLS0geW91IGNh\n" - "bid0IGp1c3QgYmFyZ2UgaW50bw0KPiB0aGUgZGF0YWNlbnRlciwgcmVmcmlnZXJhdGUgdGhlIERJ\n" - "TU1zLCB3YWxrIGF3YXkgd2l0aCB0aGVtLCBhbmQgcmVhZA0KPiBvZmYgZXZlcnlvbmUncyBkYXRh\n" - "Lg0KPiANCj4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KSSB0aGluayB3ZSBjYW4gbWFrZSBz\n" - "dWNoIGFzc3VtcHRpb24gaW4gbW9zdCBjYXNlcywgYnV0IEkgdGhpbmsgaXQncyBiZXR0ZXIgdGhh\n" - "dCB3ZSBkb24ndCBtYWtlIGFueQ0KYXNzdW1wdGlvbiBhdCBhbGwuIEZvciBleGFtcGxlLCB0aGUg\n" - "YWRtaW4gb2YgZGF0YSBjZW50ZXIgKG9yIGFueW9uZSkgd2hvIGhhcyBwaHlzaWNhbCBhY2Nlc3Mg\n" - "dG8NCnNlcnZlcnMgbWF5IGRvIHNvbWV0aGluZyBtYWxpY2lvdXMuIEkgYW0gbm90IGV4cGVydCBi\n" - "dXQgdGhlcmUgc2hvdWxkIGJlIG90aGVyIHBoeXNpY2FsIGF0dGFjaw0KbWV0aG9kcyBiZXNpZGVz\n" - "IGNvbGRib290IGF0dGFjaywgaWYgdGhlIG1hbGljaW91cyBlbXBsb3llZSBjYW4gZ2V0IHBoeXNp\n" - "Y2FsIGFjY2VzcyB0byBzZXJ2ZXIgdy9vDQpiZWluZyBkZXRlY3RlZC4NCg0KPiANCj4gPiANCj4g\n" - "PiBCdXQsIEkgdGhpbmsgd2hhdCB5b3UncmUgaW1wbHlpbmcgaXMgdGhhdCB0aGUgc2VjdXJpdHkg\n" - "cHJvcGVydGllcyBvZg0KPiA+IHVzZXItc3VwcGxpZWQga2V5cyBjYW4gb25seSBiZSAqd29yc2Uq\n" - "IHRoYW4gdXNpbmcgQ1BVLWdlbmVyYXRlZCBrZXlzDQo+ID4gKGFzc3VtaW5nIHRoZSBDUFUgZG9l\n" - "cyBhIGdvb2Qgam9iIGdlbmVyYXRpbmcgaXQpLiAgU28sIHdoeSBib3RoZXINCj4gPiBhbGxvd2lu\n" - "ZyB1c2VyLXNwZWNpZmllZCBrZXlzIGluIHRoZSBmaXJzdCBwbGFjZT8NCj4gDQo+IFRoYXQgdG9v\n" - "IDopDQoNCkkgdGhpbmsgb25lIHVzYWdlIG9mIHVzZXItc3BlY2lmaWVkIGtleSBpcyBmb3IgTlZE\n" - "SU1NLCBzaW5jZSBDUFUga2V5IHdpbGwgYmUgZ29uZSBhZnRlciBtYWNoaW5lDQpyZWJvb3QsIHRo\n" - "ZXJlZm9yZSBpZiBOVkRJTU0gaXMgZW5jcnlwdGVkIGJ5IENQVSBrZXkgd2UgYXJlIG5vdCBhYmxl\n" - "IHRvIHJldHJpZXZlIGl0IG9uY2UNCnNodXRkb3duL3JlYm9vdCwgZXRjLg0KDQpUaGVyZSBhcmUg\n" - "c29tZSBvdGhlciB1c2UgY2FzZXMgdGhhdCBhbHJlYWR5IHJlcXVpcmUgdGVuYW50IHRvIHNlbmQg\n" - "a2V5IHRvIENTUC4gRm9yIGV4YW1wbGUsIHRoZSBWTQ0KaW1hZ2UgY2FuIGJlIHByb3ZpZGVkIGJ5\n" - "IHRlbmFudCBhbmQgZW5jcnlwdGVkIGJ5IHRlbmFudCdzIG93biBrZXksIGFuZCB0ZW5hbnQgbmVl\n" - "ZHMgdG8gc2VuZCBrZXkgdG8NCkNTUCB3aGVuIGFza2luZyBDU1AgdG8gcnVuIHRoYXQgZW5jcnlw\n" - "dGVkIGltYWdlLiBCdXQgdGVuYW50IHdpbGwgbmVlZCB0byB0cnVzdCBDU1AgaW4gc3VjaCBjYXNl\n" - "LA0Kd2hpY2ggYnJpbmdzIHVzIHdoeSB0ZW5hbnQgd2FudHMgdG8gdXNlIGhpcyBvd24gaW1hZ2Ug\n" - "YXQgZmlyc3QgcGxhY2UgKEkgaGF2ZSB0byBzYXkgSSBteXNlbGYgaXMgbm90DQpjb252aW5jZWQg\n" - "dGhlIHZhbHVlIG9mIHN1Y2ggdXNlIGNhc2UpLiBJIHRoaW5rIHRoZXJlIGFyZSB0d28gbGV2ZWxz\n" - "IG9mIHRydXN0aW5lc3MgaW52b2x2ZWQgaGVyZTogMSkNCnRlbmFudCBuZWVkcyB0byB0cnVzdCBD\n" - "U1AgYW55d2F5OyAyKSBidXQgQ1NQIG5lZWRzIHRvIGNvbnZpbmNlIHRlbmFudCB0aGF0IENTUCBj\n" - "YW4gYmUgdHJ1c3RlZCwgaWUsDQpieSBwcm92aW5nIGl0IGNhbiBwcmV2ZW50IHBvdGVudGlhbCBh\n" - "dHRhY2sgZnJvbSBtYWxpY2lvdXMgZW1wbG95ZWUgKGllLCBieSByYWlzaW5nIGJhciBieSB1c2lu\n" - Zw0KTUtUTUUpLCBldGMuDQoNClRoYW5rcywNCi1LYWk + "\n" + "> \n" + "> TME itself provides a ton of protection -- you can't just barge into\n" + "> the datacenter, refrigerate the DIMMs, walk away with them, and read\n" + "> off everyone's data.\n" + "> \n" + "> Am I missing something?\n" + "\n" + "I think we can make such assumption in most cases, but I think it's better that we don't make any\n" + "assumption at all. For example, the admin of data center (or anyone) who has physical access to\n" + "servers may do something malicious. I am not expert but there should be other physical attack\n" + "methods besides coldboot attack, if the malicious employee can get physical access to server w/o\n" + "being detected.\n" + "\n" + "> \n" + "> > \n" + "> > But, I think what you're implying is that the security properties of\n" + "> > user-supplied keys can only be *worse* than using CPU-generated keys\n" + "> > (assuming the CPU does a good job generating it). So, why bother\n" + "> > allowing user-specified keys in the first place?\n" + "> \n" + "> That too :)\n" + "\n" + "I think one usage of user-specified key is for NVDIMM, since CPU key will be gone after machine\n" + "reboot, therefore if NVDIMM is encrypted by CPU key we are not able to retrieve it once\n" + "shutdown/reboot, etc.\n" + "\n" + "There are some other use cases that already require tenant to send key to CSP. For example, the VM\n" + "image can be provided by tenant and encrypted by tenant's own key, and tenant needs to send key to\n" + "CSP when asking CSP to run that encrypted image. But tenant will need to trust CSP in such case,\n" + "which brings us why tenant wants to use his own image at first place (I have to say I myself is not\n" + "convinced the value of such use case). I think there are two levels of trustiness involved here: 1)\n" + "tenant needs to trust CSP anyway; 2) but CSP needs to convince tenant that CSP can be trusted, ie,\n" + "by proving it can prevent potential attack from malicious employee (ie, by raising bar by using\n" + "MKTME), etc.\n" + "\n" + "Thanks,\n" + -Kai -0185be5e3f9e38c197a9c62a786d2c428338a6daea3121c3868e3ea73ae71925 +54c762d722511291c42c50d0041f801abf6ed252ec1bb777b6908ba395b91250
diff --git a/a/1.txt b/N2/1.txt index 2eb28f3..e1c94ea 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,33 +1,38 @@ -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 + +> +> 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 diff --git a/a/content_digest b/N2/content_digest index b31d0b3..87014fa 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -4,7 +4,7 @@ "ref\0CALCETrU34U3berTaEQbvNt0rfCdsjwj+xDb8x7bgAMFHEo=eUw@mail.gmail.com\0" "From\0Huang, Kai <kai.huang@intel.com>\0" "Subject\0Re: [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME)\0" - "Date\0Fri, 07 Dec 2018 01:55:45 +0000\0" + "Date\0Fri, 7 Dec 2018 01:55:45 +0000\0" "To\0luto@kernel.org <luto@kernel.org>" Hansen " Dave <dave.hansen@intel.com>\0" @@ -27,41 +27,47 @@ bp@alien8.de <bp@alien8.de> Schofield Alison <alison.schofield@intel.com> - " Nakajima\0" + Nakajima + "\0" "\00:1\0" "b\0" - "DQo+IA0KPiBUTUUgaXRzZWxmIHByb3ZpZGVzIGEgdG9uIG9mIHByb3RlY3Rpb24gLS0geW91IGNh\n" - "bid0IGp1c3QgYmFyZ2UgaW50bw0KPiB0aGUgZGF0YWNlbnRlciwgcmVmcmlnZXJhdGUgdGhlIERJ\n" - "TU1zLCB3YWxrIGF3YXkgd2l0aCB0aGVtLCBhbmQgcmVhZA0KPiBvZmYgZXZlcnlvbmUncyBkYXRh\n" - "Lg0KPiANCj4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KSSB0aGluayB3ZSBjYW4gbWFrZSBz\n" - "dWNoIGFzc3VtcHRpb24gaW4gbW9zdCBjYXNlcywgYnV0IEkgdGhpbmsgaXQncyBiZXR0ZXIgdGhh\n" - "dCB3ZSBkb24ndCBtYWtlIGFueQ0KYXNzdW1wdGlvbiBhdCBhbGwuIEZvciBleGFtcGxlLCB0aGUg\n" - "YWRtaW4gb2YgZGF0YSBjZW50ZXIgKG9yIGFueW9uZSkgd2hvIGhhcyBwaHlzaWNhbCBhY2Nlc3Mg\n" - "dG8NCnNlcnZlcnMgbWF5IGRvIHNvbWV0aGluZyBtYWxpY2lvdXMuIEkgYW0gbm90IGV4cGVydCBi\n" - "dXQgdGhlcmUgc2hvdWxkIGJlIG90aGVyIHBoeXNpY2FsIGF0dGFjaw0KbWV0aG9kcyBiZXNpZGVz\n" - "IGNvbGRib290IGF0dGFjaywgaWYgdGhlIG1hbGljaW91cyBlbXBsb3llZSBjYW4gZ2V0IHBoeXNp\n" - "Y2FsIGFjY2VzcyB0byBzZXJ2ZXIgdy9vDQpiZWluZyBkZXRlY3RlZC4NCg0KPiANCj4gPiANCj4g\n" - "PiBCdXQsIEkgdGhpbmsgd2hhdCB5b3UncmUgaW1wbHlpbmcgaXMgdGhhdCB0aGUgc2VjdXJpdHkg\n" - "cHJvcGVydGllcyBvZg0KPiA+IHVzZXItc3VwcGxpZWQga2V5cyBjYW4gb25seSBiZSAqd29yc2Uq\n" - "IHRoYW4gdXNpbmcgQ1BVLWdlbmVyYXRlZCBrZXlzDQo+ID4gKGFzc3VtaW5nIHRoZSBDUFUgZG9l\n" - "cyBhIGdvb2Qgam9iIGdlbmVyYXRpbmcgaXQpLiAgU28sIHdoeSBib3RoZXINCj4gPiBhbGxvd2lu\n" - "ZyB1c2VyLXNwZWNpZmllZCBrZXlzIGluIHRoZSBmaXJzdCBwbGFjZT8NCj4gDQo+IFRoYXQgdG9v\n" - "IDopDQoNCkkgdGhpbmsgb25lIHVzYWdlIG9mIHVzZXItc3BlY2lmaWVkIGtleSBpcyBmb3IgTlZE\n" - "SU1NLCBzaW5jZSBDUFUga2V5IHdpbGwgYmUgZ29uZSBhZnRlciBtYWNoaW5lDQpyZWJvb3QsIHRo\n" - "ZXJlZm9yZSBpZiBOVkRJTU0gaXMgZW5jcnlwdGVkIGJ5IENQVSBrZXkgd2UgYXJlIG5vdCBhYmxl\n" - "IHRvIHJldHJpZXZlIGl0IG9uY2UNCnNodXRkb3duL3JlYm9vdCwgZXRjLg0KDQpUaGVyZSBhcmUg\n" - "c29tZSBvdGhlciB1c2UgY2FzZXMgdGhhdCBhbHJlYWR5IHJlcXVpcmUgdGVuYW50IHRvIHNlbmQg\n" - "a2V5IHRvIENTUC4gRm9yIGV4YW1wbGUsIHRoZSBWTQ0KaW1hZ2UgY2FuIGJlIHByb3ZpZGVkIGJ5\n" - "IHRlbmFudCBhbmQgZW5jcnlwdGVkIGJ5IHRlbmFudCdzIG93biBrZXksIGFuZCB0ZW5hbnQgbmVl\n" - "ZHMgdG8gc2VuZCBrZXkgdG8NCkNTUCB3aGVuIGFza2luZyBDU1AgdG8gcnVuIHRoYXQgZW5jcnlw\n" - "dGVkIGltYWdlLiBCdXQgdGVuYW50IHdpbGwgbmVlZCB0byB0cnVzdCBDU1AgaW4gc3VjaCBjYXNl\n" - "LA0Kd2hpY2ggYnJpbmdzIHVzIHdoeSB0ZW5hbnQgd2FudHMgdG8gdXNlIGhpcyBvd24gaW1hZ2Ug\n" - "YXQgZmlyc3QgcGxhY2UgKEkgaGF2ZSB0byBzYXkgSSBteXNlbGYgaXMgbm90DQpjb252aW5jZWQg\n" - "dGhlIHZhbHVlIG9mIHN1Y2ggdXNlIGNhc2UpLiBJIHRoaW5rIHRoZXJlIGFyZSB0d28gbGV2ZWxz\n" - "IG9mIHRydXN0aW5lc3MgaW52b2x2ZWQgaGVyZTogMSkNCnRlbmFudCBuZWVkcyB0byB0cnVzdCBD\n" - "U1AgYW55d2F5OyAyKSBidXQgQ1NQIG5lZWRzIHRvIGNvbnZpbmNlIHRlbmFudCB0aGF0IENTUCBj\n" - "YW4gYmUgdHJ1c3RlZCwgaWUsDQpieSBwcm92aW5nIGl0IGNhbiBwcmV2ZW50IHBvdGVudGlhbCBh\n" - "dHRhY2sgZnJvbSBtYWxpY2lvdXMgZW1wbG95ZWUgKGllLCBieSByYWlzaW5nIGJhciBieSB1c2lu\n" - Zw0KTUtUTUUpLCBldGMuDQoNClRoYW5rcywNCi1LYWk + "\n" + "> \n" + "> TME itself provides a ton of protection -- you can't just barge into\n" + "> the datacenter, refrigerate the DIMMs, walk away with them, and read\n" + "> off everyone's data.\n" + "> \n" + "> Am I missing something?\n" + "\n" + "I think we can make such assumption in most cases, but I think it's better that we don't make any\n" + "assumption at all. For example, the admin of data center (or anyone) who has physical access to\n" + "servers may do something malicious. I am not expert but there should be other physical attack\n" + "methods besides coldboot attack, if the malicious employee can get physical access to server w/o\n" + "being detected.\n" + "\n" + "> \n" + "> > \n" + "> > But, I think what you're implying is that the security properties of\n" + "> > user-supplied keys can only be *worse* than using CPU-generated keys\n" + "> > (assuming the CPU does a good job generating it). So, why bother\n" + "> > allowing user-specified keys in the first place?\n" + "> \n" + "> That too :)\n" + "\n" + "I think one usage of user-specified key is for NVDIMM, since CPU key will be gone after machine\n" + "reboot, therefore if NVDIMM is encrypted by CPU key we are not able to retrieve it once\n" + "shutdown/reboot, etc.\n" + "\n" + "There are some other use cases that already require tenant to send key to CSP. For example, the VM\n" + "image can be provided by tenant and encrypted by tenant's own key, and tenant needs to send key to\n" + "CSP when asking CSP to run that encrypted image. But tenant will need to trust CSP in such case,\n" + "which brings us why tenant wants to use his own image at first place (I have to say I myself is not\n" + "convinced the value of such use case). I think there are two levels of trustiness involved here: 1)\n" + "tenant needs to trust CSP anyway; 2) but CSP needs to convince tenant that CSP can be trusted, ie,\n" + "by proving it can prevent potential attack from malicious employee (ie, by raising bar by using\n" + "MKTME), etc.\n" + "\n" + "Thanks,\n" + -Kai -0185be5e3f9e38c197a9c62a786d2c428338a6daea3121c3868e3ea73ae71925 +47e9b640b768525f463a706e78d2fcaa08567dd28db28d5c280b5ca8cad30e43
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.