diff for duplicates of <1544234854.28511.60.camel@intel.com> diff --git a/a/1.txt b/N1/1.txt index bafbb06..2bb8c3a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,47 +1,46 @@ -DQo+ID4gVGhlcmUgYXJlIHNvbWUgb3RoZXIgdXNlIGNhc2VzIHRoYXQgYWxyZWFkeSByZXF1aXJl -IHRlbmFudCB0byBzZW5kIGtleSB0byBDU1AuIEZvciBleGFtcGxlLCB0aGUNCj4gPiBWTQ0KPiA+ -IGltYWdlIGNhbiBiZSBwcm92aWRlZCBieSB0ZW5hbnQgYW5kIGVuY3J5cHRlZCBieSB0ZW5hbnQn -cyBvd24ga2V5LCBhbmQgdGVuYW50IG5lZWRzIHRvIHNlbmQga2V5DQo+ID4gdG8NCj4gPiBDU1Ag -d2hlbiBhc2tpbmcgQ1NQIHRvIHJ1biB0aGF0IGVuY3J5cHRlZCBpbWFnZS4NCj4gDQo+IA0KPiBJ -IGNhbiBpbWFnaW5lIGEgZmV3IHJlYXNvbnMgd2h5IG9uZSB3b3VsZCB3YW50IHRvIGVuY3J5cHQg -b25l4oCZcyBpbWFnZS4NCj4gRm9yIGV4YW1wbGUsIHRoZSBDU1AgY291bGQgaXNzdWUgYSBwdWJs -aWMga2V5IGFuZCBzdGF0ZSwgb3IgZXZlbg0KPiBhdHRlc3QsIHRoYXQgdGhlIGtleSBpcyB3cmFw -cGVkIGFuZCBsb2NrZWQgdG8gcGFydGljdWxhciBQQ1JzIG9mIHRoZWlyDQo+IFRQTSBvciBvdGhl -cndpc2UgcHJvdGVjdGVkIGJ5IGFuIGVuY2xhdmUgdGhhdCB2ZXJpZmllcyB0aGF0IHRoZSBrZXkg -aXMNCj4gb25seSB1c2VkIHRvIGRlY3J5cHQgdGhlIGltYWdlIGZvciB0aGUgYmVuZWZpdCBvZiBh -IGh5cGVydmlzb3IuDQoNClJpZ2h0LiBJIHRoaW5rIGJlZm9yZSB0ZW5hbnQgcmVsZWFzZXMga2V5 -IHRvIENTUCBpdCBzaG91bGQgYWx3YXlzIHVzZSBhdHRlc3RhdGlvbiBhdXRob3JpdHkgdG8NCnZl -cmlmeSB0aGUgdHJ1c3RpbmVzcyBvZiBjb21wdXRlciBub2RlLiBJIGNhbiB1bmRlcnN0YW5kIHRo -YXQgdGhlIGtleSBjYW4gYmUgd3JhcHBlZCBieSBUUE0gYmVmb3JlDQpzZW5kaW5nIHRvIENTUCBi -dXQgbmVlZCBzb21lIGNhdGNoIHVwIGFib3V0IHVzaW5nIGVuY2xhdmUgcGFydC4gDQoNClRoZSB0 -aGluZyBpcyBjb21wdXRlciBub2RlIGNhbiBiZSB0cnVzdGVkIGRvZXNuJ3QgbWVhbiBpdCBjYW5u -b3QgYmUgYXR0YWNrZWQsIG9yIGV2ZW4gaXQgZG9lc24ndA0KbWVhbiBpdCBjYW4gcHJldmVudCwg -aWUgc29tZSBtYWxpY2lvdXMgYWRtaW4sIHRvIGdldCB0ZW5hbnQga2V5IGV2ZW4gYnkgdXNpbmcg -bGVnaXRpbWF0ZSB3YXkuIFRoZXJlDQphcmUgbWFueSBTVyBjb21wb25lbnRzIGludm9sdmVkIGhl -cmUuIEFueXdheSB0aGlzIGlzIG5vdCByZWxhdGVkIHRvIE1LVE1FIGl0c2VsZiBsaWtlIHlvdSBt -ZW50aW9uZWQNCmJlbG93LCB0aGVyZWZvcmUgdGhlIHBvaW50IGlzLCBhcyB3ZSBhbHJlYWR5IHNl -ZSBNS1RNRSBpdHNlbGYgcHJvdmlkZXMgdmVyeSB3ZWFrIHNlY3VyaXR5DQpwcm90ZWN0aW9uLCB3 -ZSBuZWVkIHRvIHNlZSB3aGV0aGVyIE1LVE1FIGhhcyB2YWx1ZSBmcm9tIHRoZSB3aG9sZSB1c2Ug -Y2FzZSdzIHBvaW50IG9mIHZpZXcNCihpbmNsdWRpbmcgYWxsIHRoZSB0aGluZ3MgeW91IG1lbnRp -b25lZCBhYm92ZSkgLS0gd2UgZGVmaW5lIHRoZSB3aG9sZSB1c2UgY2FzZSwgd2UgY2xlYXJseSBz -dGF0ZQ0Kd2hvL3doYXQgc2hvdWxkIGJlIGluIHRydXN0IGJvdW5kYXJ5LCBhbmQgd2hhdCB3ZSBj -YW4gcHJldmVudCwgZXRjLg0KDQo+IA0KPiBJIGRvbuKAmXQgc2VlIHdoYXQgTUtUTUUgaGFzIHRv -IGRvIHdpdGggdGhpcy4gVGhlIG9ubHkgcmVtb3RlbHkNCj4gcGxhdXNpYmxlIHdheSBJIGNhbiBz -ZWUgdG8gdXNlIE1LVE1FIGZvciB0aGlzIGlzIHRvIGhhdmUgdGhlDQo+IGh5cGVydmlzb3IgbG9h -ZCBhIFRQTSAob3Igb3RoZXIgZW5jbGF2ZSkgcHJvdGVjdGVkIGtleSBpbnRvIGFuIE1LVE1FDQo+ -IHVzZXIga2V5IHNsb3QgYW5kIHRvIGxvYWQgY3VzdG9tZXItcHJvdmlkZWQgY2lwaGVydGV4dCBp -bnRvIHRoZQ0KPiBjb3JyZXNwb25kaW5nIHBoeXNpY2FsIG1lbW9yeSAodXNpbmcgYW4gTUtUTUUg -bm8tZW5jcnlwdCBzbG90KS4gIEJ1dA0KPiB0aGlzIGhhcyB0aHJlZSBtYWpvciBwcm9ibGVtcy4g -IEZpcnN0LCBpdCdzIGVmZmVjdGl2ZWx5IGp1c3QgYSBmYW5jeQ0KPiB3YXkgdG8gYXZvaWQgb25l -IEFFUyBwYXNzIG92ZXIgdGhlIGRhdGEuICBTZWNvbmQsIHNlbnNpYmxlIHNjaGVtZSBmb3INCj4g -dGhpcyB0eXBlIG9mIFZNIGltYWdlIHByb3RlY3Rpb24gd291bGQgdXNlICphdXRoZW50aWNhdGVk -KiBlbmNyeXB0aW9uDQo+IG9yIGF0IGxlYXN0IHZlcmlmeSBhIHNpZ25hdHVyZSwgd2hpY2ggTUtU -TUUgY2FuJ3QgZG8uICBUaGUgdGhpcmQNCj4gcHJvYmxlbSBpcyB0aGUgcmVhbCBzaG93LXN0b3Bw -ZXIsIHRob3VnaDogdGhpcyBzY2hlbWUgcmVxdWlyZXMgdGhhdA0KPiB0aGUgY2lwaGVydGV4dCBn -byBpbnRvIHByZWRldGVybWluZWQgcGh5c2ljYWwgYWRkcmVzc2VzLCB3aGljaCB3b3VsZA0KPiBi -ZSBhIGdpYW50IG1lc3MuDQoNCk15IGludGVudGlvbiB3YXMgdG8gc2F5IGlmIHdlIGFyZSBhbHJl -YWR5IHNlbmRpbmcga2V5IHRvIENTUCwgdGhlbiB3ZSBtYXkgcHJlZmVyIHRvIHVzZSB0aGUga2V5 -IGZvcg0KTUtUTUUgVk0gcnVudGltZSBwcm90ZWN0aW9uIGFzIHdlbGwsIGJ1dCBsaWtlIHlvdSBz -YWlkIHdlIG1heSBub3QgaGF2ZSByZWFsIHNlY3VyaXR5IGdhaW4gaGVyZQ0KY29tcGFyaW5nIHRv -IFRNRSwgc28gSSBhZ3JlZSB3ZSBuZWVkIHRvIGZpbmQgb3V0IG9uZSBzcGVjaWZpYyBjYXNlIHRv -IHByb3ZlIHRoYXQuDQoNClRoYW5rcywNCi1LYWk + +> > 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. +> +> +> I can imagine a few reasons why one would want to encrypt one’s image. +> For example, the CSP could issue a public key and state, or even +> attest, that the key is wrapped and locked to particular PCRs of their +> TPM or otherwise protected by an enclave that verifies that the key is +> only used to decrypt the image for the benefit of a hypervisor. + +Right. I think before tenant releases key to CSP it should always use attestation authority to +verify the trustiness of computer node. I can understand that the key can be wrapped by TPM before +sending to CSP but need some catch up about using enclave part. + +The thing is computer node can be trusted doesn't mean it cannot be attacked, or even it doesn't +mean it can prevent, ie some malicious admin, to get tenant key even by using legitimate way. There +are many SW components involved here. Anyway this is not related to MKTME itself like you mentioned +below, therefore the point is, as we already see MKTME itself provides very weak security +protection, we need to see whether MKTME has value from the whole use case's point of view +(including all the things you mentioned above) -- we define the whole use case, we clearly state +who/what should be in trust boundary, and what we can prevent, etc. + +> +> I don’t see what MKTME has to do with this. The only remotely +> plausible way I can see to use MKTME for this is to have the +> hypervisor load a TPM (or other enclave) protected key into an MKTME +> user key slot and to load customer-provided ciphertext into the +> corresponding physical memory (using an MKTME no-encrypt slot). But +> this has three major problems. First, it's effectively just a fancy +> way to avoid one AES pass over the data. Second, sensible scheme for +> this type of VM image protection would use *authenticated* encryption +> or at least verify a signature, which MKTME can't do. The third +> problem is the real show-stopper, though: this scheme requires that +> the ciphertext go into predetermined physical addresses, which would +> be a giant mess. + +My intention was to say if we are already sending key to CSP, then we may prefer to use the key for +MKTME VM runtime protection as well, but like you said we may not have real security gain here +comparing to TME, so I agree we need to find out one specific case to prove that. + +Thanks, +-Kai diff --git a/a/content_digest b/N1/content_digest index a5f7a90..2d69f3d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,7 +6,7 @@ "ref\0CALCETrWHqE-H1jTJY-ApuuLt5cyZ3N1UdgH+szgYm+7mUMZ2pg@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\0Sat, 08 Dec 2018 02:07:41 +0000\0" + "Date\0Sat, 8 Dec 2018 02:07:41 +0000\0" "To\0luto@kernel.org <luto@kernel.org>\0" "Cc\0kirill.shutemov@linux.intel.com <kirill.shutemov@linux.intel.com>" jmorris@namei.org <jmorris@namei.org> @@ -33,52 +33,51 @@ " Jun <jun.nakajima@intel.com>\0" "\00:1\0" "b\0" - "DQo+ID4gVGhlcmUgYXJlIHNvbWUgb3RoZXIgdXNlIGNhc2VzIHRoYXQgYWxyZWFkeSByZXF1aXJl\n" - "IHRlbmFudCB0byBzZW5kIGtleSB0byBDU1AuIEZvciBleGFtcGxlLCB0aGUNCj4gPiBWTQ0KPiA+\n" - "IGltYWdlIGNhbiBiZSBwcm92aWRlZCBieSB0ZW5hbnQgYW5kIGVuY3J5cHRlZCBieSB0ZW5hbnQn\n" - "cyBvd24ga2V5LCBhbmQgdGVuYW50IG5lZWRzIHRvIHNlbmQga2V5DQo+ID4gdG8NCj4gPiBDU1Ag\n" - "d2hlbiBhc2tpbmcgQ1NQIHRvIHJ1biB0aGF0IGVuY3J5cHRlZCBpbWFnZS4NCj4gDQo+IA0KPiBJ\n" - "IGNhbiBpbWFnaW5lIGEgZmV3IHJlYXNvbnMgd2h5IG9uZSB3b3VsZCB3YW50IHRvIGVuY3J5cHQg\n" - "b25l4oCZcyBpbWFnZS4NCj4gRm9yIGV4YW1wbGUsIHRoZSBDU1AgY291bGQgaXNzdWUgYSBwdWJs\n" - "aWMga2V5IGFuZCBzdGF0ZSwgb3IgZXZlbg0KPiBhdHRlc3QsIHRoYXQgdGhlIGtleSBpcyB3cmFw\n" - "cGVkIGFuZCBsb2NrZWQgdG8gcGFydGljdWxhciBQQ1JzIG9mIHRoZWlyDQo+IFRQTSBvciBvdGhl\n" - "cndpc2UgcHJvdGVjdGVkIGJ5IGFuIGVuY2xhdmUgdGhhdCB2ZXJpZmllcyB0aGF0IHRoZSBrZXkg\n" - "aXMNCj4gb25seSB1c2VkIHRvIGRlY3J5cHQgdGhlIGltYWdlIGZvciB0aGUgYmVuZWZpdCBvZiBh\n" - "IGh5cGVydmlzb3IuDQoNClJpZ2h0LiBJIHRoaW5rIGJlZm9yZSB0ZW5hbnQgcmVsZWFzZXMga2V5\n" - "IHRvIENTUCBpdCBzaG91bGQgYWx3YXlzIHVzZSBhdHRlc3RhdGlvbiBhdXRob3JpdHkgdG8NCnZl\n" - "cmlmeSB0aGUgdHJ1c3RpbmVzcyBvZiBjb21wdXRlciBub2RlLiBJIGNhbiB1bmRlcnN0YW5kIHRo\n" - "YXQgdGhlIGtleSBjYW4gYmUgd3JhcHBlZCBieSBUUE0gYmVmb3JlDQpzZW5kaW5nIHRvIENTUCBi\n" - "dXQgbmVlZCBzb21lIGNhdGNoIHVwIGFib3V0IHVzaW5nIGVuY2xhdmUgcGFydC4gDQoNClRoZSB0\n" - "aGluZyBpcyBjb21wdXRlciBub2RlIGNhbiBiZSB0cnVzdGVkIGRvZXNuJ3QgbWVhbiBpdCBjYW5u\n" - "b3QgYmUgYXR0YWNrZWQsIG9yIGV2ZW4gaXQgZG9lc24ndA0KbWVhbiBpdCBjYW4gcHJldmVudCwg\n" - "aWUgc29tZSBtYWxpY2lvdXMgYWRtaW4sIHRvIGdldCB0ZW5hbnQga2V5IGV2ZW4gYnkgdXNpbmcg\n" - "bGVnaXRpbWF0ZSB3YXkuIFRoZXJlDQphcmUgbWFueSBTVyBjb21wb25lbnRzIGludm9sdmVkIGhl\n" - "cmUuIEFueXdheSB0aGlzIGlzIG5vdCByZWxhdGVkIHRvIE1LVE1FIGl0c2VsZiBsaWtlIHlvdSBt\n" - "ZW50aW9uZWQNCmJlbG93LCB0aGVyZWZvcmUgdGhlIHBvaW50IGlzLCBhcyB3ZSBhbHJlYWR5IHNl\n" - "ZSBNS1RNRSBpdHNlbGYgcHJvdmlkZXMgdmVyeSB3ZWFrIHNlY3VyaXR5DQpwcm90ZWN0aW9uLCB3\n" - "ZSBuZWVkIHRvIHNlZSB3aGV0aGVyIE1LVE1FIGhhcyB2YWx1ZSBmcm9tIHRoZSB3aG9sZSB1c2Ug\n" - "Y2FzZSdzIHBvaW50IG9mIHZpZXcNCihpbmNsdWRpbmcgYWxsIHRoZSB0aGluZ3MgeW91IG1lbnRp\n" - "b25lZCBhYm92ZSkgLS0gd2UgZGVmaW5lIHRoZSB3aG9sZSB1c2UgY2FzZSwgd2UgY2xlYXJseSBz\n" - "dGF0ZQ0Kd2hvL3doYXQgc2hvdWxkIGJlIGluIHRydXN0IGJvdW5kYXJ5LCBhbmQgd2hhdCB3ZSBj\n" - "YW4gcHJldmVudCwgZXRjLg0KDQo+IA0KPiBJIGRvbuKAmXQgc2VlIHdoYXQgTUtUTUUgaGFzIHRv\n" - "IGRvIHdpdGggdGhpcy4gVGhlIG9ubHkgcmVtb3RlbHkNCj4gcGxhdXNpYmxlIHdheSBJIGNhbiBz\n" - "ZWUgdG8gdXNlIE1LVE1FIGZvciB0aGlzIGlzIHRvIGhhdmUgdGhlDQo+IGh5cGVydmlzb3IgbG9h\n" - "ZCBhIFRQTSAob3Igb3RoZXIgZW5jbGF2ZSkgcHJvdGVjdGVkIGtleSBpbnRvIGFuIE1LVE1FDQo+\n" - "IHVzZXIga2V5IHNsb3QgYW5kIHRvIGxvYWQgY3VzdG9tZXItcHJvdmlkZWQgY2lwaGVydGV4dCBp\n" - "bnRvIHRoZQ0KPiBjb3JyZXNwb25kaW5nIHBoeXNpY2FsIG1lbW9yeSAodXNpbmcgYW4gTUtUTUUg\n" - "bm8tZW5jcnlwdCBzbG90KS4gIEJ1dA0KPiB0aGlzIGhhcyB0aHJlZSBtYWpvciBwcm9ibGVtcy4g\n" - "IEZpcnN0LCBpdCdzIGVmZmVjdGl2ZWx5IGp1c3QgYSBmYW5jeQ0KPiB3YXkgdG8gYXZvaWQgb25l\n" - "IEFFUyBwYXNzIG92ZXIgdGhlIGRhdGEuICBTZWNvbmQsIHNlbnNpYmxlIHNjaGVtZSBmb3INCj4g\n" - "dGhpcyB0eXBlIG9mIFZNIGltYWdlIHByb3RlY3Rpb24gd291bGQgdXNlICphdXRoZW50aWNhdGVk\n" - "KiBlbmNyeXB0aW9uDQo+IG9yIGF0IGxlYXN0IHZlcmlmeSBhIHNpZ25hdHVyZSwgd2hpY2ggTUtU\n" - "TUUgY2FuJ3QgZG8uICBUaGUgdGhpcmQNCj4gcHJvYmxlbSBpcyB0aGUgcmVhbCBzaG93LXN0b3Bw\n" - "ZXIsIHRob3VnaDogdGhpcyBzY2hlbWUgcmVxdWlyZXMgdGhhdA0KPiB0aGUgY2lwaGVydGV4dCBn\n" - "byBpbnRvIHByZWRldGVybWluZWQgcGh5c2ljYWwgYWRkcmVzc2VzLCB3aGljaCB3b3VsZA0KPiBi\n" - "ZSBhIGdpYW50IG1lc3MuDQoNCk15IGludGVudGlvbiB3YXMgdG8gc2F5IGlmIHdlIGFyZSBhbHJl\n" - "YWR5IHNlbmRpbmcga2V5IHRvIENTUCwgdGhlbiB3ZSBtYXkgcHJlZmVyIHRvIHVzZSB0aGUga2V5\n" - "IGZvcg0KTUtUTUUgVk0gcnVudGltZSBwcm90ZWN0aW9uIGFzIHdlbGwsIGJ1dCBsaWtlIHlvdSBz\n" - "YWlkIHdlIG1heSBub3QgaGF2ZSByZWFsIHNlY3VyaXR5IGdhaW4gaGVyZQ0KY29tcGFyaW5nIHRv\n" - "IFRNRSwgc28gSSBhZ3JlZSB3ZSBuZWVkIHRvIGZpbmQgb3V0IG9uZSBzcGVjaWZpYyBjYXNlIHRv\n" - IHByb3ZlIHRoYXQuDQoNClRoYW5rcywNCi1LYWk + "\n" + "> > There are some other use cases that already require tenant to send key to CSP. For example, the\n" + "> > VM\n" + "> > image can be provided by tenant and encrypted by tenant's own key, and tenant needs to send key\n" + "> > to\n" + "> > CSP when asking CSP to run that encrypted image.\n" + "> \n" + "> \n" + "> I can imagine a few reasons why one would want to encrypt one\342\200\231s image.\n" + "> For example, the CSP could issue a public key and state, or even\n" + "> attest, that the key is wrapped and locked to particular PCRs of their\n" + "> TPM or otherwise protected by an enclave that verifies that the key is\n" + "> only used to decrypt the image for the benefit of a hypervisor.\n" + "\n" + "Right. I think before tenant releases key to CSP it should always use attestation authority to\n" + "verify the trustiness of computer node. I can understand that the key can be wrapped by TPM before\n" + "sending to CSP but need some catch up about using enclave part. \n" + "\n" + "The thing is computer node can be trusted doesn't mean it cannot be attacked, or even it doesn't\n" + "mean it can prevent, ie some malicious admin, to get tenant key even by using legitimate way. There\n" + "are many SW components involved here. Anyway this is not related to MKTME itself like you mentioned\n" + "below, therefore the point is, as we already see MKTME itself provides very weak security\n" + "protection, we need to see whether MKTME has value from the whole use case's point of view\n" + "(including all the things you mentioned above) -- we define the whole use case, we clearly state\n" + "who/what should be in trust boundary, and what we can prevent, etc.\n" + "\n" + "> \n" + "> I don\342\200\231t see what MKTME has to do with this. The only remotely\n" + "> plausible way I can see to use MKTME for this is to have the\n" + "> hypervisor load a TPM (or other enclave) protected key into an MKTME\n" + "> user key slot and to load customer-provided ciphertext into the\n" + "> corresponding physical memory (using an MKTME no-encrypt slot). But\n" + "> this has three major problems. First, it's effectively just a fancy\n" + "> way to avoid one AES pass over the data. Second, sensible scheme for\n" + "> this type of VM image protection would use *authenticated* encryption\n" + "> or at least verify a signature, which MKTME can't do. The third\n" + "> problem is the real show-stopper, though: this scheme requires that\n" + "> the ciphertext go into predetermined physical addresses, which would\n" + "> be a giant mess.\n" + "\n" + "My intention was to say if we are already sending key to CSP, then we may prefer to use the key for\n" + "MKTME VM runtime protection as well, but like you said we may not have real security gain here\n" + "comparing to TME, so I agree we need to find out one specific case to prove that.\n" + "\n" + "Thanks,\n" + -Kai -e3021c9d7785c44572be8677eaceb28ee78fabcd78a475a18794bb5a5a978bca +cc43f329ebf92fd31c16bc4ca3c11076f803403c060080059c75d1fd6c9fce77
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.