diff for duplicates of <1544148839.28511.28.camel@intel.com> diff --git a/a/1.txt b/N1/1.txt index 7737571..4eba677 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,37 +1,42 @@ -T24gTW9uLCAyMDE4LTEyLTAzIGF0IDIzOjM5IC0wODAwLCBBbGlzb24gU2Nob2ZpZWxkIHdyb3Rl -Og0KPiBNS1RNRSAoTXVsdGktS2V5IFRvdGFsIE1lbW9yeSBFbmNyeXB0aW9uKSBrZXkgcGF5bG9h -ZHMgbWF5IGluY2x1ZGUNCj4gZGF0YSBlbmNyeXB0aW9uIGtleXMsIHR3ZWFrIGtleXMsIGFuZCBh -ZGRpdGlvbmFsIGVudHJvcHkgYml0cy4gVGhlc2UNCj4gYXJlIHVzZWQgdG8gcHJvZ3JhbSB0aGUg -TUtUTUUgZW5jcnlwdGlvbiBoYXJkd2FyZS4gQnkgZGVmYXVsdCwgdGhlDQo+IGtlcm5lbCBkZXN0 -cm95cyB0aGlzIHBheWxvYWQgZGF0YSBvbmNlIHRoZSBoYXJkd2FyZSBpcyBwcm9ncmFtbWVkLg0K -PiANCj4gSG93ZXZlciwgaW4gb3JkZXIgdG8gZnVsbHkgc3VwcG9ydCBDUFUgSG90cGx1Zywgc2F2 -aW5nIHRoZSBrZXkgZGF0YQ0KPiBiZWNvbWVzIGltcG9ydGFudC4gVGhlIE1LVE1FIEtleSBTZXJ2 -aWNlIGNhbm5vdCBhbGxvdyBhIG5ldyBwaHlzaWNhbA0KPiBwYWNrYWdlIHRvIGNvbWUgb25saW5l -IHVubGVzcyBpdCBjYW4gcHJvZ3JhbSB0aGUgbmV3IHBhY2thZ2VzIEtleSBUYWJsZQ0KPiB0byBt -YXRjaCB0aGUgS2V5IFRhYmxlcyBvZiBhbGwgZXhpc3RpbmcgcGh5c2ljYWwgcGFja2FnZXMuDQo+ -IA0KPiBXaXRoIENQVSBnZW5lcmF0ZWQga2V5cyAoYS5rLmEuIHJhbmRvbSBrZXlzIG9yIGVwaGVt -ZXJhbCBrZXlzKSB0aGUNCj4gc2F2aW5nIG9mIHVzZXIga2V5IGRhdGEgaXMgbm90IGFuIGlzc3Vl -LiBUaGUga2VybmVsIGFuZCBNS1RNRSBoYXJkd2FyZQ0KPiBjYW4gZ2VuZXJhdGUgc3Ryb25nIGVu -Y3J5cHRpb24ga2V5cyB3aXRob3V0IHJlY2FsbGluZyBhbnkgdXNlciBzdXBwbGllZA0KPiBkYXRh -Lg0KPiANCj4gV2l0aCBVU0VSIGRpcmVjdGVkIGtleXMgKGEuay5hLiB1c2VyIHR5cGUpIHNhdmlu -ZyB0aGUga2V5IHByb2dyYW1taW5nDQo+IGRhdGEgKGRhdGEgYW5kIHR3ZWFrIGtleSkgYmVjb21l -cyBhbiBpc3N1ZS4gVGhlIGRhdGEgYW5kIHR3ZWFrIGtleXMNCj4gYXJlIHJlcXVpcmVkIHRvIHBy -b2dyYW0gdGhvc2Uga2V5cyBvbiBhIG5ldyBwaHlzaWNhbCBwYWNrYWdlLg0KPiANCj4gSW4gcHJl -cGFyYXRpb24gZm9yIGFkZGluZyBDUFUgaG90cGx1ZyBzdXBwb3J0Og0KPiANCj4gICAgQWRkIGFu -ICdta3RtZV92YXVsdCcgd2hlcmUga2V5IGRhdGEgaXMgc3RvcmVkLg0KPiANCj4gICAgQWRkICdt -a3RtZV9zYXZla2V5cycga2VybmVsIGNvbW1hbmQgbGluZSBwYXJhbWV0ZXIgdGhhdCBkaXJlY3Rz -DQo+ICAgIHdoYXQga2V5IGRhdGEgY2FuIGJlIHN0b3JlZC4gSWYgaXQgaXMgbm90IHNldCwga2Vy -bmVsIGRvZXMgbm90DQo+ICAgIHN0b3JlIHVzZXJzIGRhdGEga2V5IG9yIHR3ZWFrIGtleS4NCj4g -DQo+ICAgIEFkZCAnbWt0bWVfYml0bWFwX3VzZXJfdHlwZScgdG8gdHJhY2sgd2hlbiBVU0VSIHR5 -cGUga2V5cyBhcmUgaW4NCj4gICAgdXNlLiBJZiBubyBVU0VSIHR5cGUga2V5cyBhcmUgY3VycmVu -dGx5IGluIHVzZSwgYSBwaHlzaWNhbCBwYWNrYWdlDQo+ICAgIG1heSBiZSBicm91Z2h0IG9ubGlu -ZSwgZGVzcGl0ZSB0aGUgYWJzZW5jZSBvZiAnbWt0bWVfc2F2ZWtleXMnLg0KDQpPdmVyYWxsLCBJ -IGFtIG5vdCBzdXJlIHdoZXRoZXIgc2F2aW5nIGtleSBpcyBnb29kIGlkZWEsIHNpbmNlIGl0IGJy -ZWFrcyBjb2xkYm9vdCBhdHRhY2sgSU1ITy4gV2UNCm5lZWQgdG8gdHJhZGVvZmYgYmV0d2VlbiBz -dXBwb3J0aW5nIENQVSBob3RwbHVnIGFuZCBzZWN1cml0eS4gSSBhbSBub3Qgc3VyZSB3aGV0aGVy -IHN1cHBvcnRpbmcgQ1BVDQpob3RwbHVnIGlzIHRoYXQgaW1wb3J0YW50LCBzaW5jZSBmb3Igc29t -ZSBvdGhlciBmZWF0dXJlcyBzdWNoIGFzIFNHWCwgd2UgZG9uJ3Qgc3VwcG9ydCBDUFUgaG90cGx1 -Zw0KYW55d2F5Lg0KDQpBbHRlcm5hdGl2ZWx5LCB3ZSBjYW4gY2hvb3NlIHRvIHVzZSBwZXItc29j -a2V0IGtleUlELCBidXQgbm90IHRvIHByb2dyYW0ga2V5SUQgZ2xvYmFsbHkgYWNyb3NzIGFsbA0K -c29ja2V0cywgc28geW91IGRvbid0IGhhdmUgdG8gc2F2ZSBrZXkgd2hpbGUgc3RpbGwgc3VwcG9y -dGluZyBDUFUgaG90cGx1Zy4NCg0KVGhhbmtzLA0KLUthaQ= +On Mon, 2018-12-03 at 23:39 -0800, Alison Schofield wrote: +> MKTME (Multi-Key Total Memory Encryption) key payloads may include +> data encryption keys, tweak keys, and additional entropy bits. These +> are used to program the MKTME encryption hardware. By default, the +> kernel destroys this payload data once the hardware is programmed. +> +> However, in order to fully support CPU Hotplug, saving the key data +> becomes important. The MKTME Key Service cannot allow a new physical +> package to come online unless it can program the new packages Key Table +> to match the Key Tables of all existing physical packages. +> +> With CPU generated keys (a.k.a. random keys or ephemeral keys) the +> saving of user key data is not an issue. The kernel and MKTME hardware +> can generate strong encryption keys without recalling any user supplied +> data. +> +> With USER directed keys (a.k.a. user type) saving the key programming +> data (data and tweak key) becomes an issue. The data and tweak keys +> are required to program those keys on a new physical package. +> +> In preparation for adding CPU hotplug support: +> +> Add an 'mktme_vault' where key data is stored. +> +> Add 'mktme_savekeys' kernel command line parameter that directs +> what key data can be stored. If it is not set, kernel does not +> store users data key or tweak key. +> +> Add 'mktme_bitmap_user_type' to track when USER type keys are in +> use. If no USER type keys are currently in use, a physical package +> may be brought online, despite the absence of 'mktme_savekeys'. + +Overall, I am not sure whether saving key is good idea, since it breaks coldboot attack IMHO. We +need to tradeoff between supporting CPU hotplug and security. I am not sure whether supporting CPU +hotplug is that important, since for some other features such as SGX, we don't support CPU hotplug +anyway. + +Alternatively, we can choose to use per-socket keyID, but not to program keyID globally across all +sockets, so you don't have to save key while still supporting CPU hotplug. + +Thanks, +-Kai diff --git a/a/content_digest b/N1/content_digest index 6b9e7d9..958e39c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,7 +2,7 @@ "ref\0c2668d6d260bff3c88440ad097eb1445ea005860.1543903910.git.alison.schofield@intel.com\0" "From\0Huang, Kai <kai.huang@intel.com>\0" "Subject\0Re: [RFC v2 12/13] keys/mktme: Save MKTME data if kernel cmdline parameter allows\0" - "Date\0Fri, 07 Dec 2018 02:14:03 +0000\0" + "Date\0Fri, 7 Dec 2018 02:14:03 +0000\0" "To\0tglx@linutronix.de <tglx@linutronix.de>" Schofield Alison <alison.schofield@intel.com> @@ -28,42 +28,47 @@ " Jun <jun.nakajima@intel.com>\0" "\00:1\0" "b\0" - "T24gTW9uLCAyMDE4LTEyLTAzIGF0IDIzOjM5IC0wODAwLCBBbGlzb24gU2Nob2ZpZWxkIHdyb3Rl\n" - "Og0KPiBNS1RNRSAoTXVsdGktS2V5IFRvdGFsIE1lbW9yeSBFbmNyeXB0aW9uKSBrZXkgcGF5bG9h\n" - "ZHMgbWF5IGluY2x1ZGUNCj4gZGF0YSBlbmNyeXB0aW9uIGtleXMsIHR3ZWFrIGtleXMsIGFuZCBh\n" - "ZGRpdGlvbmFsIGVudHJvcHkgYml0cy4gVGhlc2UNCj4gYXJlIHVzZWQgdG8gcHJvZ3JhbSB0aGUg\n" - "TUtUTUUgZW5jcnlwdGlvbiBoYXJkd2FyZS4gQnkgZGVmYXVsdCwgdGhlDQo+IGtlcm5lbCBkZXN0\n" - "cm95cyB0aGlzIHBheWxvYWQgZGF0YSBvbmNlIHRoZSBoYXJkd2FyZSBpcyBwcm9ncmFtbWVkLg0K\n" - "PiANCj4gSG93ZXZlciwgaW4gb3JkZXIgdG8gZnVsbHkgc3VwcG9ydCBDUFUgSG90cGx1Zywgc2F2\n" - "aW5nIHRoZSBrZXkgZGF0YQ0KPiBiZWNvbWVzIGltcG9ydGFudC4gVGhlIE1LVE1FIEtleSBTZXJ2\n" - "aWNlIGNhbm5vdCBhbGxvdyBhIG5ldyBwaHlzaWNhbA0KPiBwYWNrYWdlIHRvIGNvbWUgb25saW5l\n" - "IHVubGVzcyBpdCBjYW4gcHJvZ3JhbSB0aGUgbmV3IHBhY2thZ2VzIEtleSBUYWJsZQ0KPiB0byBt\n" - "YXRjaCB0aGUgS2V5IFRhYmxlcyBvZiBhbGwgZXhpc3RpbmcgcGh5c2ljYWwgcGFja2FnZXMuDQo+\n" - "IA0KPiBXaXRoIENQVSBnZW5lcmF0ZWQga2V5cyAoYS5rLmEuIHJhbmRvbSBrZXlzIG9yIGVwaGVt\n" - "ZXJhbCBrZXlzKSB0aGUNCj4gc2F2aW5nIG9mIHVzZXIga2V5IGRhdGEgaXMgbm90IGFuIGlzc3Vl\n" - "LiBUaGUga2VybmVsIGFuZCBNS1RNRSBoYXJkd2FyZQ0KPiBjYW4gZ2VuZXJhdGUgc3Ryb25nIGVu\n" - "Y3J5cHRpb24ga2V5cyB3aXRob3V0IHJlY2FsbGluZyBhbnkgdXNlciBzdXBwbGllZA0KPiBkYXRh\n" - "Lg0KPiANCj4gV2l0aCBVU0VSIGRpcmVjdGVkIGtleXMgKGEuay5hLiB1c2VyIHR5cGUpIHNhdmlu\n" - "ZyB0aGUga2V5IHByb2dyYW1taW5nDQo+IGRhdGEgKGRhdGEgYW5kIHR3ZWFrIGtleSkgYmVjb21l\n" - "cyBhbiBpc3N1ZS4gVGhlIGRhdGEgYW5kIHR3ZWFrIGtleXMNCj4gYXJlIHJlcXVpcmVkIHRvIHBy\n" - "b2dyYW0gdGhvc2Uga2V5cyBvbiBhIG5ldyBwaHlzaWNhbCBwYWNrYWdlLg0KPiANCj4gSW4gcHJl\n" - "cGFyYXRpb24gZm9yIGFkZGluZyBDUFUgaG90cGx1ZyBzdXBwb3J0Og0KPiANCj4gICAgQWRkIGFu\n" - "ICdta3RtZV92YXVsdCcgd2hlcmUga2V5IGRhdGEgaXMgc3RvcmVkLg0KPiANCj4gICAgQWRkICdt\n" - "a3RtZV9zYXZla2V5cycga2VybmVsIGNvbW1hbmQgbGluZSBwYXJhbWV0ZXIgdGhhdCBkaXJlY3Rz\n" - "DQo+ICAgIHdoYXQga2V5IGRhdGEgY2FuIGJlIHN0b3JlZC4gSWYgaXQgaXMgbm90IHNldCwga2Vy\n" - "bmVsIGRvZXMgbm90DQo+ICAgIHN0b3JlIHVzZXJzIGRhdGEga2V5IG9yIHR3ZWFrIGtleS4NCj4g\n" - "DQo+ICAgIEFkZCAnbWt0bWVfYml0bWFwX3VzZXJfdHlwZScgdG8gdHJhY2sgd2hlbiBVU0VSIHR5\n" - "cGUga2V5cyBhcmUgaW4NCj4gICAgdXNlLiBJZiBubyBVU0VSIHR5cGUga2V5cyBhcmUgY3VycmVu\n" - "dGx5IGluIHVzZSwgYSBwaHlzaWNhbCBwYWNrYWdlDQo+ICAgIG1heSBiZSBicm91Z2h0IG9ubGlu\n" - "ZSwgZGVzcGl0ZSB0aGUgYWJzZW5jZSBvZiAnbWt0bWVfc2F2ZWtleXMnLg0KDQpPdmVyYWxsLCBJ\n" - "IGFtIG5vdCBzdXJlIHdoZXRoZXIgc2F2aW5nIGtleSBpcyBnb29kIGlkZWEsIHNpbmNlIGl0IGJy\n" - "ZWFrcyBjb2xkYm9vdCBhdHRhY2sgSU1ITy4gV2UNCm5lZWQgdG8gdHJhZGVvZmYgYmV0d2VlbiBz\n" - "dXBwb3J0aW5nIENQVSBob3RwbHVnIGFuZCBzZWN1cml0eS4gSSBhbSBub3Qgc3VyZSB3aGV0aGVy\n" - "IHN1cHBvcnRpbmcgQ1BVDQpob3RwbHVnIGlzIHRoYXQgaW1wb3J0YW50LCBzaW5jZSBmb3Igc29t\n" - "ZSBvdGhlciBmZWF0dXJlcyBzdWNoIGFzIFNHWCwgd2UgZG9uJ3Qgc3VwcG9ydCBDUFUgaG90cGx1\n" - "Zw0KYW55d2F5Lg0KDQpBbHRlcm5hdGl2ZWx5LCB3ZSBjYW4gY2hvb3NlIHRvIHVzZSBwZXItc29j\n" - "a2V0IGtleUlELCBidXQgbm90IHRvIHByb2dyYW0ga2V5SUQgZ2xvYmFsbHkgYWNyb3NzIGFsbA0K\n" - "c29ja2V0cywgc28geW91IGRvbid0IGhhdmUgdG8gc2F2ZSBrZXkgd2hpbGUgc3RpbGwgc3VwcG9y\n" - dGluZyBDUFUgaG90cGx1Zy4NCg0KVGhhbmtzLA0KLUthaQ= + "On Mon, 2018-12-03 at 23:39 -0800, Alison Schofield wrote:\n" + "> MKTME (Multi-Key Total Memory Encryption) key payloads may include\n" + "> data encryption keys, tweak keys, and additional entropy bits. These\n" + "> are used to program the MKTME encryption hardware. By default, the\n" + "> kernel destroys this payload data once the hardware is programmed.\n" + "> \n" + "> However, in order to fully support CPU Hotplug, saving the key data\n" + "> becomes important. The MKTME Key Service cannot allow a new physical\n" + "> package to come online unless it can program the new packages Key Table\n" + "> to match the Key Tables of all existing physical packages.\n" + "> \n" + "> With CPU generated keys (a.k.a. random keys or ephemeral keys) the\n" + "> saving of user key data is not an issue. The kernel and MKTME hardware\n" + "> can generate strong encryption keys without recalling any user supplied\n" + "> data.\n" + "> \n" + "> With USER directed keys (a.k.a. user type) saving the key programming\n" + "> data (data and tweak key) becomes an issue. The data and tweak keys\n" + "> are required to program those keys on a new physical package.\n" + "> \n" + "> In preparation for adding CPU hotplug support:\n" + "> \n" + "> Add an 'mktme_vault' where key data is stored.\n" + "> \n" + "> Add 'mktme_savekeys' kernel command line parameter that directs\n" + "> what key data can be stored. If it is not set, kernel does not\n" + "> store users data key or tweak key.\n" + "> \n" + "> Add 'mktme_bitmap_user_type' to track when USER type keys are in\n" + "> use. If no USER type keys are currently in use, a physical package\n" + "> may be brought online, despite the absence of 'mktme_savekeys'.\n" + "\n" + "Overall, I am not sure whether saving key is good idea, since it breaks coldboot attack IMHO. We\n" + "need to tradeoff between supporting CPU hotplug and security. I am not sure whether supporting CPU\n" + "hotplug is that important, since for some other features such as SGX, we don't support CPU hotplug\n" + "anyway.\n" + "\n" + "Alternatively, we can choose to use per-socket keyID, but not to program keyID globally across all\n" + "sockets, so you don't have to save key while still supporting CPU hotplug.\n" + "\n" + "Thanks,\n" + -Kai -edd03080b96c8181b064b1d820b068b4943f2b1072c7f39dcc43f13ac890fb57 +3d212e01739d83c3bdbd52b515592aab621d8b8ef552d710d41a08eb85912e93
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.