diff for duplicates of <1544148344.28511.21.camel@intel.com> diff --git a/a/1.txt b/N1/1.txt index 53751c0..f860c00 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,36 +1,38 @@ -T24gV2VkLCAyMDE4LTEyLTA1IGF0IDIyOjE5ICswMDAwLCBTYWtraW5lbiwgSmFya2tvIHdyb3Rl -Og0KPiBPbiBUdWUsIDIwMTgtMTItMDQgYXQgMTE6MTkgLTA4MDAsIEFuZHkgTHV0b21pcnNraSB3 -cm90ZToNCj4gPiBJJ20gbm90IFRob21hcywgYnV0IEkgdGhpbmsgaXQncyB0aGUgd3JvbmcgZGly -ZWN0aW9uLiAgQXMgaXQgc3RhbmRzLA0KPiA+IGVuY3J5cHRfbXByb3RlY3QoKSBpcyBhbiBpbmNv -bXBsZXRlIHZlcnNpb24gb2YgbXByb3RlY3QoKSAoc2luY2UgaXQncw0KPiA+IG1pc3NpbmcgdGhl -IHByb3RlY3Rpb24ga2V5IHN1cHBvcnQpLCBhbmQgaXQncyBhbHNvIGZ1bmN0aW9uYWxseSBqdXN0 -DQo+ID4gTUFEVl9ET05UTkVFRC4gIEluIG90aGVyIHdvcmRzLCB0aGUgc29sZSB1c2VyLXZpc2li -bGUgZWZmZWN0IGFwcGVhcnMNCj4gPiB0byBiZSB0aGF0IHRoZSBleGlzdGluZyBwYWdlcyBhcmUg -Ymxvd24gYXdheS4gIFRoZSBmYWN0IHRoYXQgaXQNCj4gPiBjaGFuZ2VzIHRoZSBrZXkgaW4gdXNl -IGRvZXNuJ3Qgc2VlbSB0ZXJyaWJseSB1c2VmdWwsIHNpbmNlIGl0J3MNCj4gPiBhbm9ueW1vdXMg -bWVtb3J5LCBhbmQgdGhlIG1vc3Qgc2VjdXJlIGNob2ljZSBpcyB0byB1c2UgQ1BVLW1hbmFnZWQN -Cj4gPiBrZXlpbmcsIHdoaWNoIGFwcGVhcnMgdG8gYmUgdGhlIGRlZmF1bHQgYW55d2F5IG9uIFRN -RSBzeXN0ZW1zLiAgSXQNCj4gPiBhbHNvIGhhcyB0b3RhbGx5IHVuY2xlYXIgc2VtYW50aWNzIFdS -VCBzd2FwLCBhbmQsIG9mZiB0aGUgdG9wIG9mIG15DQo+ID4gaGVhZCwgaXQgbG9va3MgbGlrZSBp -dCBtYXkgaGF2ZSBzZXJpb3VzIGNhY2hlLWNvaGVyZW5jeSBpc3N1ZXMgYW5kDQo+ID4gbGlrZSBz -d2FwcGluZyB0aGUgcGFnZXMgbWlnaHQgY29ycnVwdCB0aGVtLCBib3RoIGJlY2F1c2UgdGhlcmUg -YXJlIG5vDQo+ID4gZmx1c2hlcyBhbmQgYmVjYXVzZSB0aGUgZGlyZWN0LW1hcCBhbGlhcyBsb29r -cyBsaWtlIGl0IHdpbGwgdXNlIHRoZQ0KPiA+IGRlZmF1bHQga2V5IGFuZCB0aGVyZWZvcmUgYXBw -ZWFyIHRvIGNvbnRhaW4gdGhlIHdyb25nIGRhdGEuDQo+ID4gDQo+ID4gSSB3b3VsZCBwcm9wb3Nl -IGEgdmVyeSBkaWZmZXJlbnQgZGlyZWN0aW9uOiBkb24ndCB0cnkgdG8gc3VwcG9ydCBNS1RNRQ0K -PiA+IGF0IGFsbCBmb3IgYW5vbnltb3VzIG1lbW9yeSwgYW5kIGluc3RlYWQgZmlndXJlIG91dCB0 -aGUgaW1wb3J0YW50IHVzZQ0KPiA+IGNhc2VzIGFuZCBzdXBwb3J0IHRoZW0gZGlyZWN0bHkuICBU -aGUgdXNlIGNhc2VzIHRoYXQgSSBjYW4gdGhpbmsgb2YNCj4gPiBvZmYgdGhlIHRvcCBvZiBteSBo -ZWFkIGFyZToNCj4gPiANCj4gPiAxLiBwbWVtLiAgVGhpcyBzaG91bGQgcHJvYmFibHkgdXNlIGEg -dmVyeSBkaWZmZXJlbnQgQVBJLg0KPiA+IA0KPiA+IDIuIFNvbWUga2luZCBvZiBWTSBoYXJkZW5p -bmcsIHdoZXJlIGEgVk0ncyBtZW1vcnkgY2FuIGJlIHByb3RlY3RlZCBhDQo+ID4gbGl0dGxlIHRp -bnkgYml0IGZyb20gdGhlIG1haW4ga2VybmVsLiAgQnV0IEkgZG9uJ3Qgc2VlIHdoeSB0aGlzIGlz -IGFueQ0KPiA+IGJldHRlciB0aGFuIFhQTyAoZVhjbHVzaXZlIFBhZ2UtZnJhbWUgT3duZXJzaGlw -KSwgd2hpY2ggYnJpbmdzIHRvDQo+ID4gbWluZDoNCj4gDQo+IFdoYXQgaXMgdGhlIHRocmVhdCBt -b2RlbCBhbnl3YXkgZm9yIEFNRCBhbmQgSW50ZWwgdGVjaG5vbG9naWVzPw0KPiANCj4gRm9yIG1l -IGl0IGxvb2tzIGxpa2UgdGhhdCB5b3UgY2FuIHJlYWQsIHdyaXRlIGFuZCBldmVuIHJlcGxheSAN -Cj4gZW5jcnlwdGVkIHBhZ2VzIGJvdGggaW4gU01FIGFuZCBUTUUuIA0KDQpSaWdodC4gTmVpdGhl -ciBvZiB0aGVtIChpbmNsdWRpbmcgTUtUTUUpIHByZXZlbnRzIHJlcGxheSBhdHRhY2suIEJ1dCBp -biBteSB1bmRlcnN0YW5kaW5nIFNFViBkb2Vzbid0DQpwcmV2ZW50IHJlcGxheSBhdHRhY2sgZWl0 -aGVyIHNpbmNlIGl0IGRvZXNuJ3QgaGF2ZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4NCg0KVGhhbmtz -LA0KLUthaQ0K +On Wed, 2018-12-05 at 22:19 +0000, Sakkinen, Jarkko wrote: +> On Tue, 2018-12-04 at 11:19 -0800, Andy Lutomirski wrote: +> > I'm not Thomas, but I think it's the wrong direction. As it stands, +> > encrypt_mprotect() is an incomplete version of mprotect() (since it's +> > missing the protection key support), and it's also functionally just +> > MADV_DONTNEED. In other words, the sole user-visible effect appears +> > to be that the existing pages are blown away. The fact that it +> > changes the key in use doesn't seem terribly useful, since it's +> > anonymous memory, and the most secure choice is to use CPU-managed +> > keying, which appears to be the default anyway on TME systems. It +> > also has totally unclear semantics WRT swap, and, off the top of my +> > head, it looks like it may have serious cache-coherency issues and +> > like swapping the pages might corrupt them, both because there are no +> > flushes and because the direct-map alias looks like it will use the +> > default key and therefore appear to contain the wrong data. +> > +> > I would propose a very different direction: don't try to support MKTME +> > at all for anonymous memory, and instead figure out the important use +> > cases and support them directly. The use cases that I can think of +> > off the top of my head are: +> > +> > 1. pmem. This should probably use a very different API. +> > +> > 2. Some kind of VM hardening, where a VM's memory can be protected a +> > little tiny bit from the main kernel. But I don't see why this is any +> > better than XPO (eXclusive Page-frame Ownership), which brings to +> > mind: +> +> What is the threat model anyway for AMD and Intel technologies? +> +> For me it looks like that you can read, write and even replay +> encrypted pages both in SME and TME. + +Right. Neither of them (including MKTME) prevents replay attack. But in my understanding SEV doesn't +prevent replay attack either since it doesn't have integrity protection. + +Thanks, +-Kai diff --git a/a/content_digest b/N1/content_digest index dd9f0ae..9ab0695 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,7 +3,7 @@ "ref\00a21eadd05b245f762f7d536d8fdf579c113a9bc.camel@intel.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 02:05:50 +0000\0" + "Date\0Fri, 7 Dec 2018 02:05:50 +0000\0" "To\0Williams" Dan J <dan.j.williams@intel.com> Schofield @@ -30,41 +30,43 @@ " Jun <jun.nakajima@intel.com>\0" "\00:1\0" "b\0" - "T24gV2VkLCAyMDE4LTEyLTA1IGF0IDIyOjE5ICswMDAwLCBTYWtraW5lbiwgSmFya2tvIHdyb3Rl\n" - "Og0KPiBPbiBUdWUsIDIwMTgtMTItMDQgYXQgMTE6MTkgLTA4MDAsIEFuZHkgTHV0b21pcnNraSB3\n" - "cm90ZToNCj4gPiBJJ20gbm90IFRob21hcywgYnV0IEkgdGhpbmsgaXQncyB0aGUgd3JvbmcgZGly\n" - "ZWN0aW9uLiAgQXMgaXQgc3RhbmRzLA0KPiA+IGVuY3J5cHRfbXByb3RlY3QoKSBpcyBhbiBpbmNv\n" - "bXBsZXRlIHZlcnNpb24gb2YgbXByb3RlY3QoKSAoc2luY2UgaXQncw0KPiA+IG1pc3NpbmcgdGhl\n" - "IHByb3RlY3Rpb24ga2V5IHN1cHBvcnQpLCBhbmQgaXQncyBhbHNvIGZ1bmN0aW9uYWxseSBqdXN0\n" - "DQo+ID4gTUFEVl9ET05UTkVFRC4gIEluIG90aGVyIHdvcmRzLCB0aGUgc29sZSB1c2VyLXZpc2li\n" - "bGUgZWZmZWN0IGFwcGVhcnMNCj4gPiB0byBiZSB0aGF0IHRoZSBleGlzdGluZyBwYWdlcyBhcmUg\n" - "Ymxvd24gYXdheS4gIFRoZSBmYWN0IHRoYXQgaXQNCj4gPiBjaGFuZ2VzIHRoZSBrZXkgaW4gdXNl\n" - "IGRvZXNuJ3Qgc2VlbSB0ZXJyaWJseSB1c2VmdWwsIHNpbmNlIGl0J3MNCj4gPiBhbm9ueW1vdXMg\n" - "bWVtb3J5LCBhbmQgdGhlIG1vc3Qgc2VjdXJlIGNob2ljZSBpcyB0byB1c2UgQ1BVLW1hbmFnZWQN\n" - "Cj4gPiBrZXlpbmcsIHdoaWNoIGFwcGVhcnMgdG8gYmUgdGhlIGRlZmF1bHQgYW55d2F5IG9uIFRN\n" - "RSBzeXN0ZW1zLiAgSXQNCj4gPiBhbHNvIGhhcyB0b3RhbGx5IHVuY2xlYXIgc2VtYW50aWNzIFdS\n" - "VCBzd2FwLCBhbmQsIG9mZiB0aGUgdG9wIG9mIG15DQo+ID4gaGVhZCwgaXQgbG9va3MgbGlrZSBp\n" - "dCBtYXkgaGF2ZSBzZXJpb3VzIGNhY2hlLWNvaGVyZW5jeSBpc3N1ZXMgYW5kDQo+ID4gbGlrZSBz\n" - "d2FwcGluZyB0aGUgcGFnZXMgbWlnaHQgY29ycnVwdCB0aGVtLCBib3RoIGJlY2F1c2UgdGhlcmUg\n" - "YXJlIG5vDQo+ID4gZmx1c2hlcyBhbmQgYmVjYXVzZSB0aGUgZGlyZWN0LW1hcCBhbGlhcyBsb29r\n" - "cyBsaWtlIGl0IHdpbGwgdXNlIHRoZQ0KPiA+IGRlZmF1bHQga2V5IGFuZCB0aGVyZWZvcmUgYXBw\n" - "ZWFyIHRvIGNvbnRhaW4gdGhlIHdyb25nIGRhdGEuDQo+ID4gDQo+ID4gSSB3b3VsZCBwcm9wb3Nl\n" - "IGEgdmVyeSBkaWZmZXJlbnQgZGlyZWN0aW9uOiBkb24ndCB0cnkgdG8gc3VwcG9ydCBNS1RNRQ0K\n" - "PiA+IGF0IGFsbCBmb3IgYW5vbnltb3VzIG1lbW9yeSwgYW5kIGluc3RlYWQgZmlndXJlIG91dCB0\n" - "aGUgaW1wb3J0YW50IHVzZQ0KPiA+IGNhc2VzIGFuZCBzdXBwb3J0IHRoZW0gZGlyZWN0bHkuICBU\n" - "aGUgdXNlIGNhc2VzIHRoYXQgSSBjYW4gdGhpbmsgb2YNCj4gPiBvZmYgdGhlIHRvcCBvZiBteSBo\n" - "ZWFkIGFyZToNCj4gPiANCj4gPiAxLiBwbWVtLiAgVGhpcyBzaG91bGQgcHJvYmFibHkgdXNlIGEg\n" - "dmVyeSBkaWZmZXJlbnQgQVBJLg0KPiA+IA0KPiA+IDIuIFNvbWUga2luZCBvZiBWTSBoYXJkZW5p\n" - "bmcsIHdoZXJlIGEgVk0ncyBtZW1vcnkgY2FuIGJlIHByb3RlY3RlZCBhDQo+ID4gbGl0dGxlIHRp\n" - "bnkgYml0IGZyb20gdGhlIG1haW4ga2VybmVsLiAgQnV0IEkgZG9uJ3Qgc2VlIHdoeSB0aGlzIGlz\n" - "IGFueQ0KPiA+IGJldHRlciB0aGFuIFhQTyAoZVhjbHVzaXZlIFBhZ2UtZnJhbWUgT3duZXJzaGlw\n" - "KSwgd2hpY2ggYnJpbmdzIHRvDQo+ID4gbWluZDoNCj4gDQo+IFdoYXQgaXMgdGhlIHRocmVhdCBt\n" - "b2RlbCBhbnl3YXkgZm9yIEFNRCBhbmQgSW50ZWwgdGVjaG5vbG9naWVzPw0KPiANCj4gRm9yIG1l\n" - "IGl0IGxvb2tzIGxpa2UgdGhhdCB5b3UgY2FuIHJlYWQsIHdyaXRlIGFuZCBldmVuIHJlcGxheSAN\n" - "Cj4gZW5jcnlwdGVkIHBhZ2VzIGJvdGggaW4gU01FIGFuZCBUTUUuIA0KDQpSaWdodC4gTmVpdGhl\n" - "ciBvZiB0aGVtIChpbmNsdWRpbmcgTUtUTUUpIHByZXZlbnRzIHJlcGxheSBhdHRhY2suIEJ1dCBp\n" - "biBteSB1bmRlcnN0YW5kaW5nIFNFViBkb2Vzbid0DQpwcmV2ZW50IHJlcGxheSBhdHRhY2sgZWl0\n" - "aGVyIHNpbmNlIGl0IGRvZXNuJ3QgaGF2ZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4NCg0KVGhhbmtz\n" - LA0KLUthaQ0K + "On Wed, 2018-12-05 at 22:19 +0000, Sakkinen, Jarkko wrote:\n" + "> On Tue, 2018-12-04 at 11:19 -0800, Andy Lutomirski wrote:\n" + "> > I'm not Thomas, but I think it's the wrong direction. As it stands,\n" + "> > encrypt_mprotect() is an incomplete version of mprotect() (since it's\n" + "> > missing the protection key support), and it's also functionally just\n" + "> > MADV_DONTNEED. In other words, the sole user-visible effect appears\n" + "> > to be that the existing pages are blown away. The fact that it\n" + "> > changes the key in use doesn't seem terribly useful, since it's\n" + "> > anonymous memory, and the most secure choice is to use CPU-managed\n" + "> > keying, which appears to be the default anyway on TME systems. It\n" + "> > also has totally unclear semantics WRT swap, and, off the top of my\n" + "> > head, it looks like it may have serious cache-coherency issues and\n" + "> > like swapping the pages might corrupt them, both because there are no\n" + "> > flushes and because the direct-map alias looks like it will use the\n" + "> > default key and therefore appear to contain the wrong data.\n" + "> > \n" + "> > I would propose a very different direction: don't try to support MKTME\n" + "> > at all for anonymous memory, and instead figure out the important use\n" + "> > cases and support them directly. The use cases that I can think of\n" + "> > off the top of my head are:\n" + "> > \n" + "> > 1. pmem. This should probably use a very different API.\n" + "> > \n" + "> > 2. Some kind of VM hardening, where a VM's memory can be protected a\n" + "> > little tiny bit from the main kernel. But I don't see why this is any\n" + "> > better than XPO (eXclusive Page-frame Ownership), which brings to\n" + "> > mind:\n" + "> \n" + "> What is the threat model anyway for AMD and Intel technologies?\n" + "> \n" + "> For me it looks like that you can read, write and even replay \n" + "> encrypted pages both in SME and TME. \n" + "\n" + "Right. Neither of them (including MKTME) prevents replay attack. But in my understanding SEV doesn't\n" + "prevent replay attack either since it doesn't have integrity protection.\n" + "\n" + "Thanks,\n" + -Kai -37357710cf059ec92da150f6bcaeb359a48a206d35e4ec7daf4d9f35f134db13 +aa15c54a54819200fd14a8c202bbe3e7816d5f1064bb4fe82fb1620ff74b3ba7
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.