All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1536635716.5860.17.camel@intel.com>

diff --git a/a/1.txt b/N1/1.txt
index 49f4eac..22f7408 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,156 +1,223 @@
-T24gTW9uLCAyMDE4LTA5LTEwIGF0IDEyOjEwIC0wNzAwLCBBbGlzb24gU2Nob2ZpZWxkIHdyb3Rl
-Og0KPiBPbiBTdW4sIFNlcCAwOSwgMjAxOCBhdCAwNjoxMDoxOVBNIC0wNzAwLCBIdWFuZywgS2Fp
-IHdyb3RlOg0KPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZy
-b206IGtleXJpbmdzLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmtleXJpbmdzLQ0KPiA+
-ID4gb3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgQWxpc29uIFNjaG9maWVsZA0K
-PiA+ID4gU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciA4LCAyMDE4IDEwOjIzIEFNDQo+ID4gPiBU
-bzogZGhvd2VsbHNAcmVkaGF0LmNvbTsgdGdseEBsaW51dHJvbml4LmRlDQo+ID4gPiBDYzogSHVh
-bmcsIEthaSA8a2FpLmh1YW5nQGludGVsLmNvbT47IE5ha2FqaW1hLCBKdW4NCj4gPiA+IDxqdW4u
-bmFrYWppbWFAaW50ZWwuY29tPjsgU2h1dGVtb3YsIEtpcmlsbCA8a2lyaWxsLnNodXRlbW92QGlu
-dGVsDQo+ID4gPiAuY29tPjsNCj4gPiA+IEhhbnNlbiwgRGF2ZSA8ZGF2ZS5oYW5zZW5AaW50ZWwu
-Y29tPjsgU2Fra2luZW4sIEphcmtrbw0KPiA+ID4gPGphcmtrby5zYWtraW5lbkBpbnRlbC5jb20+
-OyBqbW9ycmlzQG5hbWVpLm9yZzsga2V5cmluZ3NAdmdlci5rZXINCj4gPiA+IG5lbC5vcmc7DQo+
-ID4gPiBsaW51eC1zZWN1cml0eS1tb2R1bGVAdmdlci5rZXJuZWwub3JnOyBtaW5nb0ByZWRoYXQu
-Y29tOyBocGFAenl0bw0KPiA+ID4gci5jb207DQo+ID4gPiB4ODZAa2VybmVsLm9yZzsgbGludXgt
-bW1Aa3ZhY2sub3JnDQo+ID4gPiBTdWJqZWN0OiBbUkZDIDAwLzEyXSBNdWx0aS1LZXkgVG90YWwg
-TWVtb3J5IEVuY3J5cHRpb24gQVBJDQo+ID4gPiAoTUtUTUUpDQo+ID4gPiANCj4gPiA+IFNlZWtp
-bmcgY29tbWVudHMgb24gdGhlIEFQSXMgc3VwcG9ydGluZyBNS1RNRSBvbiBmdXR1cmUgSW50ZWwN
-Cj4gPiA+IHBsYXRmb3Jtcy4NCj4gPiA+IA0KPiA+ID4gTUtUTUUgKE11bHRpLUtleSBUb3RhbCBN
-ZW1vcnkgRW5jcnlwdGlvbikgaXMgYSB0ZWNobm9sb2d5DQo+ID4gPiBzdXBwb3J0aW5nDQo+ID4g
-PiBtZW1vcnkgZW5jcnlwdGlvbiBvbiB1cGNvbWluZyBJbnRlbCBwbGF0Zm9ybXMuIFdoZXJlYXMg
-VE1FIGFsbG93cw0KPiA+ID4gZW5jcnlwdGlvbiBvZiB0aGUgZW50aXJlIHN5c3RlbSBtZW1vcnkg
-dXNpbmcgYSBzaW5nbGUga2V5LCBNS1RNRQ0KPiA+ID4gYWxsb3dzDQo+ID4gPiBtdWxpdHBsZSBl
-bmNyeXB0aW9uIGRvbWFpbnMsIGVhY2ggaGF2aW5nIHRoZWlyIG93biBrZXkuIFdoaWxlIHRoZQ0K
-PiA+ID4gbWFpbiB1c2UNCj4gPiA+IGNhc2UgZm9yIHRoZSBmZWF0dXJlIGlzIHZpcnR1YWwgbWFj
-aGluZSBpc29sYXRpb24sIHRoZSBBUEkgbmVlZHMNCj4gPiA+IHRoZSBmbGV4aWJpbGl0eSB0bw0K
-PiA+ID4gd29yayBmb3IgYSB3aWRlIHJhbmdlIG9mIHVzZSBjYXNlcy4NCj4gPiA+IA0KPiA+ID4g
-VGhpcyBSRkMgcHJlc2VudHMgdGhlIDIgQVBJIGFkZGl0aW9ucyB0aGF0IGVuYWJsZSB1c2Vyc3Bh
-Y2UgdG86DQo+ID4gPiAgMSkgQ3JlYXRlIEVuY3J5cHRpb24gS2V5czogS2VybmVsIEtleSBTZXJ2
-aWNlIHR5cGUgIm1rdG1lIg0KPiA+ID4gIDIpIFVzZSB0aGUgRW5jcnlwdGlvbiBLZXlzOiBzeXN0
-ZW0gY2FsbCBlbmNyeXB0X21wcm90ZWN0KCkNCj4gPiA+IA0KPiA+ID4gSW4gb3JkZXIgdG8gc2hh
-cmUgYmV0d2VlbjogdGhlIEtlcm5lbCBLZXkgU2VydmljZSwgdGhlIG5ldyBzeXN0ZW0NCj4gPiA+
-IGNhbGwsIGFuZCB0aGUNCj4gPiA+IGV4aXN0aW5nIG1tIGNvZGUsIGhlbHBlciBmdW5jdGlvbnMg
-d2VyZSBjcmVhdGVkIGluIGFyY2gveDg2L21rdG1lDQo+ID4gDQo+ID4gSU1ITywgd2UgY2FuIHNl
-cGFyYXRlIHRoaXMgc2VyaWVzIGludG8gMiBwYXJ0cywgYXMgeW91IGRpZCBhYm92ZSwNCj4gPiBh
-bmQgc2VuZCBvdXQgdGhlbSBzZXBhcmF0ZWx5LiBUaGUgcmVhc29uIGlzLCBpbiBnZW5lcmFsIEkg
-dGhpbmsNCj4gPiBhZGRpbmcgbmV3IE1LVE1FIHR5cGUgdG8ga2V5IHJldGVudGlvbiBzZXJ2aWNl
-cyBpcyBub3QgdGhhdCByZWxhdGVkDQo+ID4gdG8gbWVtb3J5IG1hbmFnZW1lbnQgY29kZSwgbmFt
-ZWx5IHRoZSBlbmNyeXB0X21wcm90ZWN0KCkgQVBJIHBhcnQuDQo+ID4gDQo+ID4gU28gaWYgd2Ug
-c3BsaXQgdGhlIHR3byBwYXJ0cyBhbmQgc2VuZCB0aGVtIG91dCBzZXBhcmF0ZWx5LCB0aGUNCj4g
-PiBmaXJzdCBwYXJ0IGNhbiBiZSByZXZpZXdlZCBieSBrZXlyaW5nIGFuZCBzZWN1cml0eSBndXlz
-LCB3aXRob3V0DQo+ID4gaW52b2x2aW5nIG1tIGd1eXMsIGFuZCB0aGUgZW5jcnlwdF9tcHJvdGVj
-dCgpIHBhcnQgY2FuIGJlIG1vcmUNCj4gPiByZXZpZXdlZCBtb3JlIGJ5IG1tIGd1eXMuIA0KPiA+
-IA0KPiANCj4gS2FpLA0KPiANCj4gVGhhdCB3YXMgdGhlIGRpcmVjdGlvbiBJIGhhZCBpbiBtaW5k
-IGF0IHRoZSBvbnNldDogdGhlIE1LVE1FIGtleQ0KPiBzZXJ2aWNlDQo+IHdvdWxkIGJlIG9uZSBw
-YXRjaChzZXQpIGFuZCB0aGUgTUtUTUUgZW5jcnlwdF9tcHJvdGVjdCgpIHN5c3RlbSBjYWxsDQo+
-IHdvdWxkDQo+IGJlIGRlbGl2ZXJlZCBpbiBhbm90aGVyIHBhdGNoKHNldCkuDQo+IA0KPiBUaGF0
-IHNlcGFyYXRpb24gZmFsbHMgYXBhcnQgd2hlbiB0aGUgc2hhcmVkIHN0cnVjdHVyZXMgYW5kIGZ1
-bmN0aW9ucw0KPiBhcmUNCj4gaW50cm9kdWNlZC4gVGhhdCAnbWt0bWVfbWFwJyAobWFwcyB1c2Vy
-c3BhY2Uga2V5cyB0byBoYXJkd2FyZSBrZXlpZA0KPiBzbG90cyksDQo+IGFuZCB0aGUgJ2VuY3J5
-cHRfY291bnQnIGFycmF5IChjb3VudHMgdm1hJ3Mgb3V0c3RhbmRpbmcgZm9yIGVhY2gga2V5KQ0K
-PiBuZWVkDQo+IHRvIGJlIHNoYXJlZCBieSBib3RoIHBpZWNlcy4gVGhlc2UgbWt0bWUgc3BlY2lh
-bCBzaGFyZWQgc3RydWN0dXJlcw0KPiBhbmQgdGhlDQo+IGZ1bmN0aW9ucyB0aGF0IG9wZXJhdGUg
-b24gdGhlbSBhcmUgYWxsIGRlZmluZWQgaW4NCj4gYXJjaC94ODYvbW0vbWt0bWUuaCwuYy4NCj4g
-RnJvbSB0aGVyZSB0aGV5IGNhbiBiZSBzaGFyZWQgd2l0aCB0aGUgc2VjdXJpdHkva2V5cy9ta3Rt
-ZV9rZXlzLmMNCj4gDQo+IE9uY2UgSSBtYWRlIHRoYXQgc2VwYXJhdGlvbiwgSSBzdHVjayB3aXRo
-IGl0LiBUaG9zZSBzdHJ1Y3R1cmVzLCBhbmQNCj4gYW55DQo+IGZ1bmN0aW9ucyB0aGF0IG1hbmlw
-dWxhdGUgdGhvc2Ugc3RydWN0dXJlcyBsaXZlIGluDQo+IGFyY2gveDg2L21tL21rdG1lLmgsYw0K
-PiANCj4gWW91IG5vdGVkIHRoYXQgc29tZSBvZiB0aGUgZnVuY3Rpb25zIHRoYXQgb3BlcmF0ZSBv
-biB0aGUNCj4gZW5jcnlwdF9jb3VudA0KPiBtaWdodCBub3QgbmVlZCB0byBiZSBvdmVyIGluIGFy
-Y2gveDg2L21tL21rdG1lLmMgYmVjYXVzZSB0aGV5IGFyZSBub3QNCj4gdXNlZA0KPiBpbiB0aGUg
-bW0gY29kZS4gVGhhdCBpcyB0cnVlLiAgDQoNClllcyBJTU8gdGhpcyBpcyBiZXR0ZXIuDQoNCj4g
-QnV0LCB0aGVuIEknZCBiZSBzcGxpdHRpbmcgdXAgdGhlIGRlZmluaXRpb24NCj4gb2YgdGhlIHN0
-cnVjdCBhbmQgdGhlIGZ1bmNzIHRoYXQgb3BlcmF0ZSBvbiBpdC4gU28sIEkgc3R1Y2sgd2l0aA0K
-PiBrZWVwaW5nIGl0DQo+IGFsbCB0b2dldGhlciBpbiB0aGUgYXJjaCBzcGVjaWZpYyBta3RtZSBm
-aWxlcy4NCg0KRGVmaW5pdGlvbiBjYW4gYWxzbyBiZSBpbiBpbmNsdWRlL2tleXMvbWt0bWUtdHlw
-ZS5oLCByaWdodD8NCg0KPiANCj4gSGF2aW5nIHNhaWQgYWxsIHRoZSBhYm92ZSwgSSBkbyB3ZWxj
-b21lIG90aGVyIGlkZWFzIG9uIGhvdyB0byBiZXR0ZXINCj4gb3JnYW5pemUNCj4gdGhlIGNvZGUu
-IA0KPiANCj4gQmFjayB0byB5b3VyIHJlcXVlc3QtIHRvIHNwbGl0IGl0IGludG8gc21hbGxlciBw
-YXRjaHNldHMgbWlnaHQgbG9vaw0KPiBzb21ldGhpbmcNCj4gbGlrZToNCj4gMSkgdGhlIE1LVE1F
-IEFQSSBoZWxwZXJzDQoNCkV4YWN0bHkgd2hhdCBoZWxwZXJzPw0KDQo+IDIpIHRoZSBNS1RNRSBL
-ZXkgU2VydmljZQ0KPiAzKSB0aGUgTUtUTUUgc3lzY2FsbCBlbmNyeXB0X21wcm90ZWN0KCkNCj4g
-DQo+IEknbSBub3QgY2xlYXIgdGhhdCB3b3VsZCBtYWtlIGFueW9uZXMgcmV2aWV3IGxpZmUgZWFz
-aWVyLCB0aGFuDQo+IHBpY2tpbmcNCj4gdGhlIHNhbWUgcGllY2VzIG91dCBvZiB0aGUgZ3JlYXRl
-ciBwYXRjaHNldC4NCg0KV2VsbCwgdGhlIHJlYXNvbiBJIHN1Z2dlc3RlZCB3ZSBzaG91bGQgc3Bs
-aXQga2V5IHJldGVudGlvbiBzZXJ2aWNlcw0KZnJvbSBvdGhlciBzdGFmZiBhbmQgZ2V0IGl0IHJl
-dmlld2VkIGZpcnN0IGlzIEkgdGhpbmsgdGhlDQpmdW5jdGlvbmFsaXRpZXMgb2YgTUtUTUUga2V5
-IHR5cGUgaGFzIG5vdGhpbmcgdG8gZG8gdy8gTU0gY29kZS4gSU1ITw0Kd2hhdCBNS1RNRSBrZXkg
-dHlwZSBzaG91bGQgcHJvdmlkZSBpbmNsdWRlczoNCg0KMSkgU3VwcG9ydCBhZGRfa2V5LCBrZXlj
-dGwgKHJldm9rZSwgZXRjKSBvYnZpb3VzbHkuIFRIaXMgYWxzbyBpbXBsaWVzDQprZXlJRCBhbGxv
-Y2F0aW9uLCBzbyB5b3Ugd2lsbCBuZWVkIHNvbWUgaW5mbyBmcm9tIE1NIG9yIHg4NiBjb2RlIHRv
-IGdldA0KIGluZm8gc3VjaCBhcyBudW1iZXIgb2Yga2V5SURzLCBldGMuIEluIGZhY3QgSSB0aGlu
-ayBudW1iZXIgb2Yga2V5SURzDQppcyAgdGhlIG9ubHkgaW5mbyB5b3UgbmVlZCAoMCBrZXlJRHMg
-bWVhbnMgTUtUTUUgaXMgZGlzYWJsZWQpLg0KDQoyKSBZb3UgbmVlZCB0byBwcm92aWRlIHNvbWUg
-QVBJcyB0byBtdW5pcHVsYXRlIGtleSByZWZlcmVuY2UgY291bnQuDQpUaG9zZSBmdW5jdGlvbnMg
-Y2FuIGJlIGRlY2xhcmVkIGluIG1rdG1lLXR5cGUuaCwgYW5kIGltcGxlbWVudGVkIGluDQpta3Rt
-ZV9rZXlzLmMuIEkgdGhpbmsgdGhpcyBpcyBtb3JlIHJlYXNvbmFibGUsIGFzIGxvZ2ljYWxseSBy
-ZWZlcmVuY2UNCmNvdW50IGlzIHBhcnQgb2YgTUtUTUUga2V5IHNlcnZpY2UuDQoNCkkgZG9uJ3Qg
-dGhpbmsgeW91IG5lZWQgdG8gZG8gYW55dGhpbmcgZWxzZSBpbiBNS1RNRSBrZXkgdHlwZT8NCg0K
-SSB0aGluayB5b3UgY2FuIGV2ZW4gc3RhcnQgdXBzdHJlYW1pbmcgTUtUTUUga2V5IHR5cGUgbm93
-IHcvbyBLaXJpbGwncw0KY29yZS1NS1RNRSBzdXBwb3J0LCBzaW5jZSAxKSBhZGRpbmcgTUtUTUUg
-a2V5IHR5cGUgZG9lc24ndCBkbyBhbnkgaGFybQ0Kdy9vIGtpcmlsbCdzIGNvcmUtTUtUTUUgY29k
-ZTsgMikgbG9naWNhbGx5IE1LVE1FIGtleSB0eXBlIGhhcyBubyB0cnVlDQpkZXBlbmRlbmN5IG9u
-IGNvcmUtTUtUTUUgY29kZS4NCg0KU28gSU1ITywgYSBiZXR0ZXIgc3RydWN0dXJlIHNob3VsZCBi
-ZToNCg0KMSkgQ3VycmVudCB1cHN0cmVhbSBjb2RlIChtYXliZSB3aXRoIHNvbWUgZWFybHkgZGV0
-Y3Rpb24gY29kZSBjaGFuZ2UsDQppZSwgdG8gZGlzYWJsZSBNS1RNRSBmb3Igc29tZSBTVyByZWFz
-b24sIGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcw0KaXMgdHJ1ZWx5IG5lZWRlZCwgc2lu
-Y2Ugd2hlbiBNS1RNRSBrZXkgdHlwZSBnZXRzIGluaXRpYWxpemVkLCB0aGF0IHBhcnQNCnNob3Vs
-ZCBiZWVuIGRvbmUgYWxyZWFkeSkuDQoyKSBNS1RNRSBrZXkgdHlwZQ0KMykgS2lyaWxsJ3MgY29y
-ZS1NS1RNRQ0KNCkgbmV3IHN5c2NhbGwNCg0KQW5kIEkgdGhpbmsgQ09ORklHX01LVE1FX0tFWVMg
-ZG9lc24ndCByZWFsbHkgbmVlZCB0byBkZXBlbmQgb24NCkNPTkZJR19JTlRFTF9NS1RNRSBhdCB0
-aGlzIHBvaW50LCBhbHRob3VnaCB3ZSBjYW4gYWRkIHN1Y2ggaWYgbmVlZGVkDQp3aGVuIGtpcmls
-bCdzIGNvcmUtTUtUTUUgY29kZSBnZXRzIHVwc3RyZWFtZWQuDQoNClRoYW5rcywNCi1LYWkNCj4g
-DQo+IFN1Z2dlc3Rpb25zIHdlbGNvbWUsDQo+IEFsaXNvbg0KPiANCj4gPiBBbmQgc2luY2UgZW5j
-cnlwdF9tcHJvdGVjdCgpIGlzIGEgbmV3IHN5c2NhbGwsIHlvdSBtYXkgbmVlZCB0byBhZGQNCj4g
-PiBtb3JlIGxpc3RzIGZvciB0aGUgcmV2aWV3LCBpZSwgbGludXgtYXBpLCBhbmQgbWF5YmUgbGlu
-dXgta2VybmVsIGFzDQo+ID4gd2VsbC4NCj4gDQo+IEdvdCBpdC4gV2lsbCBpbmNsdWRlIHRoZXNl
-cyBpbiB2MS4NCj4gDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+IC1LYWkNCj4gPiANCj4gPiA+IA0K
-PiA+ID4gVGhpcyBwYXRjaHNldCBpcyBidWlsdCB1cG9uIEtpcmlsbCBTaHV0ZW1vdidzIHBhdGNo
-c2V0IGZvciB0aGUNCj4gPiA+IGNvcmUgTUtUTUUNCj4gPiA+IHN1cHBvcnQuIFlvdSBjYW4gZmlu
-ZCB0aGF0IGhlcmU6DQo+ID4gPiBnaXQ6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tl
-cm5lbC9naXQva2FzL2xpbnV4LmdpdA0KPiA+ID4gbWt0bWUvd2lwDQo+ID4gPiANCj4gPiA+IA0K
-PiA+ID4gQWxpc29uIFNjaG9maWVsZCAoMTIpOg0KPiA+ID4gICBkb2NzL3g4NjogRG9jdW1lbnQg
-dGhlIE11bHRpLUtleSBUb3RhbCBNZW1vcnkgRW5jcnlwdGlvbiBBUEkNCj4gPiA+ICAgbW06IEdl
-bmVyYWxpemUgdGhlIG1wcm90ZWN0IGltcGxlbWVudGF0aW9uIHRvIHN1cHBvcnQNCj4gPiA+IGV4
-dGVuc2lvbnMNCj4gPiA+ICAgc3lzY2FsbC94ODY6IFdpcmUgdXAgYSBuZXcgc3lzdGVtIGNhbGwg
-Zm9yIG1lbW9yeSBlbmNyeXB0aW9uDQo+ID4gPiBrZXlzDQo+ID4gPiAgIHg4Ni9tbTogQWRkIGhl
-bHBlciBmdW5jdGlvbnMgdG8gbWFuYWdlIG1lbW9yeSBlbmNyeXB0aW9uIGtleXMNCj4gPiA+ICAg
-eDg2L21tOiBBZGQgYSBoZWxwZXIgZnVuY3Rpb24gdG8gc2V0IGtleWlkIGJpdHMgaW4gZW5jcnlw
-dGVkDQo+ID4gPiBWTUEncw0KPiA+ID4gICBtbTogQWRkIHRoZSBlbmNyeXB0X21wcm90ZWN0KCkg
-c3lzdGVtIGNhbGwNCj4gPiA+ICAgeDg2L21tOiBBZGQgaGVscGVyIGZ1bmN0aW9ucyB0byB0cmFj
-ayBlbmNyeXB0ZWQgVk1BJ3MNCj4gPiA+ICAgbW06IFRyYWNrIFZNQSdzIGluIHVzZSBmb3IgZWFj
-aCBtZW1vcnkgZW5jcnlwdGlvbiBrZXlpZA0KPiA+ID4gICBtbTogUmVzdHJpY3QgbWVtb3J5IGVu
-Y3J5cHRpb24gdG8gYW5vbnltb3VzIFZNQSdzDQo+ID4gPiAgIHg4Ni9wY29uZmlnOiBQcm9ncmFt
-IG1lbW9yeSBlbmNyeXB0aW9uIGtleXMgb24gYSBzeXN0ZW0td2lkZQ0KPiA+ID4gYmFzaXMNCj4g
-PiA+ICAga2V5cy9ta3RtZTogQWRkIGEgbmV3IGtleSBzZXJ2aWNlIHR5cGUgZm9yIG1lbW9yeSBl
-bmNyeXB0aW9uDQo+ID4gPiBrZXlzDQo+ID4gPiAgIGtleXMvbWt0bWU6IERvIG5vdCByZXZva2Ug
-aW4gdXNlIG1lbW9yeSBlbmNyeXB0aW9uIGtleXMNCj4gPiA+IA0KPiA+ID4gIERvY3VtZW50YXRp
-b24veDg2L21rdG1lLWtleXMudHh0ICAgICAgIHwgMTUzICsrKysrKysrKysrKysrKysNCj4gPiA+
-ICBhcmNoL3g4Ni9LY29uZmlnICAgICAgICAgICAgICAgICAgICAgICB8ICAgMSArDQo+ID4gPiAg
-YXJjaC94ODYvZW50cnkvc3lzY2FsbHMvc3lzY2FsbF8zMi50YmwgfCAgIDEgKw0KPiA+ID4gIGFy
-Y2gveDg2L2VudHJ5L3N5c2NhbGxzL3N5c2NhbGxfNjQudGJsIHwgICAxICsNCj4gPiA+ICBhcmNo
-L3g4Ni9pbmNsdWRlL2FzbS9pbnRlbF9wY29uZmlnLmggICB8ICA0MiArKysrLQ0KPiA+ID4gIGFy
-Y2gveDg2L2luY2x1ZGUvYXNtL21rdG1lLmggICAgICAgICAgIHwgIDIxICsrKw0KPiA+ID4gIGFy
-Y2gveDg2L21tL21rdG1lLmMgICAgICAgICAgICAgICAgICAgIHwgMTQxICsrKysrKysrKysrKysr
-DQo+ID4gPiAgZnMvZXhlYy5jICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDQgKy0N
-Cj4gPiA+ICBpbmNsdWRlL2tleXMvbWt0bWUtdHlwZS5oICAgICAgICAgICAgICB8ICAyOCArKysN
-Cj4gPiA+ICBpbmNsdWRlL2xpbnV4L2tleS5oICAgICAgICAgICAgICAgICAgICB8ICAgMiArDQo+
-ID4gPiAgaW5jbHVkZS9saW51eC9tbS5oICAgICAgICAgICAgICAgICAgICAgfCAgIDkgKy0NCj4g
-PiA+ICBpbmNsdWRlL2xpbnV4L3N5c2NhbGxzLmggICAgICAgICAgICAgICB8ICAgMiArDQo+ID4g
-PiAgaW5jbHVkZS91YXBpL2FzbS1nZW5lcmljL3VuaXN0ZC5oICAgICAgfCAgIDQgKy0NCj4gPiA+
-ICBrZXJuZWwvZm9yay5jICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMiArDQo+ID4gPiAg
-a2VybmVsL3N5c19uaS5jICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDIgKw0KPiA+ID4gIG1t
-L21tYXAuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDEyICsrDQo+ID4gPiAgbW0v
-bXByb3RlY3QuYyAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgOTMgKysrKysrKysrLQ0KPiA+
-ID4gIG1tL25vbW11LmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICA0ICsNCj4gPiA+
-ICBzZWN1cml0eS9rZXlzL0tjb25maWcgICAgICAgICAgICAgICAgICB8ICAxMSArKw0KPiA+ID4g
-IHNlY3VyaXR5L2tleXMvTWFrZWZpbGUgICAgICAgICAgICAgICAgIHwgICAxICsNCj4gPiA+ICBz
-ZWN1cml0eS9rZXlzL2ludGVybmFsLmggICAgICAgICAgICAgICB8ICAgNiArDQo+ID4gPiAgc2Vj
-dXJpdHkva2V5cy9rZXljdGwuYyAgICAgICAgICAgICAgICAgfCAgIDcgKw0KPiA+ID4gIHNlY3Vy
-aXR5L2tleXMvbWt0bWVfa2V5cy5jICAgICAgICAgICAgIHwgMzI1DQo+ID4gPiArKysrKysrKysr
-KysrKysrKysrKysrKysrKysrKysrKysNCj4gPiA+ICAyMyBmaWxlcyBjaGFuZ2VkLCA4NTUgaW5z
-ZXJ0aW9ucygrKSwgMTcgZGVsZXRpb25zKC0pICBjcmVhdGUNCj4gPiA+IG1vZGUgMTAwNjQ0DQo+
-ID4gPiBEb2N1bWVudGF0aW9uL3g4Ni9ta3RtZS1rZXlzLnR4dCAgY3JlYXRlIG1vZGUgMTAwNjQ0
-DQo+ID4gPiBpbmNsdWRlL2tleXMvbWt0bWUtDQo+ID4gPiB0eXBlLmggIGNyZWF0ZSBtb2RlIDEw
-MDY0NCBzZWN1cml0eS9rZXlzL21rdG1lX2tleXMuYw0KPiA+ID4gDQo+ID4gPiAtLQ0KPiA+ID4g
-Mi4xNC4x
+On Mon, 2018-09-10 at 12:10 -0700, Alison Schofield wrote:
+> On Sun, Sep 09, 2018 at 06:10:19PM -0700, Huang, Kai wrote:
+> > 
+> > > -----Original Message-----
+> > > From: keyrings-owner at vger.kernel.org [mailto:keyrings-
+> > > owner at vger.kernel.org] On Behalf Of Alison Schofield
+> > > Sent: Saturday, September 8, 2018 10:23 AM
+> > > To: dhowells at redhat.com; tglx at linutronix.de
+> > > Cc: Huang, Kai <kai.huang@intel.com>; Nakajima, Jun
+> > > <jun.nakajima@intel.com>; Shutemov, Kirill <kirill.shutemov@intel
+> > > .com>;
+> > > Hansen, Dave <dave.hansen@intel.com>; Sakkinen, Jarkko
+> > > <jarkko.sakkinen@intel.com>; jmorris at namei.org; keyrings at vger.ker
+> > > nel.org;
+> > > linux-security-module at vger.kernel.org; mingo at redhat.com; hpa at zyto
+> > > r.com;
+> > > x86 at kernel.org; linux-mm at kvack.org
+> > > Subject: [RFC 00/12] Multi-Key Total Memory Encryption API
+> > > (MKTME)
+> > > 
+> > > Seeking comments on the APIs supporting MKTME on future Intel
+> > > platforms.
+> > > 
+> > > MKTME (Multi-Key Total Memory Encryption) is a technology
+> > > supporting
+> > > memory encryption on upcoming Intel platforms. Whereas TME allows
+> > > encryption of the entire system memory using a single key, MKTME
+> > > allows
+> > > mulitple encryption domains, each having their own key. While the
+> > > main use
+> > > case for the feature is virtual machine isolation, the API needs
+> > > the flexibility to
+> > > work for a wide range of use cases.
+> > > 
+> > > This RFC presents the 2 API additions that enable userspace to:
+> > >  1) Create Encryption Keys: Kernel Key Service type "mktme"
+> > >  2) Use the Encryption Keys: system call encrypt_mprotect()
+> > > 
+> > > In order to share between: the Kernel Key Service, the new system
+> > > call, and the
+> > > existing mm code, helper functions were created in arch/x86/mktme
+> > 
+> > IMHO, we can separate this series into 2 parts, as you did above,
+> > and send out them separately. The reason is, in general I think
+> > adding new MKTME type to key retention services is not that related
+> > to memory management code, namely the encrypt_mprotect() API part.
+> > 
+> > So if we split the two parts and send them out separately, the
+> > first part can be reviewed by keyring and security guys, without
+> > involving mm guys, and the encrypt_mprotect() part can be more
+> > reviewed more by mm guys. 
+> > 
+> 
+> Kai,
+> 
+> That was the direction I had in mind at the onset: the MKTME key
+> service
+> would be one patch(set) and the MKTME encrypt_mprotect() system call
+> would
+> be delivered in another patch(set).
+> 
+> That separation falls apart when the shared structures and functions
+> are
+> introduced. That 'mktme_map' (maps userspace keys to hardware keyid
+> slots),
+> and the 'encrypt_count' array (counts vma's outstanding for each key)
+> need
+> to be shared by both pieces. These mktme special shared structures
+> and the
+> functions that operate on them are all defined in
+> arch/x86/mm/mktme.h,.c.
+> From there they can be shared with the security/keys/mktme_keys.c
+> 
+> Once I made that separation, I stuck with it. Those structures, and
+> any
+> functions that manipulate those structures live in
+> arch/x86/mm/mktme.h,c
+> 
+> You noted that some of the functions that operate on the
+> encrypt_count
+> might not need to be over in arch/x86/mm/mktme.c because they are not
+> used
+> in the mm code. That is true.  
+
+Yes IMO this is better.
+
+> But, then I'd be splitting up the definition
+> of the struct and the funcs that operate on it. So, I stuck with
+> keeping it
+> all together in the arch specific mktme files.
+
+Definition can also be in include/keys/mktme-type.h, right?
+
+> 
+> Having said all the above, I do welcome other ideas on how to better
+> organize
+> the code. 
+> 
+> Back to your request- to split it into smaller patchsets might look
+> something
+> like:
+> 1) the MKTME API helpers
+
+Exactly what helpers?
+
+> 2) the MKTME Key Service
+> 3) the MKTME syscall encrypt_mprotect()
+> 
+> I'm not clear that would make anyones review life easier, than
+> picking
+> the same pieces out of the greater patchset.
+
+Well, the reason I suggested we should split key retention services
+from other staff and get it reviewed first is I think the
+functionalities of MKTME key type has nothing to do w/ MM code. IMHO
+what MKTME key type should provide includes:
+
+1) Support add_key, keyctl (revoke, etc) obviously. THis also implies
+keyID allocation, so you will need some info from MM or x86 code to get
+ info such as number of keyIDs, etc. In fact I think number of keyIDs
+is  the only info you need (0 keyIDs means MKTME is disabled).
+
+2) You need to provide some APIs to munipulate key reference count.
+Those functions can be declared in mktme-type.h, and implemented in
+mktme_keys.c. I think this is more reasonable, as logically reference
+count is part of MKTME key service.
+
+I don't think you need to do anything else in MKTME key type?
+
+I think you can even start upstreaming MKTME key type now w/o Kirill's
+core-MKTME support, since 1) adding MKTME key type doesn't do any harm
+w/o kirill's core-MKTME code; 2) logically MKTME key type has no true
+dependency on core-MKTME code.
+
+So IMHO, a better structure should be:
+
+1) Current upstream code (maybe with some early detction code change,
+ie, to disable MKTME for some SW reason, but I am not sure whether this
+is truely needed, since when MKTME key type gets initialized, that part
+should been done already).
+2) MKTME key type
+3) Kirill's core-MKTME
+4) new syscall
+
+And I think CONFIG_MKTME_KEYS doesn't really need to depend on
+CONFIG_INTEL_MKTME at this point, although we can add such if needed
+when kirill's core-MKTME code gets upstreamed.
+
+Thanks,
+-Kai
+> 
+> Suggestions welcome,
+> Alison
+> 
+> > And since encrypt_mprotect() is a new syscall, you may need to add
+> > more lists for the review, ie, linux-api, and maybe linux-kernel as
+> > well.
+> 
+> Got it. Will include theses in v1.
+> 
+> > 
+> > Thanks,
+> > -Kai
+> > 
+> > > 
+> > > This patchset is built upon Kirill Shutemov's patchset for the
+> > > core MKTME
+> > > support. You can find that here:
+> > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git
+> > > mktme/wip
+> > > 
+> > > 
+> > > Alison Schofield (12):
+> > >   docs/x86: Document the Multi-Key Total Memory Encryption API
+> > >   mm: Generalize the mprotect implementation to support
+> > > extensions
+> > >   syscall/x86: Wire up a new system call for memory encryption
+> > > keys
+> > >   x86/mm: Add helper functions to manage memory encryption keys
+> > >   x86/mm: Add a helper function to set keyid bits in encrypted
+> > > VMA's
+> > >   mm: Add the encrypt_mprotect() system call
+> > >   x86/mm: Add helper functions to track encrypted VMA's
+> > >   mm: Track VMA's in use for each memory encryption keyid
+> > >   mm: Restrict memory encryption to anonymous VMA's
+> > >   x86/pconfig: Program memory encryption keys on a system-wide
+> > > basis
+> > >   keys/mktme: Add a new key service type for memory encryption
+> > > keys
+> > >   keys/mktme: Do not revoke in use memory encryption keys
+> > > 
+> > >  Documentation/x86/mktme-keys.txt       | 153 ++++++++++++++++
+> > >  arch/x86/Kconfig                       |   1 +
+> > >  arch/x86/entry/syscalls/syscall_32.tbl |   1 +
+> > >  arch/x86/entry/syscalls/syscall_64.tbl |   1 +
+> > >  arch/x86/include/asm/intel_pconfig.h   |  42 ++++-
+> > >  arch/x86/include/asm/mktme.h           |  21 +++
+> > >  arch/x86/mm/mktme.c                    | 141 ++++++++++++++
+> > >  fs/exec.c                              |   4 +-
+> > >  include/keys/mktme-type.h              |  28 +++
+> > >  include/linux/key.h                    |   2 +
+> > >  include/linux/mm.h                     |   9 +-
+> > >  include/linux/syscalls.h               |   2 +
+> > >  include/uapi/asm-generic/unistd.h      |   4 +-
+> > >  kernel/fork.c                          |   2 +
+> > >  kernel/sys_ni.c                        |   2 +
+> > >  mm/mmap.c                              |  12 ++
+> > >  mm/mprotect.c                          |  93 +++++++++-
+> > >  mm/nommu.c                             |   4 +
+> > >  security/keys/Kconfig                  |  11 ++
+> > >  security/keys/Makefile                 |   1 +
+> > >  security/keys/internal.h               |   6 +
+> > >  security/keys/keyctl.c                 |   7 +
+> > >  security/keys/mktme_keys.c             | 325
+> > > +++++++++++++++++++++++++++++++++
+> > >  23 files changed, 855 insertions(+), 17 deletions(-)  create
+> > > mode 100644
+> > > Documentation/x86/mktme-keys.txt  create mode 100644
+> > > include/keys/mktme-
+> > > type.h  create mode 100644 security/keys/mktme_keys.c
+> > > 
+> > > --
+> > > 2.14.1
diff --git a/a/content_digest b/N1/content_digest
index e520873..ef1f5d1 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,185 +1,234 @@
  "ref\0cover.1536356108.git.alison.schofield@intel.com\0"
  "ref\0105F7BF4D0229846AF094488D65A098935424961@PGSMSX112.gar.corp.intel.com\0"
  "ref\020180910191059.GA26529@alison-desk.jf.intel.com\0"
- "From\0Huang, Kai <kai.huang@intel.com>\0"
- "Subject\0Re: [RFC 00/12] Multi-Key Total Memory Encryption API (MKTME)\0"
+ "From\0kai.huang@intel.com (Huang, Kai)\0"
+ "Subject\0[RFC 00/12] Multi-Key Total Memory Encryption API (MKTME)\0"
  "Date\0Tue, 11 Sep 2018 03:15:22 +0000\0"
- "To\0Schofield"
- " Alison <alison.schofield@intel.com>\0"
- "Cc\0Shutemov"
-  Kirill <kirill.shutemov@intel.com>
-  jmorris@namei.org <jmorris@namei.org>
-  keyrings@vger.kernel.org <keyrings@vger.kernel.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>
-  x86@kernel.org <x86@kernel.org>
-  hpa@zytor.com <hpa@zytor.com>
-  mingo@redhat.com <mingo@redhat.com>
-  Sakkinen
-  Jarkko <jarkko.sakkinen@intel.com>
-  Hansen
-  Dave <dave.hansen@intel.com>
-  Nakajima
- " Jun <jun.nakajima@intel.com>\0"
+ "To\0linux-security-module@vger.kernel.org\0"
  "\00:1\0"
  "b\0"
- "T24gTW9uLCAyMDE4LTA5LTEwIGF0IDEyOjEwIC0wNzAwLCBBbGlzb24gU2Nob2ZpZWxkIHdyb3Rl\n"
- "Og0KPiBPbiBTdW4sIFNlcCAwOSwgMjAxOCBhdCAwNjoxMDoxOVBNIC0wNzAwLCBIdWFuZywgS2Fp\n"
- "IHdyb3RlOg0KPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZy\n"
- "b206IGtleXJpbmdzLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmtleXJpbmdzLQ0KPiA+\n"
- "ID4gb3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgQWxpc29uIFNjaG9maWVsZA0K\n"
- "PiA+ID4gU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciA4LCAyMDE4IDEwOjIzIEFNDQo+ID4gPiBU\n"
- "bzogZGhvd2VsbHNAcmVkaGF0LmNvbTsgdGdseEBsaW51dHJvbml4LmRlDQo+ID4gPiBDYzogSHVh\n"
- "bmcsIEthaSA8a2FpLmh1YW5nQGludGVsLmNvbT47IE5ha2FqaW1hLCBKdW4NCj4gPiA+IDxqdW4u\n"
- "bmFrYWppbWFAaW50ZWwuY29tPjsgU2h1dGVtb3YsIEtpcmlsbCA8a2lyaWxsLnNodXRlbW92QGlu\n"
- "dGVsDQo+ID4gPiAuY29tPjsNCj4gPiA+IEhhbnNlbiwgRGF2ZSA8ZGF2ZS5oYW5zZW5AaW50ZWwu\n"
- "Y29tPjsgU2Fra2luZW4sIEphcmtrbw0KPiA+ID4gPGphcmtrby5zYWtraW5lbkBpbnRlbC5jb20+\n"
- "OyBqbW9ycmlzQG5hbWVpLm9yZzsga2V5cmluZ3NAdmdlci5rZXINCj4gPiA+IG5lbC5vcmc7DQo+\n"
- "ID4gPiBsaW51eC1zZWN1cml0eS1tb2R1bGVAdmdlci5rZXJuZWwub3JnOyBtaW5nb0ByZWRoYXQu\n"
- "Y29tOyBocGFAenl0bw0KPiA+ID4gci5jb207DQo+ID4gPiB4ODZAa2VybmVsLm9yZzsgbGludXgt\n"
- "bW1Aa3ZhY2sub3JnDQo+ID4gPiBTdWJqZWN0OiBbUkZDIDAwLzEyXSBNdWx0aS1LZXkgVG90YWwg\n"
- "TWVtb3J5IEVuY3J5cHRpb24gQVBJDQo+ID4gPiAoTUtUTUUpDQo+ID4gPiANCj4gPiA+IFNlZWtp\n"
- "bmcgY29tbWVudHMgb24gdGhlIEFQSXMgc3VwcG9ydGluZyBNS1RNRSBvbiBmdXR1cmUgSW50ZWwN\n"
- "Cj4gPiA+IHBsYXRmb3Jtcy4NCj4gPiA+IA0KPiA+ID4gTUtUTUUgKE11bHRpLUtleSBUb3RhbCBN\n"
- "ZW1vcnkgRW5jcnlwdGlvbikgaXMgYSB0ZWNobm9sb2d5DQo+ID4gPiBzdXBwb3J0aW5nDQo+ID4g\n"
- "PiBtZW1vcnkgZW5jcnlwdGlvbiBvbiB1cGNvbWluZyBJbnRlbCBwbGF0Zm9ybXMuIFdoZXJlYXMg\n"
- "VE1FIGFsbG93cw0KPiA+ID4gZW5jcnlwdGlvbiBvZiB0aGUgZW50aXJlIHN5c3RlbSBtZW1vcnkg\n"
- "dXNpbmcgYSBzaW5nbGUga2V5LCBNS1RNRQ0KPiA+ID4gYWxsb3dzDQo+ID4gPiBtdWxpdHBsZSBl\n"
- "bmNyeXB0aW9uIGRvbWFpbnMsIGVhY2ggaGF2aW5nIHRoZWlyIG93biBrZXkuIFdoaWxlIHRoZQ0K\n"
- "PiA+ID4gbWFpbiB1c2UNCj4gPiA+IGNhc2UgZm9yIHRoZSBmZWF0dXJlIGlzIHZpcnR1YWwgbWFj\n"
- "aGluZSBpc29sYXRpb24sIHRoZSBBUEkgbmVlZHMNCj4gPiA+IHRoZSBmbGV4aWJpbGl0eSB0bw0K\n"
- "PiA+ID4gd29yayBmb3IgYSB3aWRlIHJhbmdlIG9mIHVzZSBjYXNlcy4NCj4gPiA+IA0KPiA+ID4g\n"
- "VGhpcyBSRkMgcHJlc2VudHMgdGhlIDIgQVBJIGFkZGl0aW9ucyB0aGF0IGVuYWJsZSB1c2Vyc3Bh\n"
- "Y2UgdG86DQo+ID4gPiAgMSkgQ3JlYXRlIEVuY3J5cHRpb24gS2V5czogS2VybmVsIEtleSBTZXJ2\n"
- "aWNlIHR5cGUgIm1rdG1lIg0KPiA+ID4gIDIpIFVzZSB0aGUgRW5jcnlwdGlvbiBLZXlzOiBzeXN0\n"
- "ZW0gY2FsbCBlbmNyeXB0X21wcm90ZWN0KCkNCj4gPiA+IA0KPiA+ID4gSW4gb3JkZXIgdG8gc2hh\n"
- "cmUgYmV0d2VlbjogdGhlIEtlcm5lbCBLZXkgU2VydmljZSwgdGhlIG5ldyBzeXN0ZW0NCj4gPiA+\n"
- "IGNhbGwsIGFuZCB0aGUNCj4gPiA+IGV4aXN0aW5nIG1tIGNvZGUsIGhlbHBlciBmdW5jdGlvbnMg\n"
- "d2VyZSBjcmVhdGVkIGluIGFyY2gveDg2L21rdG1lDQo+ID4gDQo+ID4gSU1ITywgd2UgY2FuIHNl\n"
- "cGFyYXRlIHRoaXMgc2VyaWVzIGludG8gMiBwYXJ0cywgYXMgeW91IGRpZCBhYm92ZSwNCj4gPiBh\n"
- "bmQgc2VuZCBvdXQgdGhlbSBzZXBhcmF0ZWx5LiBUaGUgcmVhc29uIGlzLCBpbiBnZW5lcmFsIEkg\n"
- "dGhpbmsNCj4gPiBhZGRpbmcgbmV3IE1LVE1FIHR5cGUgdG8ga2V5IHJldGVudGlvbiBzZXJ2aWNl\n"
- "cyBpcyBub3QgdGhhdCByZWxhdGVkDQo+ID4gdG8gbWVtb3J5IG1hbmFnZW1lbnQgY29kZSwgbmFt\n"
- "ZWx5IHRoZSBlbmNyeXB0X21wcm90ZWN0KCkgQVBJIHBhcnQuDQo+ID4gDQo+ID4gU28gaWYgd2Ug\n"
- "c3BsaXQgdGhlIHR3byBwYXJ0cyBhbmQgc2VuZCB0aGVtIG91dCBzZXBhcmF0ZWx5LCB0aGUNCj4g\n"
- "PiBmaXJzdCBwYXJ0IGNhbiBiZSByZXZpZXdlZCBieSBrZXlyaW5nIGFuZCBzZWN1cml0eSBndXlz\n"
- "LCB3aXRob3V0DQo+ID4gaW52b2x2aW5nIG1tIGd1eXMsIGFuZCB0aGUgZW5jcnlwdF9tcHJvdGVj\n"
- "dCgpIHBhcnQgY2FuIGJlIG1vcmUNCj4gPiByZXZpZXdlZCBtb3JlIGJ5IG1tIGd1eXMuIA0KPiA+\n"
- "IA0KPiANCj4gS2FpLA0KPiANCj4gVGhhdCB3YXMgdGhlIGRpcmVjdGlvbiBJIGhhZCBpbiBtaW5k\n"
- "IGF0IHRoZSBvbnNldDogdGhlIE1LVE1FIGtleQ0KPiBzZXJ2aWNlDQo+IHdvdWxkIGJlIG9uZSBw\n"
- "YXRjaChzZXQpIGFuZCB0aGUgTUtUTUUgZW5jcnlwdF9tcHJvdGVjdCgpIHN5c3RlbSBjYWxsDQo+\n"
- "IHdvdWxkDQo+IGJlIGRlbGl2ZXJlZCBpbiBhbm90aGVyIHBhdGNoKHNldCkuDQo+IA0KPiBUaGF0\n"
- "IHNlcGFyYXRpb24gZmFsbHMgYXBhcnQgd2hlbiB0aGUgc2hhcmVkIHN0cnVjdHVyZXMgYW5kIGZ1\n"
- "bmN0aW9ucw0KPiBhcmUNCj4gaW50cm9kdWNlZC4gVGhhdCAnbWt0bWVfbWFwJyAobWFwcyB1c2Vy\n"
- "c3BhY2Uga2V5cyB0byBoYXJkd2FyZSBrZXlpZA0KPiBzbG90cyksDQo+IGFuZCB0aGUgJ2VuY3J5\n"
- "cHRfY291bnQnIGFycmF5IChjb3VudHMgdm1hJ3Mgb3V0c3RhbmRpbmcgZm9yIGVhY2gga2V5KQ0K\n"
- "PiBuZWVkDQo+IHRvIGJlIHNoYXJlZCBieSBib3RoIHBpZWNlcy4gVGhlc2UgbWt0bWUgc3BlY2lh\n"
- "bCBzaGFyZWQgc3RydWN0dXJlcw0KPiBhbmQgdGhlDQo+IGZ1bmN0aW9ucyB0aGF0IG9wZXJhdGUg\n"
- "b24gdGhlbSBhcmUgYWxsIGRlZmluZWQgaW4NCj4gYXJjaC94ODYvbW0vbWt0bWUuaCwuYy4NCj4g\n"
- "RnJvbSB0aGVyZSB0aGV5IGNhbiBiZSBzaGFyZWQgd2l0aCB0aGUgc2VjdXJpdHkva2V5cy9ta3Rt\n"
- "ZV9rZXlzLmMNCj4gDQo+IE9uY2UgSSBtYWRlIHRoYXQgc2VwYXJhdGlvbiwgSSBzdHVjayB3aXRo\n"
- "IGl0LiBUaG9zZSBzdHJ1Y3R1cmVzLCBhbmQNCj4gYW55DQo+IGZ1bmN0aW9ucyB0aGF0IG1hbmlw\n"
- "dWxhdGUgdGhvc2Ugc3RydWN0dXJlcyBsaXZlIGluDQo+IGFyY2gveDg2L21tL21rdG1lLmgsYw0K\n"
- "PiANCj4gWW91IG5vdGVkIHRoYXQgc29tZSBvZiB0aGUgZnVuY3Rpb25zIHRoYXQgb3BlcmF0ZSBv\n"
- "biB0aGUNCj4gZW5jcnlwdF9jb3VudA0KPiBtaWdodCBub3QgbmVlZCB0byBiZSBvdmVyIGluIGFy\n"
- "Y2gveDg2L21tL21rdG1lLmMgYmVjYXVzZSB0aGV5IGFyZSBub3QNCj4gdXNlZA0KPiBpbiB0aGUg\n"
- "bW0gY29kZS4gVGhhdCBpcyB0cnVlLiAgDQoNClllcyBJTU8gdGhpcyBpcyBiZXR0ZXIuDQoNCj4g\n"
- "QnV0LCB0aGVuIEknZCBiZSBzcGxpdHRpbmcgdXAgdGhlIGRlZmluaXRpb24NCj4gb2YgdGhlIHN0\n"
- "cnVjdCBhbmQgdGhlIGZ1bmNzIHRoYXQgb3BlcmF0ZSBvbiBpdC4gU28sIEkgc3R1Y2sgd2l0aA0K\n"
- "PiBrZWVwaW5nIGl0DQo+IGFsbCB0b2dldGhlciBpbiB0aGUgYXJjaCBzcGVjaWZpYyBta3RtZSBm\n"
- "aWxlcy4NCg0KRGVmaW5pdGlvbiBjYW4gYWxzbyBiZSBpbiBpbmNsdWRlL2tleXMvbWt0bWUtdHlw\n"
- "ZS5oLCByaWdodD8NCg0KPiANCj4gSGF2aW5nIHNhaWQgYWxsIHRoZSBhYm92ZSwgSSBkbyB3ZWxj\n"
- "b21lIG90aGVyIGlkZWFzIG9uIGhvdyB0byBiZXR0ZXINCj4gb3JnYW5pemUNCj4gdGhlIGNvZGUu\n"
- "IA0KPiANCj4gQmFjayB0byB5b3VyIHJlcXVlc3QtIHRvIHNwbGl0IGl0IGludG8gc21hbGxlciBw\n"
- "YXRjaHNldHMgbWlnaHQgbG9vaw0KPiBzb21ldGhpbmcNCj4gbGlrZToNCj4gMSkgdGhlIE1LVE1F\n"
- "IEFQSSBoZWxwZXJzDQoNCkV4YWN0bHkgd2hhdCBoZWxwZXJzPw0KDQo+IDIpIHRoZSBNS1RNRSBL\n"
- "ZXkgU2VydmljZQ0KPiAzKSB0aGUgTUtUTUUgc3lzY2FsbCBlbmNyeXB0X21wcm90ZWN0KCkNCj4g\n"
- "DQo+IEknbSBub3QgY2xlYXIgdGhhdCB3b3VsZCBtYWtlIGFueW9uZXMgcmV2aWV3IGxpZmUgZWFz\n"
- "aWVyLCB0aGFuDQo+IHBpY2tpbmcNCj4gdGhlIHNhbWUgcGllY2VzIG91dCBvZiB0aGUgZ3JlYXRl\n"
- "ciBwYXRjaHNldC4NCg0KV2VsbCwgdGhlIHJlYXNvbiBJIHN1Z2dlc3RlZCB3ZSBzaG91bGQgc3Bs\n"
- "aXQga2V5IHJldGVudGlvbiBzZXJ2aWNlcw0KZnJvbSBvdGhlciBzdGFmZiBhbmQgZ2V0IGl0IHJl\n"
- "dmlld2VkIGZpcnN0IGlzIEkgdGhpbmsgdGhlDQpmdW5jdGlvbmFsaXRpZXMgb2YgTUtUTUUga2V5\n"
- "IHR5cGUgaGFzIG5vdGhpbmcgdG8gZG8gdy8gTU0gY29kZS4gSU1ITw0Kd2hhdCBNS1RNRSBrZXkg\n"
- "dHlwZSBzaG91bGQgcHJvdmlkZSBpbmNsdWRlczoNCg0KMSkgU3VwcG9ydCBhZGRfa2V5LCBrZXlj\n"
- "dGwgKHJldm9rZSwgZXRjKSBvYnZpb3VzbHkuIFRIaXMgYWxzbyBpbXBsaWVzDQprZXlJRCBhbGxv\n"
- "Y2F0aW9uLCBzbyB5b3Ugd2lsbCBuZWVkIHNvbWUgaW5mbyBmcm9tIE1NIG9yIHg4NiBjb2RlIHRv\n"
- "IGdldA0KIGluZm8gc3VjaCBhcyBudW1iZXIgb2Yga2V5SURzLCBldGMuIEluIGZhY3QgSSB0aGlu\n"
- "ayBudW1iZXIgb2Yga2V5SURzDQppcyAgdGhlIG9ubHkgaW5mbyB5b3UgbmVlZCAoMCBrZXlJRHMg\n"
- "bWVhbnMgTUtUTUUgaXMgZGlzYWJsZWQpLg0KDQoyKSBZb3UgbmVlZCB0byBwcm92aWRlIHNvbWUg\n"
- "QVBJcyB0byBtdW5pcHVsYXRlIGtleSByZWZlcmVuY2UgY291bnQuDQpUaG9zZSBmdW5jdGlvbnMg\n"
- "Y2FuIGJlIGRlY2xhcmVkIGluIG1rdG1lLXR5cGUuaCwgYW5kIGltcGxlbWVudGVkIGluDQpta3Rt\n"
- "ZV9rZXlzLmMuIEkgdGhpbmsgdGhpcyBpcyBtb3JlIHJlYXNvbmFibGUsIGFzIGxvZ2ljYWxseSBy\n"
- "ZWZlcmVuY2UNCmNvdW50IGlzIHBhcnQgb2YgTUtUTUUga2V5IHNlcnZpY2UuDQoNCkkgZG9uJ3Qg\n"
- "dGhpbmsgeW91IG5lZWQgdG8gZG8gYW55dGhpbmcgZWxzZSBpbiBNS1RNRSBrZXkgdHlwZT8NCg0K\n"
- "SSB0aGluayB5b3UgY2FuIGV2ZW4gc3RhcnQgdXBzdHJlYW1pbmcgTUtUTUUga2V5IHR5cGUgbm93\n"
- "IHcvbyBLaXJpbGwncw0KY29yZS1NS1RNRSBzdXBwb3J0LCBzaW5jZSAxKSBhZGRpbmcgTUtUTUUg\n"
- "a2V5IHR5cGUgZG9lc24ndCBkbyBhbnkgaGFybQ0Kdy9vIGtpcmlsbCdzIGNvcmUtTUtUTUUgY29k\n"
- "ZTsgMikgbG9naWNhbGx5IE1LVE1FIGtleSB0eXBlIGhhcyBubyB0cnVlDQpkZXBlbmRlbmN5IG9u\n"
- "IGNvcmUtTUtUTUUgY29kZS4NCg0KU28gSU1ITywgYSBiZXR0ZXIgc3RydWN0dXJlIHNob3VsZCBi\n"
- "ZToNCg0KMSkgQ3VycmVudCB1cHN0cmVhbSBjb2RlIChtYXliZSB3aXRoIHNvbWUgZWFybHkgZGV0\n"
- "Y3Rpb24gY29kZSBjaGFuZ2UsDQppZSwgdG8gZGlzYWJsZSBNS1RNRSBmb3Igc29tZSBTVyByZWFz\n"
- "b24sIGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcw0KaXMgdHJ1ZWx5IG5lZWRlZCwgc2lu\n"
- "Y2Ugd2hlbiBNS1RNRSBrZXkgdHlwZSBnZXRzIGluaXRpYWxpemVkLCB0aGF0IHBhcnQNCnNob3Vs\n"
- "ZCBiZWVuIGRvbmUgYWxyZWFkeSkuDQoyKSBNS1RNRSBrZXkgdHlwZQ0KMykgS2lyaWxsJ3MgY29y\n"
- "ZS1NS1RNRQ0KNCkgbmV3IHN5c2NhbGwNCg0KQW5kIEkgdGhpbmsgQ09ORklHX01LVE1FX0tFWVMg\n"
- "ZG9lc24ndCByZWFsbHkgbmVlZCB0byBkZXBlbmQgb24NCkNPTkZJR19JTlRFTF9NS1RNRSBhdCB0\n"
- "aGlzIHBvaW50LCBhbHRob3VnaCB3ZSBjYW4gYWRkIHN1Y2ggaWYgbmVlZGVkDQp3aGVuIGtpcmls\n"
- "bCdzIGNvcmUtTUtUTUUgY29kZSBnZXRzIHVwc3RyZWFtZWQuDQoNClRoYW5rcywNCi1LYWkNCj4g\n"
- "DQo+IFN1Z2dlc3Rpb25zIHdlbGNvbWUsDQo+IEFsaXNvbg0KPiANCj4gPiBBbmQgc2luY2UgZW5j\n"
- "cnlwdF9tcHJvdGVjdCgpIGlzIGEgbmV3IHN5c2NhbGwsIHlvdSBtYXkgbmVlZCB0byBhZGQNCj4g\n"
- "PiBtb3JlIGxpc3RzIGZvciB0aGUgcmV2aWV3LCBpZSwgbGludXgtYXBpLCBhbmQgbWF5YmUgbGlu\n"
- "dXgta2VybmVsIGFzDQo+ID4gd2VsbC4NCj4gDQo+IEdvdCBpdC4gV2lsbCBpbmNsdWRlIHRoZXNl\n"
- "cyBpbiB2MS4NCj4gDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+IC1LYWkNCj4gPiANCj4gPiA+IA0K\n"
- "PiA+ID4gVGhpcyBwYXRjaHNldCBpcyBidWlsdCB1cG9uIEtpcmlsbCBTaHV0ZW1vdidzIHBhdGNo\n"
- "c2V0IGZvciB0aGUNCj4gPiA+IGNvcmUgTUtUTUUNCj4gPiA+IHN1cHBvcnQuIFlvdSBjYW4gZmlu\n"
- "ZCB0aGF0IGhlcmU6DQo+ID4gPiBnaXQ6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tl\n"
- "cm5lbC9naXQva2FzL2xpbnV4LmdpdA0KPiA+ID4gbWt0bWUvd2lwDQo+ID4gPiANCj4gPiA+IA0K\n"
- "PiA+ID4gQWxpc29uIFNjaG9maWVsZCAoMTIpOg0KPiA+ID4gICBkb2NzL3g4NjogRG9jdW1lbnQg\n"
- "dGhlIE11bHRpLUtleSBUb3RhbCBNZW1vcnkgRW5jcnlwdGlvbiBBUEkNCj4gPiA+ICAgbW06IEdl\n"
- "bmVyYWxpemUgdGhlIG1wcm90ZWN0IGltcGxlbWVudGF0aW9uIHRvIHN1cHBvcnQNCj4gPiA+IGV4\n"
- "dGVuc2lvbnMNCj4gPiA+ICAgc3lzY2FsbC94ODY6IFdpcmUgdXAgYSBuZXcgc3lzdGVtIGNhbGwg\n"
- "Zm9yIG1lbW9yeSBlbmNyeXB0aW9uDQo+ID4gPiBrZXlzDQo+ID4gPiAgIHg4Ni9tbTogQWRkIGhl\n"
- "bHBlciBmdW5jdGlvbnMgdG8gbWFuYWdlIG1lbW9yeSBlbmNyeXB0aW9uIGtleXMNCj4gPiA+ICAg\n"
- "eDg2L21tOiBBZGQgYSBoZWxwZXIgZnVuY3Rpb24gdG8gc2V0IGtleWlkIGJpdHMgaW4gZW5jcnlw\n"
- "dGVkDQo+ID4gPiBWTUEncw0KPiA+ID4gICBtbTogQWRkIHRoZSBlbmNyeXB0X21wcm90ZWN0KCkg\n"
- "c3lzdGVtIGNhbGwNCj4gPiA+ICAgeDg2L21tOiBBZGQgaGVscGVyIGZ1bmN0aW9ucyB0byB0cmFj\n"
- "ayBlbmNyeXB0ZWQgVk1BJ3MNCj4gPiA+ICAgbW06IFRyYWNrIFZNQSdzIGluIHVzZSBmb3IgZWFj\n"
- "aCBtZW1vcnkgZW5jcnlwdGlvbiBrZXlpZA0KPiA+ID4gICBtbTogUmVzdHJpY3QgbWVtb3J5IGVu\n"
- "Y3J5cHRpb24gdG8gYW5vbnltb3VzIFZNQSdzDQo+ID4gPiAgIHg4Ni9wY29uZmlnOiBQcm9ncmFt\n"
- "IG1lbW9yeSBlbmNyeXB0aW9uIGtleXMgb24gYSBzeXN0ZW0td2lkZQ0KPiA+ID4gYmFzaXMNCj4g\n"
- "PiA+ICAga2V5cy9ta3RtZTogQWRkIGEgbmV3IGtleSBzZXJ2aWNlIHR5cGUgZm9yIG1lbW9yeSBl\n"
- "bmNyeXB0aW9uDQo+ID4gPiBrZXlzDQo+ID4gPiAgIGtleXMvbWt0bWU6IERvIG5vdCByZXZva2Ug\n"
- "aW4gdXNlIG1lbW9yeSBlbmNyeXB0aW9uIGtleXMNCj4gPiA+IA0KPiA+ID4gIERvY3VtZW50YXRp\n"
- "b24veDg2L21rdG1lLWtleXMudHh0ICAgICAgIHwgMTUzICsrKysrKysrKysrKysrKysNCj4gPiA+\n"
- "ICBhcmNoL3g4Ni9LY29uZmlnICAgICAgICAgICAgICAgICAgICAgICB8ICAgMSArDQo+ID4gPiAg\n"
- "YXJjaC94ODYvZW50cnkvc3lzY2FsbHMvc3lzY2FsbF8zMi50YmwgfCAgIDEgKw0KPiA+ID4gIGFy\n"
- "Y2gveDg2L2VudHJ5L3N5c2NhbGxzL3N5c2NhbGxfNjQudGJsIHwgICAxICsNCj4gPiA+ICBhcmNo\n"
- "L3g4Ni9pbmNsdWRlL2FzbS9pbnRlbF9wY29uZmlnLmggICB8ICA0MiArKysrLQ0KPiA+ID4gIGFy\n"
- "Y2gveDg2L2luY2x1ZGUvYXNtL21rdG1lLmggICAgICAgICAgIHwgIDIxICsrKw0KPiA+ID4gIGFy\n"
- "Y2gveDg2L21tL21rdG1lLmMgICAgICAgICAgICAgICAgICAgIHwgMTQxICsrKysrKysrKysrKysr\n"
- "DQo+ID4gPiAgZnMvZXhlYy5jICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDQgKy0N\n"
- "Cj4gPiA+ICBpbmNsdWRlL2tleXMvbWt0bWUtdHlwZS5oICAgICAgICAgICAgICB8ICAyOCArKysN\n"
- "Cj4gPiA+ICBpbmNsdWRlL2xpbnV4L2tleS5oICAgICAgICAgICAgICAgICAgICB8ICAgMiArDQo+\n"
- "ID4gPiAgaW5jbHVkZS9saW51eC9tbS5oICAgICAgICAgICAgICAgICAgICAgfCAgIDkgKy0NCj4g\n"
- "PiA+ICBpbmNsdWRlL2xpbnV4L3N5c2NhbGxzLmggICAgICAgICAgICAgICB8ICAgMiArDQo+ID4g\n"
- "PiAgaW5jbHVkZS91YXBpL2FzbS1nZW5lcmljL3VuaXN0ZC5oICAgICAgfCAgIDQgKy0NCj4gPiA+\n"
- "ICBrZXJuZWwvZm9yay5jICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMiArDQo+ID4gPiAg\n"
- "a2VybmVsL3N5c19uaS5jICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDIgKw0KPiA+ID4gIG1t\n"
- "L21tYXAuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDEyICsrDQo+ID4gPiAgbW0v\n"
- "bXByb3RlY3QuYyAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgOTMgKysrKysrKysrLQ0KPiA+\n"
- "ID4gIG1tL25vbW11LmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICA0ICsNCj4gPiA+\n"
- "ICBzZWN1cml0eS9rZXlzL0tjb25maWcgICAgICAgICAgICAgICAgICB8ICAxMSArKw0KPiA+ID4g\n"
- "IHNlY3VyaXR5L2tleXMvTWFrZWZpbGUgICAgICAgICAgICAgICAgIHwgICAxICsNCj4gPiA+ICBz\n"
- "ZWN1cml0eS9rZXlzL2ludGVybmFsLmggICAgICAgICAgICAgICB8ICAgNiArDQo+ID4gPiAgc2Vj\n"
- "dXJpdHkva2V5cy9rZXljdGwuYyAgICAgICAgICAgICAgICAgfCAgIDcgKw0KPiA+ID4gIHNlY3Vy\n"
- "aXR5L2tleXMvbWt0bWVfa2V5cy5jICAgICAgICAgICAgIHwgMzI1DQo+ID4gPiArKysrKysrKysr\n"
- "KysrKysrKysrKysrKysrKysrKysrKysNCj4gPiA+ICAyMyBmaWxlcyBjaGFuZ2VkLCA4NTUgaW5z\n"
- "ZXJ0aW9ucygrKSwgMTcgZGVsZXRpb25zKC0pICBjcmVhdGUNCj4gPiA+IG1vZGUgMTAwNjQ0DQo+\n"
- "ID4gPiBEb2N1bWVudGF0aW9uL3g4Ni9ta3RtZS1rZXlzLnR4dCAgY3JlYXRlIG1vZGUgMTAwNjQ0\n"
- "DQo+ID4gPiBpbmNsdWRlL2tleXMvbWt0bWUtDQo+ID4gPiB0eXBlLmggIGNyZWF0ZSBtb2RlIDEw\n"
- "MDY0NCBzZWN1cml0eS9rZXlzL21rdG1lX2tleXMuYw0KPiA+ID4gDQo+ID4gPiAtLQ0KPiA+ID4g\n"
- Mi4xNC4x
+ "On Mon, 2018-09-10 at 12:10 -0700, Alison Schofield wrote:\n"
+ "> On Sun, Sep 09, 2018 at 06:10:19PM -0700, Huang, Kai wrote:\n"
+ "> > \n"
+ "> > > -----Original Message-----\n"
+ "> > > From: keyrings-owner at vger.kernel.org [mailto:keyrings-\n"
+ "> > > owner at vger.kernel.org] On Behalf Of Alison Schofield\n"
+ "> > > Sent: Saturday, September 8, 2018 10:23 AM\n"
+ "> > > To: dhowells at redhat.com; tglx at linutronix.de\n"
+ "> > > Cc: Huang, Kai <kai.huang@intel.com>; Nakajima, Jun\n"
+ "> > > <jun.nakajima@intel.com>; Shutemov, Kirill <kirill.shutemov@intel\n"
+ "> > > .com>;\n"
+ "> > > Hansen, Dave <dave.hansen@intel.com>; Sakkinen, Jarkko\n"
+ "> > > <jarkko.sakkinen@intel.com>; jmorris at namei.org; keyrings at vger.ker\n"
+ "> > > nel.org;\n"
+ "> > > linux-security-module at vger.kernel.org; mingo at redhat.com; hpa at zyto\n"
+ "> > > r.com;\n"
+ "> > > x86 at kernel.org; linux-mm at kvack.org\n"
+ "> > > Subject: [RFC 00/12] Multi-Key Total Memory Encryption API\n"
+ "> > > (MKTME)\n"
+ "> > > \n"
+ "> > > Seeking comments on the APIs supporting MKTME on future Intel\n"
+ "> > > platforms.\n"
+ "> > > \n"
+ "> > > MKTME (Multi-Key Total Memory Encryption) is a technology\n"
+ "> > > supporting\n"
+ "> > > memory encryption on upcoming Intel platforms. Whereas TME allows\n"
+ "> > > encryption of the entire system memory using a single key, MKTME\n"
+ "> > > allows\n"
+ "> > > mulitple encryption domains, each having their own key. While the\n"
+ "> > > main use\n"
+ "> > > case for the feature is virtual machine isolation, the API needs\n"
+ "> > > the flexibility to\n"
+ "> > > work for a wide range of use cases.\n"
+ "> > > \n"
+ "> > > This RFC presents the 2 API additions that enable userspace to:\n"
+ "> > >  1) Create Encryption Keys: Kernel Key Service type \"mktme\"\n"
+ "> > >  2) Use the Encryption Keys: system call encrypt_mprotect()\n"
+ "> > > \n"
+ "> > > In order to share between: the Kernel Key Service, the new system\n"
+ "> > > call, and the\n"
+ "> > > existing mm code, helper functions were created in arch/x86/mktme\n"
+ "> > \n"
+ "> > IMHO, we can separate this series into 2 parts, as you did above,\n"
+ "> > and send out them separately. The reason is, in general I think\n"
+ "> > adding new MKTME type to key retention services is not that related\n"
+ "> > to memory management code, namely the encrypt_mprotect() API part.\n"
+ "> > \n"
+ "> > So if we split the two parts and send them out separately, the\n"
+ "> > first part can be reviewed by keyring and security guys, without\n"
+ "> > involving mm guys, and the encrypt_mprotect() part can be more\n"
+ "> > reviewed more by mm guys. \n"
+ "> > \n"
+ "> \n"
+ "> Kai,\n"
+ "> \n"
+ "> That was the direction I had in mind at the onset: the MKTME key\n"
+ "> service\n"
+ "> would be one patch(set) and the MKTME encrypt_mprotect() system call\n"
+ "> would\n"
+ "> be delivered in another patch(set).\n"
+ "> \n"
+ "> That separation falls apart when the shared structures and functions\n"
+ "> are\n"
+ "> introduced. That 'mktme_map' (maps userspace keys to hardware keyid\n"
+ "> slots),\n"
+ "> and the 'encrypt_count' array (counts vma's outstanding for each key)\n"
+ "> need\n"
+ "> to be shared by both pieces. These mktme special shared structures\n"
+ "> and the\n"
+ "> functions that operate on them are all defined in\n"
+ "> arch/x86/mm/mktme.h,.c.\n"
+ "> From there they can be shared with the security/keys/mktme_keys.c\n"
+ "> \n"
+ "> Once I made that separation, I stuck with it. Those structures, and\n"
+ "> any\n"
+ "> functions that manipulate those structures live in\n"
+ "> arch/x86/mm/mktme.h,c\n"
+ "> \n"
+ "> You noted that some of the functions that operate on the\n"
+ "> encrypt_count\n"
+ "> might not need to be over in arch/x86/mm/mktme.c because they are not\n"
+ "> used\n"
+ "> in the mm code. That is true.  \n"
+ "\n"
+ "Yes IMO this is better.\n"
+ "\n"
+ "> But, then I'd be splitting up the definition\n"
+ "> of the struct and the funcs that operate on it. So, I stuck with\n"
+ "> keeping it\n"
+ "> all together in the arch specific mktme files.\n"
+ "\n"
+ "Definition can also be in include/keys/mktme-type.h, right?\n"
+ "\n"
+ "> \n"
+ "> Having said all the above, I do welcome other ideas on how to better\n"
+ "> organize\n"
+ "> the code. \n"
+ "> \n"
+ "> Back to your request- to split it into smaller patchsets might look\n"
+ "> something\n"
+ "> like:\n"
+ "> 1) the MKTME API helpers\n"
+ "\n"
+ "Exactly what helpers?\n"
+ "\n"
+ "> 2) the MKTME Key Service\n"
+ "> 3) the MKTME syscall encrypt_mprotect()\n"
+ "> \n"
+ "> I'm not clear that would make anyones review life easier, than\n"
+ "> picking\n"
+ "> the same pieces out of the greater patchset.\n"
+ "\n"
+ "Well, the reason I suggested we should split key retention services\n"
+ "from other staff and get it reviewed first is I think the\n"
+ "functionalities of MKTME key type has nothing to do w/ MM code. IMHO\n"
+ "what MKTME key type should provide includes:\n"
+ "\n"
+ "1) Support add_key, keyctl (revoke, etc) obviously. THis also implies\n"
+ "keyID allocation, so you will need some info from MM or x86 code to get\n"
+ " info such as number of keyIDs, etc. In fact I think number of keyIDs\n"
+ "is  the only info you need (0 keyIDs means MKTME is disabled).\n"
+ "\n"
+ "2) You need to provide some APIs to munipulate key reference count.\n"
+ "Those functions can be declared in mktme-type.h, and implemented in\n"
+ "mktme_keys.c. I think this is more reasonable, as logically reference\n"
+ "count is part of MKTME key service.\n"
+ "\n"
+ "I don't think you need to do anything else in MKTME key type?\n"
+ "\n"
+ "I think you can even start upstreaming MKTME key type now w/o Kirill's\n"
+ "core-MKTME support, since 1) adding MKTME key type doesn't do any harm\n"
+ "w/o kirill's core-MKTME code; 2) logically MKTME key type has no true\n"
+ "dependency on core-MKTME code.\n"
+ "\n"
+ "So IMHO, a better structure should be:\n"
+ "\n"
+ "1) Current upstream code (maybe with some early detction code change,\n"
+ "ie, to disable MKTME for some SW reason, but I am not sure whether this\n"
+ "is truely needed, since when MKTME key type gets initialized, that part\n"
+ "should been done already).\n"
+ "2) MKTME key type\n"
+ "3) Kirill's core-MKTME\n"
+ "4) new syscall\n"
+ "\n"
+ "And I think CONFIG_MKTME_KEYS doesn't really need to depend on\n"
+ "CONFIG_INTEL_MKTME at this point, although we can add such if needed\n"
+ "when kirill's core-MKTME code gets upstreamed.\n"
+ "\n"
+ "Thanks,\n"
+ "-Kai\n"
+ "> \n"
+ "> Suggestions welcome,\n"
+ "> Alison\n"
+ "> \n"
+ "> > And since encrypt_mprotect() is a new syscall, you may need to add\n"
+ "> > more lists for the review, ie, linux-api, and maybe linux-kernel as\n"
+ "> > well.\n"
+ "> \n"
+ "> Got it. Will include theses in v1.\n"
+ "> \n"
+ "> > \n"
+ "> > Thanks,\n"
+ "> > -Kai\n"
+ "> > \n"
+ "> > > \n"
+ "> > > This patchset is built upon Kirill Shutemov's patchset for the\n"
+ "> > > core MKTME\n"
+ "> > > support. You can find that here:\n"
+ "> > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git\n"
+ "> > > mktme/wip\n"
+ "> > > \n"
+ "> > > \n"
+ "> > > Alison Schofield (12):\n"
+ "> > >   docs/x86: Document the Multi-Key Total Memory Encryption API\n"
+ "> > >   mm: Generalize the mprotect implementation to support\n"
+ "> > > extensions\n"
+ "> > >   syscall/x86: Wire up a new system call for memory encryption\n"
+ "> > > keys\n"
+ "> > >   x86/mm: Add helper functions to manage memory encryption keys\n"
+ "> > >   x86/mm: Add a helper function to set keyid bits in encrypted\n"
+ "> > > VMA's\n"
+ "> > >   mm: Add the encrypt_mprotect() system call\n"
+ "> > >   x86/mm: Add helper functions to track encrypted VMA's\n"
+ "> > >   mm: Track VMA's in use for each memory encryption keyid\n"
+ "> > >   mm: Restrict memory encryption to anonymous VMA's\n"
+ "> > >   x86/pconfig: Program memory encryption keys on a system-wide\n"
+ "> > > basis\n"
+ "> > >   keys/mktme: Add a new key service type for memory encryption\n"
+ "> > > keys\n"
+ "> > >   keys/mktme: Do not revoke in use memory encryption keys\n"
+ "> > > \n"
+ "> > >  Documentation/x86/mktme-keys.txt       | 153 ++++++++++++++++\n"
+ "> > >  arch/x86/Kconfig                       |   1 +\n"
+ "> > >  arch/x86/entry/syscalls/syscall_32.tbl |   1 +\n"
+ "> > >  arch/x86/entry/syscalls/syscall_64.tbl |   1 +\n"
+ "> > >  arch/x86/include/asm/intel_pconfig.h   |  42 ++++-\n"
+ "> > >  arch/x86/include/asm/mktme.h           |  21 +++\n"
+ "> > >  arch/x86/mm/mktme.c                    | 141 ++++++++++++++\n"
+ "> > >  fs/exec.c                              |   4 +-\n"
+ "> > >  include/keys/mktme-type.h              |  28 +++\n"
+ "> > >  include/linux/key.h                    |   2 +\n"
+ "> > >  include/linux/mm.h                     |   9 +-\n"
+ "> > >  include/linux/syscalls.h               |   2 +\n"
+ "> > >  include/uapi/asm-generic/unistd.h      |   4 +-\n"
+ "> > >  kernel/fork.c                          |   2 +\n"
+ "> > >  kernel/sys_ni.c                        |   2 +\n"
+ "> > >  mm/mmap.c                              |  12 ++\n"
+ "> > >  mm/mprotect.c                          |  93 +++++++++-\n"
+ "> > >  mm/nommu.c                             |   4 +\n"
+ "> > >  security/keys/Kconfig                  |  11 ++\n"
+ "> > >  security/keys/Makefile                 |   1 +\n"
+ "> > >  security/keys/internal.h               |   6 +\n"
+ "> > >  security/keys/keyctl.c                 |   7 +\n"
+ "> > >  security/keys/mktme_keys.c             | 325\n"
+ "> > > +++++++++++++++++++++++++++++++++\n"
+ "> > >  23 files changed, 855 insertions(+), 17 deletions(-)  create\n"
+ "> > > mode 100644\n"
+ "> > > Documentation/x86/mktme-keys.txt  create mode 100644\n"
+ "> > > include/keys/mktme-\n"
+ "> > > type.h  create mode 100644 security/keys/mktme_keys.c\n"
+ "> > > \n"
+ "> > > --\n"
+ > > > 2.14.1
 
-15f39306757d29823a45de7fd61c1b6361a20ea2166850417e2e33a1da3cf2a0
+02fcb3fcc6cbeb8200c0ef7eb32641e393cdef080ca869c466681311024acc0c

diff --git a/a/1.txt b/N2/1.txt
index 49f4eac..701a9f9 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -1,156 +1,223 @@
-T24gTW9uLCAyMDE4LTA5LTEwIGF0IDEyOjEwIC0wNzAwLCBBbGlzb24gU2Nob2ZpZWxkIHdyb3Rl
-Og0KPiBPbiBTdW4sIFNlcCAwOSwgMjAxOCBhdCAwNjoxMDoxOVBNIC0wNzAwLCBIdWFuZywgS2Fp
-IHdyb3RlOg0KPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZy
-b206IGtleXJpbmdzLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmtleXJpbmdzLQ0KPiA+
-ID4gb3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgQWxpc29uIFNjaG9maWVsZA0K
-PiA+ID4gU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciA4LCAyMDE4IDEwOjIzIEFNDQo+ID4gPiBU
-bzogZGhvd2VsbHNAcmVkaGF0LmNvbTsgdGdseEBsaW51dHJvbml4LmRlDQo+ID4gPiBDYzogSHVh
-bmcsIEthaSA8a2FpLmh1YW5nQGludGVsLmNvbT47IE5ha2FqaW1hLCBKdW4NCj4gPiA+IDxqdW4u
-bmFrYWppbWFAaW50ZWwuY29tPjsgU2h1dGVtb3YsIEtpcmlsbCA8a2lyaWxsLnNodXRlbW92QGlu
-dGVsDQo+ID4gPiAuY29tPjsNCj4gPiA+IEhhbnNlbiwgRGF2ZSA8ZGF2ZS5oYW5zZW5AaW50ZWwu
-Y29tPjsgU2Fra2luZW4sIEphcmtrbw0KPiA+ID4gPGphcmtrby5zYWtraW5lbkBpbnRlbC5jb20+
-OyBqbW9ycmlzQG5hbWVpLm9yZzsga2V5cmluZ3NAdmdlci5rZXINCj4gPiA+IG5lbC5vcmc7DQo+
-ID4gPiBsaW51eC1zZWN1cml0eS1tb2R1bGVAdmdlci5rZXJuZWwub3JnOyBtaW5nb0ByZWRoYXQu
-Y29tOyBocGFAenl0bw0KPiA+ID4gci5jb207DQo+ID4gPiB4ODZAa2VybmVsLm9yZzsgbGludXgt
-bW1Aa3ZhY2sub3JnDQo+ID4gPiBTdWJqZWN0OiBbUkZDIDAwLzEyXSBNdWx0aS1LZXkgVG90YWwg
-TWVtb3J5IEVuY3J5cHRpb24gQVBJDQo+ID4gPiAoTUtUTUUpDQo+ID4gPiANCj4gPiA+IFNlZWtp
-bmcgY29tbWVudHMgb24gdGhlIEFQSXMgc3VwcG9ydGluZyBNS1RNRSBvbiBmdXR1cmUgSW50ZWwN
-Cj4gPiA+IHBsYXRmb3Jtcy4NCj4gPiA+IA0KPiA+ID4gTUtUTUUgKE11bHRpLUtleSBUb3RhbCBN
-ZW1vcnkgRW5jcnlwdGlvbikgaXMgYSB0ZWNobm9sb2d5DQo+ID4gPiBzdXBwb3J0aW5nDQo+ID4g
-PiBtZW1vcnkgZW5jcnlwdGlvbiBvbiB1cGNvbWluZyBJbnRlbCBwbGF0Zm9ybXMuIFdoZXJlYXMg
-VE1FIGFsbG93cw0KPiA+ID4gZW5jcnlwdGlvbiBvZiB0aGUgZW50aXJlIHN5c3RlbSBtZW1vcnkg
-dXNpbmcgYSBzaW5nbGUga2V5LCBNS1RNRQ0KPiA+ID4gYWxsb3dzDQo+ID4gPiBtdWxpdHBsZSBl
-bmNyeXB0aW9uIGRvbWFpbnMsIGVhY2ggaGF2aW5nIHRoZWlyIG93biBrZXkuIFdoaWxlIHRoZQ0K
-PiA+ID4gbWFpbiB1c2UNCj4gPiA+IGNhc2UgZm9yIHRoZSBmZWF0dXJlIGlzIHZpcnR1YWwgbWFj
-aGluZSBpc29sYXRpb24sIHRoZSBBUEkgbmVlZHMNCj4gPiA+IHRoZSBmbGV4aWJpbGl0eSB0bw0K
-PiA+ID4gd29yayBmb3IgYSB3aWRlIHJhbmdlIG9mIHVzZSBjYXNlcy4NCj4gPiA+IA0KPiA+ID4g
-VGhpcyBSRkMgcHJlc2VudHMgdGhlIDIgQVBJIGFkZGl0aW9ucyB0aGF0IGVuYWJsZSB1c2Vyc3Bh
-Y2UgdG86DQo+ID4gPiAgMSkgQ3JlYXRlIEVuY3J5cHRpb24gS2V5czogS2VybmVsIEtleSBTZXJ2
-aWNlIHR5cGUgIm1rdG1lIg0KPiA+ID4gIDIpIFVzZSB0aGUgRW5jcnlwdGlvbiBLZXlzOiBzeXN0
-ZW0gY2FsbCBlbmNyeXB0X21wcm90ZWN0KCkNCj4gPiA+IA0KPiA+ID4gSW4gb3JkZXIgdG8gc2hh
-cmUgYmV0d2VlbjogdGhlIEtlcm5lbCBLZXkgU2VydmljZSwgdGhlIG5ldyBzeXN0ZW0NCj4gPiA+
-IGNhbGwsIGFuZCB0aGUNCj4gPiA+IGV4aXN0aW5nIG1tIGNvZGUsIGhlbHBlciBmdW5jdGlvbnMg
-d2VyZSBjcmVhdGVkIGluIGFyY2gveDg2L21rdG1lDQo+ID4gDQo+ID4gSU1ITywgd2UgY2FuIHNl
-cGFyYXRlIHRoaXMgc2VyaWVzIGludG8gMiBwYXJ0cywgYXMgeW91IGRpZCBhYm92ZSwNCj4gPiBh
-bmQgc2VuZCBvdXQgdGhlbSBzZXBhcmF0ZWx5LiBUaGUgcmVhc29uIGlzLCBpbiBnZW5lcmFsIEkg
-dGhpbmsNCj4gPiBhZGRpbmcgbmV3IE1LVE1FIHR5cGUgdG8ga2V5IHJldGVudGlvbiBzZXJ2aWNl
-cyBpcyBub3QgdGhhdCByZWxhdGVkDQo+ID4gdG8gbWVtb3J5IG1hbmFnZW1lbnQgY29kZSwgbmFt
-ZWx5IHRoZSBlbmNyeXB0X21wcm90ZWN0KCkgQVBJIHBhcnQuDQo+ID4gDQo+ID4gU28gaWYgd2Ug
-c3BsaXQgdGhlIHR3byBwYXJ0cyBhbmQgc2VuZCB0aGVtIG91dCBzZXBhcmF0ZWx5LCB0aGUNCj4g
-PiBmaXJzdCBwYXJ0IGNhbiBiZSByZXZpZXdlZCBieSBrZXlyaW5nIGFuZCBzZWN1cml0eSBndXlz
-LCB3aXRob3V0DQo+ID4gaW52b2x2aW5nIG1tIGd1eXMsIGFuZCB0aGUgZW5jcnlwdF9tcHJvdGVj
-dCgpIHBhcnQgY2FuIGJlIG1vcmUNCj4gPiByZXZpZXdlZCBtb3JlIGJ5IG1tIGd1eXMuIA0KPiA+
-IA0KPiANCj4gS2FpLA0KPiANCj4gVGhhdCB3YXMgdGhlIGRpcmVjdGlvbiBJIGhhZCBpbiBtaW5k
-IGF0IHRoZSBvbnNldDogdGhlIE1LVE1FIGtleQ0KPiBzZXJ2aWNlDQo+IHdvdWxkIGJlIG9uZSBw
-YXRjaChzZXQpIGFuZCB0aGUgTUtUTUUgZW5jcnlwdF9tcHJvdGVjdCgpIHN5c3RlbSBjYWxsDQo+
-IHdvdWxkDQo+IGJlIGRlbGl2ZXJlZCBpbiBhbm90aGVyIHBhdGNoKHNldCkuDQo+IA0KPiBUaGF0
-IHNlcGFyYXRpb24gZmFsbHMgYXBhcnQgd2hlbiB0aGUgc2hhcmVkIHN0cnVjdHVyZXMgYW5kIGZ1
-bmN0aW9ucw0KPiBhcmUNCj4gaW50cm9kdWNlZC4gVGhhdCAnbWt0bWVfbWFwJyAobWFwcyB1c2Vy
-c3BhY2Uga2V5cyB0byBoYXJkd2FyZSBrZXlpZA0KPiBzbG90cyksDQo+IGFuZCB0aGUgJ2VuY3J5
-cHRfY291bnQnIGFycmF5IChjb3VudHMgdm1hJ3Mgb3V0c3RhbmRpbmcgZm9yIGVhY2gga2V5KQ0K
-PiBuZWVkDQo+IHRvIGJlIHNoYXJlZCBieSBib3RoIHBpZWNlcy4gVGhlc2UgbWt0bWUgc3BlY2lh
-bCBzaGFyZWQgc3RydWN0dXJlcw0KPiBhbmQgdGhlDQo+IGZ1bmN0aW9ucyB0aGF0IG9wZXJhdGUg
-b24gdGhlbSBhcmUgYWxsIGRlZmluZWQgaW4NCj4gYXJjaC94ODYvbW0vbWt0bWUuaCwuYy4NCj4g
-RnJvbSB0aGVyZSB0aGV5IGNhbiBiZSBzaGFyZWQgd2l0aCB0aGUgc2VjdXJpdHkva2V5cy9ta3Rt
-ZV9rZXlzLmMNCj4gDQo+IE9uY2UgSSBtYWRlIHRoYXQgc2VwYXJhdGlvbiwgSSBzdHVjayB3aXRo
-IGl0LiBUaG9zZSBzdHJ1Y3R1cmVzLCBhbmQNCj4gYW55DQo+IGZ1bmN0aW9ucyB0aGF0IG1hbmlw
-dWxhdGUgdGhvc2Ugc3RydWN0dXJlcyBsaXZlIGluDQo+IGFyY2gveDg2L21tL21rdG1lLmgsYw0K
-PiANCj4gWW91IG5vdGVkIHRoYXQgc29tZSBvZiB0aGUgZnVuY3Rpb25zIHRoYXQgb3BlcmF0ZSBv
-biB0aGUNCj4gZW5jcnlwdF9jb3VudA0KPiBtaWdodCBub3QgbmVlZCB0byBiZSBvdmVyIGluIGFy
-Y2gveDg2L21tL21rdG1lLmMgYmVjYXVzZSB0aGV5IGFyZSBub3QNCj4gdXNlZA0KPiBpbiB0aGUg
-bW0gY29kZS4gVGhhdCBpcyB0cnVlLiAgDQoNClllcyBJTU8gdGhpcyBpcyBiZXR0ZXIuDQoNCj4g
-QnV0LCB0aGVuIEknZCBiZSBzcGxpdHRpbmcgdXAgdGhlIGRlZmluaXRpb24NCj4gb2YgdGhlIHN0
-cnVjdCBhbmQgdGhlIGZ1bmNzIHRoYXQgb3BlcmF0ZSBvbiBpdC4gU28sIEkgc3R1Y2sgd2l0aA0K
-PiBrZWVwaW5nIGl0DQo+IGFsbCB0b2dldGhlciBpbiB0aGUgYXJjaCBzcGVjaWZpYyBta3RtZSBm
-aWxlcy4NCg0KRGVmaW5pdGlvbiBjYW4gYWxzbyBiZSBpbiBpbmNsdWRlL2tleXMvbWt0bWUtdHlw
-ZS5oLCByaWdodD8NCg0KPiANCj4gSGF2aW5nIHNhaWQgYWxsIHRoZSBhYm92ZSwgSSBkbyB3ZWxj
-b21lIG90aGVyIGlkZWFzIG9uIGhvdyB0byBiZXR0ZXINCj4gb3JnYW5pemUNCj4gdGhlIGNvZGUu
-IA0KPiANCj4gQmFjayB0byB5b3VyIHJlcXVlc3QtIHRvIHNwbGl0IGl0IGludG8gc21hbGxlciBw
-YXRjaHNldHMgbWlnaHQgbG9vaw0KPiBzb21ldGhpbmcNCj4gbGlrZToNCj4gMSkgdGhlIE1LVE1F
-IEFQSSBoZWxwZXJzDQoNCkV4YWN0bHkgd2hhdCBoZWxwZXJzPw0KDQo+IDIpIHRoZSBNS1RNRSBL
-ZXkgU2VydmljZQ0KPiAzKSB0aGUgTUtUTUUgc3lzY2FsbCBlbmNyeXB0X21wcm90ZWN0KCkNCj4g
-DQo+IEknbSBub3QgY2xlYXIgdGhhdCB3b3VsZCBtYWtlIGFueW9uZXMgcmV2aWV3IGxpZmUgZWFz
-aWVyLCB0aGFuDQo+IHBpY2tpbmcNCj4gdGhlIHNhbWUgcGllY2VzIG91dCBvZiB0aGUgZ3JlYXRl
-ciBwYXRjaHNldC4NCg0KV2VsbCwgdGhlIHJlYXNvbiBJIHN1Z2dlc3RlZCB3ZSBzaG91bGQgc3Bs
-aXQga2V5IHJldGVudGlvbiBzZXJ2aWNlcw0KZnJvbSBvdGhlciBzdGFmZiBhbmQgZ2V0IGl0IHJl
-dmlld2VkIGZpcnN0IGlzIEkgdGhpbmsgdGhlDQpmdW5jdGlvbmFsaXRpZXMgb2YgTUtUTUUga2V5
-IHR5cGUgaGFzIG5vdGhpbmcgdG8gZG8gdy8gTU0gY29kZS4gSU1ITw0Kd2hhdCBNS1RNRSBrZXkg
-dHlwZSBzaG91bGQgcHJvdmlkZSBpbmNsdWRlczoNCg0KMSkgU3VwcG9ydCBhZGRfa2V5LCBrZXlj
-dGwgKHJldm9rZSwgZXRjKSBvYnZpb3VzbHkuIFRIaXMgYWxzbyBpbXBsaWVzDQprZXlJRCBhbGxv
-Y2F0aW9uLCBzbyB5b3Ugd2lsbCBuZWVkIHNvbWUgaW5mbyBmcm9tIE1NIG9yIHg4NiBjb2RlIHRv
-IGdldA0KIGluZm8gc3VjaCBhcyBudW1iZXIgb2Yga2V5SURzLCBldGMuIEluIGZhY3QgSSB0aGlu
-ayBudW1iZXIgb2Yga2V5SURzDQppcyAgdGhlIG9ubHkgaW5mbyB5b3UgbmVlZCAoMCBrZXlJRHMg
-bWVhbnMgTUtUTUUgaXMgZGlzYWJsZWQpLg0KDQoyKSBZb3UgbmVlZCB0byBwcm92aWRlIHNvbWUg
-QVBJcyB0byBtdW5pcHVsYXRlIGtleSByZWZlcmVuY2UgY291bnQuDQpUaG9zZSBmdW5jdGlvbnMg
-Y2FuIGJlIGRlY2xhcmVkIGluIG1rdG1lLXR5cGUuaCwgYW5kIGltcGxlbWVudGVkIGluDQpta3Rt
-ZV9rZXlzLmMuIEkgdGhpbmsgdGhpcyBpcyBtb3JlIHJlYXNvbmFibGUsIGFzIGxvZ2ljYWxseSBy
-ZWZlcmVuY2UNCmNvdW50IGlzIHBhcnQgb2YgTUtUTUUga2V5IHNlcnZpY2UuDQoNCkkgZG9uJ3Qg
-dGhpbmsgeW91IG5lZWQgdG8gZG8gYW55dGhpbmcgZWxzZSBpbiBNS1RNRSBrZXkgdHlwZT8NCg0K
-SSB0aGluayB5b3UgY2FuIGV2ZW4gc3RhcnQgdXBzdHJlYW1pbmcgTUtUTUUga2V5IHR5cGUgbm93
-IHcvbyBLaXJpbGwncw0KY29yZS1NS1RNRSBzdXBwb3J0LCBzaW5jZSAxKSBhZGRpbmcgTUtUTUUg
-a2V5IHR5cGUgZG9lc24ndCBkbyBhbnkgaGFybQ0Kdy9vIGtpcmlsbCdzIGNvcmUtTUtUTUUgY29k
-ZTsgMikgbG9naWNhbGx5IE1LVE1FIGtleSB0eXBlIGhhcyBubyB0cnVlDQpkZXBlbmRlbmN5IG9u
-IGNvcmUtTUtUTUUgY29kZS4NCg0KU28gSU1ITywgYSBiZXR0ZXIgc3RydWN0dXJlIHNob3VsZCBi
-ZToNCg0KMSkgQ3VycmVudCB1cHN0cmVhbSBjb2RlIChtYXliZSB3aXRoIHNvbWUgZWFybHkgZGV0
-Y3Rpb24gY29kZSBjaGFuZ2UsDQppZSwgdG8gZGlzYWJsZSBNS1RNRSBmb3Igc29tZSBTVyByZWFz
-b24sIGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcw0KaXMgdHJ1ZWx5IG5lZWRlZCwgc2lu
-Y2Ugd2hlbiBNS1RNRSBrZXkgdHlwZSBnZXRzIGluaXRpYWxpemVkLCB0aGF0IHBhcnQNCnNob3Vs
-ZCBiZWVuIGRvbmUgYWxyZWFkeSkuDQoyKSBNS1RNRSBrZXkgdHlwZQ0KMykgS2lyaWxsJ3MgY29y
-ZS1NS1RNRQ0KNCkgbmV3IHN5c2NhbGwNCg0KQW5kIEkgdGhpbmsgQ09ORklHX01LVE1FX0tFWVMg
-ZG9lc24ndCByZWFsbHkgbmVlZCB0byBkZXBlbmQgb24NCkNPTkZJR19JTlRFTF9NS1RNRSBhdCB0
-aGlzIHBvaW50LCBhbHRob3VnaCB3ZSBjYW4gYWRkIHN1Y2ggaWYgbmVlZGVkDQp3aGVuIGtpcmls
-bCdzIGNvcmUtTUtUTUUgY29kZSBnZXRzIHVwc3RyZWFtZWQuDQoNClRoYW5rcywNCi1LYWkNCj4g
-DQo+IFN1Z2dlc3Rpb25zIHdlbGNvbWUsDQo+IEFsaXNvbg0KPiANCj4gPiBBbmQgc2luY2UgZW5j
-cnlwdF9tcHJvdGVjdCgpIGlzIGEgbmV3IHN5c2NhbGwsIHlvdSBtYXkgbmVlZCB0byBhZGQNCj4g
-PiBtb3JlIGxpc3RzIGZvciB0aGUgcmV2aWV3LCBpZSwgbGludXgtYXBpLCBhbmQgbWF5YmUgbGlu
-dXgta2VybmVsIGFzDQo+ID4gd2VsbC4NCj4gDQo+IEdvdCBpdC4gV2lsbCBpbmNsdWRlIHRoZXNl
-cyBpbiB2MS4NCj4gDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+IC1LYWkNCj4gPiANCj4gPiA+IA0K
-PiA+ID4gVGhpcyBwYXRjaHNldCBpcyBidWlsdCB1cG9uIEtpcmlsbCBTaHV0ZW1vdidzIHBhdGNo
-c2V0IGZvciB0aGUNCj4gPiA+IGNvcmUgTUtUTUUNCj4gPiA+IHN1cHBvcnQuIFlvdSBjYW4gZmlu
-ZCB0aGF0IGhlcmU6DQo+ID4gPiBnaXQ6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tl
-cm5lbC9naXQva2FzL2xpbnV4LmdpdA0KPiA+ID4gbWt0bWUvd2lwDQo+ID4gPiANCj4gPiA+IA0K
-PiA+ID4gQWxpc29uIFNjaG9maWVsZCAoMTIpOg0KPiA+ID4gICBkb2NzL3g4NjogRG9jdW1lbnQg
-dGhlIE11bHRpLUtleSBUb3RhbCBNZW1vcnkgRW5jcnlwdGlvbiBBUEkNCj4gPiA+ICAgbW06IEdl
-bmVyYWxpemUgdGhlIG1wcm90ZWN0IGltcGxlbWVudGF0aW9uIHRvIHN1cHBvcnQNCj4gPiA+IGV4
-dGVuc2lvbnMNCj4gPiA+ICAgc3lzY2FsbC94ODY6IFdpcmUgdXAgYSBuZXcgc3lzdGVtIGNhbGwg
-Zm9yIG1lbW9yeSBlbmNyeXB0aW9uDQo+ID4gPiBrZXlzDQo+ID4gPiAgIHg4Ni9tbTogQWRkIGhl
-bHBlciBmdW5jdGlvbnMgdG8gbWFuYWdlIG1lbW9yeSBlbmNyeXB0aW9uIGtleXMNCj4gPiA+ICAg
-eDg2L21tOiBBZGQgYSBoZWxwZXIgZnVuY3Rpb24gdG8gc2V0IGtleWlkIGJpdHMgaW4gZW5jcnlw
-dGVkDQo+ID4gPiBWTUEncw0KPiA+ID4gICBtbTogQWRkIHRoZSBlbmNyeXB0X21wcm90ZWN0KCkg
-c3lzdGVtIGNhbGwNCj4gPiA+ICAgeDg2L21tOiBBZGQgaGVscGVyIGZ1bmN0aW9ucyB0byB0cmFj
-ayBlbmNyeXB0ZWQgVk1BJ3MNCj4gPiA+ICAgbW06IFRyYWNrIFZNQSdzIGluIHVzZSBmb3IgZWFj
-aCBtZW1vcnkgZW5jcnlwdGlvbiBrZXlpZA0KPiA+ID4gICBtbTogUmVzdHJpY3QgbWVtb3J5IGVu
-Y3J5cHRpb24gdG8gYW5vbnltb3VzIFZNQSdzDQo+ID4gPiAgIHg4Ni9wY29uZmlnOiBQcm9ncmFt
-IG1lbW9yeSBlbmNyeXB0aW9uIGtleXMgb24gYSBzeXN0ZW0td2lkZQ0KPiA+ID4gYmFzaXMNCj4g
-PiA+ICAga2V5cy9ta3RtZTogQWRkIGEgbmV3IGtleSBzZXJ2aWNlIHR5cGUgZm9yIG1lbW9yeSBl
-bmNyeXB0aW9uDQo+ID4gPiBrZXlzDQo+ID4gPiAgIGtleXMvbWt0bWU6IERvIG5vdCByZXZva2Ug
-aW4gdXNlIG1lbW9yeSBlbmNyeXB0aW9uIGtleXMNCj4gPiA+IA0KPiA+ID4gIERvY3VtZW50YXRp
-b24veDg2L21rdG1lLWtleXMudHh0ICAgICAgIHwgMTUzICsrKysrKysrKysrKysrKysNCj4gPiA+
-ICBhcmNoL3g4Ni9LY29uZmlnICAgICAgICAgICAgICAgICAgICAgICB8ICAgMSArDQo+ID4gPiAg
-YXJjaC94ODYvZW50cnkvc3lzY2FsbHMvc3lzY2FsbF8zMi50YmwgfCAgIDEgKw0KPiA+ID4gIGFy
-Y2gveDg2L2VudHJ5L3N5c2NhbGxzL3N5c2NhbGxfNjQudGJsIHwgICAxICsNCj4gPiA+ICBhcmNo
-L3g4Ni9pbmNsdWRlL2FzbS9pbnRlbF9wY29uZmlnLmggICB8ICA0MiArKysrLQ0KPiA+ID4gIGFy
-Y2gveDg2L2luY2x1ZGUvYXNtL21rdG1lLmggICAgICAgICAgIHwgIDIxICsrKw0KPiA+ID4gIGFy
-Y2gveDg2L21tL21rdG1lLmMgICAgICAgICAgICAgICAgICAgIHwgMTQxICsrKysrKysrKysrKysr
-DQo+ID4gPiAgZnMvZXhlYy5jICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDQgKy0N
-Cj4gPiA+ICBpbmNsdWRlL2tleXMvbWt0bWUtdHlwZS5oICAgICAgICAgICAgICB8ICAyOCArKysN
-Cj4gPiA+ICBpbmNsdWRlL2xpbnV4L2tleS5oICAgICAgICAgICAgICAgICAgICB8ICAgMiArDQo+
-ID4gPiAgaW5jbHVkZS9saW51eC9tbS5oICAgICAgICAgICAgICAgICAgICAgfCAgIDkgKy0NCj4g
-PiA+ICBpbmNsdWRlL2xpbnV4L3N5c2NhbGxzLmggICAgICAgICAgICAgICB8ICAgMiArDQo+ID4g
-PiAgaW5jbHVkZS91YXBpL2FzbS1nZW5lcmljL3VuaXN0ZC5oICAgICAgfCAgIDQgKy0NCj4gPiA+
-ICBrZXJuZWwvZm9yay5jICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMiArDQo+ID4gPiAg
-a2VybmVsL3N5c19uaS5jICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDIgKw0KPiA+ID4gIG1t
-L21tYXAuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDEyICsrDQo+ID4gPiAgbW0v
-bXByb3RlY3QuYyAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgOTMgKysrKysrKysrLQ0KPiA+
-ID4gIG1tL25vbW11LmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICA0ICsNCj4gPiA+
-ICBzZWN1cml0eS9rZXlzL0tjb25maWcgICAgICAgICAgICAgICAgICB8ICAxMSArKw0KPiA+ID4g
-IHNlY3VyaXR5L2tleXMvTWFrZWZpbGUgICAgICAgICAgICAgICAgIHwgICAxICsNCj4gPiA+ICBz
-ZWN1cml0eS9rZXlzL2ludGVybmFsLmggICAgICAgICAgICAgICB8ICAgNiArDQo+ID4gPiAgc2Vj
-dXJpdHkva2V5cy9rZXljdGwuYyAgICAgICAgICAgICAgICAgfCAgIDcgKw0KPiA+ID4gIHNlY3Vy
-aXR5L2tleXMvbWt0bWVfa2V5cy5jICAgICAgICAgICAgIHwgMzI1DQo+ID4gPiArKysrKysrKysr
-KysrKysrKysrKysrKysrKysrKysrKysNCj4gPiA+ICAyMyBmaWxlcyBjaGFuZ2VkLCA4NTUgaW5z
-ZXJ0aW9ucygrKSwgMTcgZGVsZXRpb25zKC0pICBjcmVhdGUNCj4gPiA+IG1vZGUgMTAwNjQ0DQo+
-ID4gPiBEb2N1bWVudGF0aW9uL3g4Ni9ta3RtZS1rZXlzLnR4dCAgY3JlYXRlIG1vZGUgMTAwNjQ0
-DQo+ID4gPiBpbmNsdWRlL2tleXMvbWt0bWUtDQo+ID4gPiB0eXBlLmggIGNyZWF0ZSBtb2RlIDEw
-MDY0NCBzZWN1cml0eS9rZXlzL21rdG1lX2tleXMuYw0KPiA+ID4gDQo+ID4gPiAtLQ0KPiA+ID4g
-Mi4xNC4x
+On Mon, 2018-09-10 at 12:10 -0700, Alison Schofield wrote:
+> On Sun, Sep 09, 2018 at 06:10:19PM -0700, Huang, Kai wrote:
+> > 
+> > > -----Original Message-----
+> > > From: keyrings-owner@vger.kernel.org [mailto:keyrings-
+> > > owner@vger.kernel.org] On Behalf Of Alison Schofield
+> > > Sent: Saturday, September 8, 2018 10:23 AM
+> > > To: dhowells@redhat.com; tglx@linutronix.de
+> > > Cc: Huang, Kai <kai.huang@intel.com>; Nakajima, Jun
+> > > <jun.nakajima@intel.com>; Shutemov, Kirill <kirill.shutemov@intel
+> > > .com>;
+> > > Hansen, Dave <dave.hansen@intel.com>; Sakkinen, Jarkko
+> > > <jarkko.sakkinen@intel.com>; jmorris@namei.org; keyrings@vger.ker
+> > > nel.org;
+> > > linux-security-module@vger.kernel.org; mingo@redhat.com; hpa@zyto
+> > > r.com;
+> > > x86@kernel.org; linux-mm@kvack.org
+> > > Subject: [RFC 00/12] Multi-Key Total Memory Encryption API
+> > > (MKTME)
+> > > 
+> > > Seeking comments on the APIs supporting MKTME on future Intel
+> > > platforms.
+> > > 
+> > > MKTME (Multi-Key Total Memory Encryption) is a technology
+> > > supporting
+> > > memory encryption on upcoming Intel platforms. Whereas TME allows
+> > > encryption of the entire system memory using a single key, MKTME
+> > > allows
+> > > mulitple encryption domains, each having their own key. While the
+> > > main use
+> > > case for the feature is virtual machine isolation, the API needs
+> > > the flexibility to
+> > > work for a wide range of use cases.
+> > > 
+> > > This RFC presents the 2 API additions that enable userspace to:
+> > >  1) Create Encryption Keys: Kernel Key Service type "mktme"
+> > >  2) Use the Encryption Keys: system call encrypt_mprotect()
+> > > 
+> > > In order to share between: the Kernel Key Service, the new system
+> > > call, and the
+> > > existing mm code, helper functions were created in arch/x86/mktme
+> > 
+> > IMHO, we can separate this series into 2 parts, as you did above,
+> > and send out them separately. The reason is, in general I think
+> > adding new MKTME type to key retention services is not that related
+> > to memory management code, namely the encrypt_mprotect() API part.
+> > 
+> > So if we split the two parts and send them out separately, the
+> > first part can be reviewed by keyring and security guys, without
+> > involving mm guys, and the encrypt_mprotect() part can be more
+> > reviewed more by mm guys. 
+> > 
+> 
+> Kai,
+> 
+> That was the direction I had in mind at the onset: the MKTME key
+> service
+> would be one patch(set) and the MKTME encrypt_mprotect() system call
+> would
+> be delivered in another patch(set).
+> 
+> That separation falls apart when the shared structures and functions
+> are
+> introduced. That 'mktme_map' (maps userspace keys to hardware keyid
+> slots),
+> and the 'encrypt_count' array (counts vma's outstanding for each key)
+> need
+> to be shared by both pieces. These mktme special shared structures
+> and the
+> functions that operate on them are all defined in
+> arch/x86/mm/mktme.h,.c.
+> From there they can be shared with the security/keys/mktme_keys.c
+> 
+> Once I made that separation, I stuck with it. Those structures, and
+> any
+> functions that manipulate those structures live in
+> arch/x86/mm/mktme.h,c
+> 
+> You noted that some of the functions that operate on the
+> encrypt_count
+> might not need to be over in arch/x86/mm/mktme.c because they are not
+> used
+> in the mm code. That is true.  
+
+Yes IMO this is better.
+
+> But, then I'd be splitting up the definition
+> of the struct and the funcs that operate on it. So, I stuck with
+> keeping it
+> all together in the arch specific mktme files.
+
+Definition can also be in include/keys/mktme-type.h, right?
+
+> 
+> Having said all the above, I do welcome other ideas on how to better
+> organize
+> the code. 
+> 
+> Back to your request- to split it into smaller patchsets might look
+> something
+> like:
+> 1) the MKTME API helpers
+
+Exactly what helpers?
+
+> 2) the MKTME Key Service
+> 3) the MKTME syscall encrypt_mprotect()
+> 
+> I'm not clear that would make anyones review life easier, than
+> picking
+> the same pieces out of the greater patchset.
+
+Well, the reason I suggested we should split key retention services
+from other staff and get it reviewed first is I think the
+functionalities of MKTME key type has nothing to do w/ MM code. IMHO
+what MKTME key type should provide includes:
+
+1) Support add_key, keyctl (revoke, etc) obviously. THis also implies
+keyID allocation, so you will need some info from MM or x86 code to get
+ info such as number of keyIDs, etc. In fact I think number of keyIDs
+is  the only info you need (0 keyIDs means MKTME is disabled).
+
+2) You need to provide some APIs to munipulate key reference count.
+Those functions can be declared in mktme-type.h, and implemented in
+mktme_keys.c. I think this is more reasonable, as logically reference
+count is part of MKTME key service.
+
+I don't think you need to do anything else in MKTME key type?
+
+I think you can even start upstreaming MKTME key type now w/o Kirill's
+core-MKTME support, since 1) adding MKTME key type doesn't do any harm
+w/o kirill's core-MKTME code; 2) logically MKTME key type has no true
+dependency on core-MKTME code.
+
+So IMHO, a better structure should be:
+
+1) Current upstream code (maybe with some early detction code change,
+ie, to disable MKTME for some SW reason, but I am not sure whether this
+is truely needed, since when MKTME key type gets initialized, that part
+should been done already).
+2) MKTME key type
+3) Kirill's core-MKTME
+4) new syscall
+
+And I think CONFIG_MKTME_KEYS doesn't really need to depend on
+CONFIG_INTEL_MKTME at this point, although we can add such if needed
+when kirill's core-MKTME code gets upstreamed.
+
+Thanks,
+-Kai
+> 
+> Suggestions welcome,
+> Alison
+> 
+> > And since encrypt_mprotect() is a new syscall, you may need to add
+> > more lists for the review, ie, linux-api, and maybe linux-kernel as
+> > well.
+> 
+> Got it. Will include theses in v1.
+> 
+> > 
+> > Thanks,
+> > -Kai
+> > 
+> > > 
+> > > This patchset is built upon Kirill Shutemov's patchset for the
+> > > core MKTME
+> > > support. You can find that here:
+> > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git
+> > > mktme/wip
+> > > 
+> > > 
+> > > Alison Schofield (12):
+> > >   docs/x86: Document the Multi-Key Total Memory Encryption API
+> > >   mm: Generalize the mprotect implementation to support
+> > > extensions
+> > >   syscall/x86: Wire up a new system call for memory encryption
+> > > keys
+> > >   x86/mm: Add helper functions to manage memory encryption keys
+> > >   x86/mm: Add a helper function to set keyid bits in encrypted
+> > > VMA's
+> > >   mm: Add the encrypt_mprotect() system call
+> > >   x86/mm: Add helper functions to track encrypted VMA's
+> > >   mm: Track VMA's in use for each memory encryption keyid
+> > >   mm: Restrict memory encryption to anonymous VMA's
+> > >   x86/pconfig: Program memory encryption keys on a system-wide
+> > > basis
+> > >   keys/mktme: Add a new key service type for memory encryption
+> > > keys
+> > >   keys/mktme: Do not revoke in use memory encryption keys
+> > > 
+> > >  Documentation/x86/mktme-keys.txt       | 153 ++++++++++++++++
+> > >  arch/x86/Kconfig                       |   1 +
+> > >  arch/x86/entry/syscalls/syscall_32.tbl |   1 +
+> > >  arch/x86/entry/syscalls/syscall_64.tbl |   1 +
+> > >  arch/x86/include/asm/intel_pconfig.h   |  42 ++++-
+> > >  arch/x86/include/asm/mktme.h           |  21 +++
+> > >  arch/x86/mm/mktme.c                    | 141 ++++++++++++++
+> > >  fs/exec.c                              |   4 +-
+> > >  include/keys/mktme-type.h              |  28 +++
+> > >  include/linux/key.h                    |   2 +
+> > >  include/linux/mm.h                     |   9 +-
+> > >  include/linux/syscalls.h               |   2 +
+> > >  include/uapi/asm-generic/unistd.h      |   4 +-
+> > >  kernel/fork.c                          |   2 +
+> > >  kernel/sys_ni.c                        |   2 +
+> > >  mm/mmap.c                              |  12 ++
+> > >  mm/mprotect.c                          |  93 +++++++++-
+> > >  mm/nommu.c                             |   4 +
+> > >  security/keys/Kconfig                  |  11 ++
+> > >  security/keys/Makefile                 |   1 +
+> > >  security/keys/internal.h               |   6 +
+> > >  security/keys/keyctl.c                 |   7 +
+> > >  security/keys/mktme_keys.c             | 325
+> > > +++++++++++++++++++++++++++++++++
+> > >  23 files changed, 855 insertions(+), 17 deletions(-)  create
+> > > mode 100644
+> > > Documentation/x86/mktme-keys.txt  create mode 100644
+> > > include/keys/mktme-
+> > > type.h  create mode 100644 security/keys/mktme_keys.c
+> > > 
+> > > --
+> > > 2.14.1
diff --git a/a/content_digest b/N2/content_digest
index e520873..da083ac 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -25,161 +25,228 @@
  " Jun <jun.nakajima@intel.com>\0"
  "\00:1\0"
  "b\0"
- "T24gTW9uLCAyMDE4LTA5LTEwIGF0IDEyOjEwIC0wNzAwLCBBbGlzb24gU2Nob2ZpZWxkIHdyb3Rl\n"
- "Og0KPiBPbiBTdW4sIFNlcCAwOSwgMjAxOCBhdCAwNjoxMDoxOVBNIC0wNzAwLCBIdWFuZywgS2Fp\n"
- "IHdyb3RlOg0KPiA+IA0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZy\n"
- "b206IGtleXJpbmdzLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmtleXJpbmdzLQ0KPiA+\n"
- "ID4gb3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgQWxpc29uIFNjaG9maWVsZA0K\n"
- "PiA+ID4gU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciA4LCAyMDE4IDEwOjIzIEFNDQo+ID4gPiBU\n"
- "bzogZGhvd2VsbHNAcmVkaGF0LmNvbTsgdGdseEBsaW51dHJvbml4LmRlDQo+ID4gPiBDYzogSHVh\n"
- "bmcsIEthaSA8a2FpLmh1YW5nQGludGVsLmNvbT47IE5ha2FqaW1hLCBKdW4NCj4gPiA+IDxqdW4u\n"
- "bmFrYWppbWFAaW50ZWwuY29tPjsgU2h1dGVtb3YsIEtpcmlsbCA8a2lyaWxsLnNodXRlbW92QGlu\n"
- "dGVsDQo+ID4gPiAuY29tPjsNCj4gPiA+IEhhbnNlbiwgRGF2ZSA8ZGF2ZS5oYW5zZW5AaW50ZWwu\n"
- "Y29tPjsgU2Fra2luZW4sIEphcmtrbw0KPiA+ID4gPGphcmtrby5zYWtraW5lbkBpbnRlbC5jb20+\n"
- "OyBqbW9ycmlzQG5hbWVpLm9yZzsga2V5cmluZ3NAdmdlci5rZXINCj4gPiA+IG5lbC5vcmc7DQo+\n"
- "ID4gPiBsaW51eC1zZWN1cml0eS1tb2R1bGVAdmdlci5rZXJuZWwub3JnOyBtaW5nb0ByZWRoYXQu\n"
- "Y29tOyBocGFAenl0bw0KPiA+ID4gci5jb207DQo+ID4gPiB4ODZAa2VybmVsLm9yZzsgbGludXgt\n"
- "bW1Aa3ZhY2sub3JnDQo+ID4gPiBTdWJqZWN0OiBbUkZDIDAwLzEyXSBNdWx0aS1LZXkgVG90YWwg\n"
- "TWVtb3J5IEVuY3J5cHRpb24gQVBJDQo+ID4gPiAoTUtUTUUpDQo+ID4gPiANCj4gPiA+IFNlZWtp\n"
- "bmcgY29tbWVudHMgb24gdGhlIEFQSXMgc3VwcG9ydGluZyBNS1RNRSBvbiBmdXR1cmUgSW50ZWwN\n"
- "Cj4gPiA+IHBsYXRmb3Jtcy4NCj4gPiA+IA0KPiA+ID4gTUtUTUUgKE11bHRpLUtleSBUb3RhbCBN\n"
- "ZW1vcnkgRW5jcnlwdGlvbikgaXMgYSB0ZWNobm9sb2d5DQo+ID4gPiBzdXBwb3J0aW5nDQo+ID4g\n"
- "PiBtZW1vcnkgZW5jcnlwdGlvbiBvbiB1cGNvbWluZyBJbnRlbCBwbGF0Zm9ybXMuIFdoZXJlYXMg\n"
- "VE1FIGFsbG93cw0KPiA+ID4gZW5jcnlwdGlvbiBvZiB0aGUgZW50aXJlIHN5c3RlbSBtZW1vcnkg\n"
- "dXNpbmcgYSBzaW5nbGUga2V5LCBNS1RNRQ0KPiA+ID4gYWxsb3dzDQo+ID4gPiBtdWxpdHBsZSBl\n"
- "bmNyeXB0aW9uIGRvbWFpbnMsIGVhY2ggaGF2aW5nIHRoZWlyIG93biBrZXkuIFdoaWxlIHRoZQ0K\n"
- "PiA+ID4gbWFpbiB1c2UNCj4gPiA+IGNhc2UgZm9yIHRoZSBmZWF0dXJlIGlzIHZpcnR1YWwgbWFj\n"
- "aGluZSBpc29sYXRpb24sIHRoZSBBUEkgbmVlZHMNCj4gPiA+IHRoZSBmbGV4aWJpbGl0eSB0bw0K\n"
- "PiA+ID4gd29yayBmb3IgYSB3aWRlIHJhbmdlIG9mIHVzZSBjYXNlcy4NCj4gPiA+IA0KPiA+ID4g\n"
- "VGhpcyBSRkMgcHJlc2VudHMgdGhlIDIgQVBJIGFkZGl0aW9ucyB0aGF0IGVuYWJsZSB1c2Vyc3Bh\n"
- "Y2UgdG86DQo+ID4gPiAgMSkgQ3JlYXRlIEVuY3J5cHRpb24gS2V5czogS2VybmVsIEtleSBTZXJ2\n"
- "aWNlIHR5cGUgIm1rdG1lIg0KPiA+ID4gIDIpIFVzZSB0aGUgRW5jcnlwdGlvbiBLZXlzOiBzeXN0\n"
- "ZW0gY2FsbCBlbmNyeXB0X21wcm90ZWN0KCkNCj4gPiA+IA0KPiA+ID4gSW4gb3JkZXIgdG8gc2hh\n"
- "cmUgYmV0d2VlbjogdGhlIEtlcm5lbCBLZXkgU2VydmljZSwgdGhlIG5ldyBzeXN0ZW0NCj4gPiA+\n"
- "IGNhbGwsIGFuZCB0aGUNCj4gPiA+IGV4aXN0aW5nIG1tIGNvZGUsIGhlbHBlciBmdW5jdGlvbnMg\n"
- "d2VyZSBjcmVhdGVkIGluIGFyY2gveDg2L21rdG1lDQo+ID4gDQo+ID4gSU1ITywgd2UgY2FuIHNl\n"
- "cGFyYXRlIHRoaXMgc2VyaWVzIGludG8gMiBwYXJ0cywgYXMgeW91IGRpZCBhYm92ZSwNCj4gPiBh\n"
- "bmQgc2VuZCBvdXQgdGhlbSBzZXBhcmF0ZWx5LiBUaGUgcmVhc29uIGlzLCBpbiBnZW5lcmFsIEkg\n"
- "dGhpbmsNCj4gPiBhZGRpbmcgbmV3IE1LVE1FIHR5cGUgdG8ga2V5IHJldGVudGlvbiBzZXJ2aWNl\n"
- "cyBpcyBub3QgdGhhdCByZWxhdGVkDQo+ID4gdG8gbWVtb3J5IG1hbmFnZW1lbnQgY29kZSwgbmFt\n"
- "ZWx5IHRoZSBlbmNyeXB0X21wcm90ZWN0KCkgQVBJIHBhcnQuDQo+ID4gDQo+ID4gU28gaWYgd2Ug\n"
- "c3BsaXQgdGhlIHR3byBwYXJ0cyBhbmQgc2VuZCB0aGVtIG91dCBzZXBhcmF0ZWx5LCB0aGUNCj4g\n"
- "PiBmaXJzdCBwYXJ0IGNhbiBiZSByZXZpZXdlZCBieSBrZXlyaW5nIGFuZCBzZWN1cml0eSBndXlz\n"
- "LCB3aXRob3V0DQo+ID4gaW52b2x2aW5nIG1tIGd1eXMsIGFuZCB0aGUgZW5jcnlwdF9tcHJvdGVj\n"
- "dCgpIHBhcnQgY2FuIGJlIG1vcmUNCj4gPiByZXZpZXdlZCBtb3JlIGJ5IG1tIGd1eXMuIA0KPiA+\n"
- "IA0KPiANCj4gS2FpLA0KPiANCj4gVGhhdCB3YXMgdGhlIGRpcmVjdGlvbiBJIGhhZCBpbiBtaW5k\n"
- "IGF0IHRoZSBvbnNldDogdGhlIE1LVE1FIGtleQ0KPiBzZXJ2aWNlDQo+IHdvdWxkIGJlIG9uZSBw\n"
- "YXRjaChzZXQpIGFuZCB0aGUgTUtUTUUgZW5jcnlwdF9tcHJvdGVjdCgpIHN5c3RlbSBjYWxsDQo+\n"
- "IHdvdWxkDQo+IGJlIGRlbGl2ZXJlZCBpbiBhbm90aGVyIHBhdGNoKHNldCkuDQo+IA0KPiBUaGF0\n"
- "IHNlcGFyYXRpb24gZmFsbHMgYXBhcnQgd2hlbiB0aGUgc2hhcmVkIHN0cnVjdHVyZXMgYW5kIGZ1\n"
- "bmN0aW9ucw0KPiBhcmUNCj4gaW50cm9kdWNlZC4gVGhhdCAnbWt0bWVfbWFwJyAobWFwcyB1c2Vy\n"
- "c3BhY2Uga2V5cyB0byBoYXJkd2FyZSBrZXlpZA0KPiBzbG90cyksDQo+IGFuZCB0aGUgJ2VuY3J5\n"
- "cHRfY291bnQnIGFycmF5IChjb3VudHMgdm1hJ3Mgb3V0c3RhbmRpbmcgZm9yIGVhY2gga2V5KQ0K\n"
- "PiBuZWVkDQo+IHRvIGJlIHNoYXJlZCBieSBib3RoIHBpZWNlcy4gVGhlc2UgbWt0bWUgc3BlY2lh\n"
- "bCBzaGFyZWQgc3RydWN0dXJlcw0KPiBhbmQgdGhlDQo+IGZ1bmN0aW9ucyB0aGF0IG9wZXJhdGUg\n"
- "b24gdGhlbSBhcmUgYWxsIGRlZmluZWQgaW4NCj4gYXJjaC94ODYvbW0vbWt0bWUuaCwuYy4NCj4g\n"
- "RnJvbSB0aGVyZSB0aGV5IGNhbiBiZSBzaGFyZWQgd2l0aCB0aGUgc2VjdXJpdHkva2V5cy9ta3Rt\n"
- "ZV9rZXlzLmMNCj4gDQo+IE9uY2UgSSBtYWRlIHRoYXQgc2VwYXJhdGlvbiwgSSBzdHVjayB3aXRo\n"
- "IGl0LiBUaG9zZSBzdHJ1Y3R1cmVzLCBhbmQNCj4gYW55DQo+IGZ1bmN0aW9ucyB0aGF0IG1hbmlw\n"
- "dWxhdGUgdGhvc2Ugc3RydWN0dXJlcyBsaXZlIGluDQo+IGFyY2gveDg2L21tL21rdG1lLmgsYw0K\n"
- "PiANCj4gWW91IG5vdGVkIHRoYXQgc29tZSBvZiB0aGUgZnVuY3Rpb25zIHRoYXQgb3BlcmF0ZSBv\n"
- "biB0aGUNCj4gZW5jcnlwdF9jb3VudA0KPiBtaWdodCBub3QgbmVlZCB0byBiZSBvdmVyIGluIGFy\n"
- "Y2gveDg2L21tL21rdG1lLmMgYmVjYXVzZSB0aGV5IGFyZSBub3QNCj4gdXNlZA0KPiBpbiB0aGUg\n"
- "bW0gY29kZS4gVGhhdCBpcyB0cnVlLiAgDQoNClllcyBJTU8gdGhpcyBpcyBiZXR0ZXIuDQoNCj4g\n"
- "QnV0LCB0aGVuIEknZCBiZSBzcGxpdHRpbmcgdXAgdGhlIGRlZmluaXRpb24NCj4gb2YgdGhlIHN0\n"
- "cnVjdCBhbmQgdGhlIGZ1bmNzIHRoYXQgb3BlcmF0ZSBvbiBpdC4gU28sIEkgc3R1Y2sgd2l0aA0K\n"
- "PiBrZWVwaW5nIGl0DQo+IGFsbCB0b2dldGhlciBpbiB0aGUgYXJjaCBzcGVjaWZpYyBta3RtZSBm\n"
- "aWxlcy4NCg0KRGVmaW5pdGlvbiBjYW4gYWxzbyBiZSBpbiBpbmNsdWRlL2tleXMvbWt0bWUtdHlw\n"
- "ZS5oLCByaWdodD8NCg0KPiANCj4gSGF2aW5nIHNhaWQgYWxsIHRoZSBhYm92ZSwgSSBkbyB3ZWxj\n"
- "b21lIG90aGVyIGlkZWFzIG9uIGhvdyB0byBiZXR0ZXINCj4gb3JnYW5pemUNCj4gdGhlIGNvZGUu\n"
- "IA0KPiANCj4gQmFjayB0byB5b3VyIHJlcXVlc3QtIHRvIHNwbGl0IGl0IGludG8gc21hbGxlciBw\n"
- "YXRjaHNldHMgbWlnaHQgbG9vaw0KPiBzb21ldGhpbmcNCj4gbGlrZToNCj4gMSkgdGhlIE1LVE1F\n"
- "IEFQSSBoZWxwZXJzDQoNCkV4YWN0bHkgd2hhdCBoZWxwZXJzPw0KDQo+IDIpIHRoZSBNS1RNRSBL\n"
- "ZXkgU2VydmljZQ0KPiAzKSB0aGUgTUtUTUUgc3lzY2FsbCBlbmNyeXB0X21wcm90ZWN0KCkNCj4g\n"
- "DQo+IEknbSBub3QgY2xlYXIgdGhhdCB3b3VsZCBtYWtlIGFueW9uZXMgcmV2aWV3IGxpZmUgZWFz\n"
- "aWVyLCB0aGFuDQo+IHBpY2tpbmcNCj4gdGhlIHNhbWUgcGllY2VzIG91dCBvZiB0aGUgZ3JlYXRl\n"
- "ciBwYXRjaHNldC4NCg0KV2VsbCwgdGhlIHJlYXNvbiBJIHN1Z2dlc3RlZCB3ZSBzaG91bGQgc3Bs\n"
- "aXQga2V5IHJldGVudGlvbiBzZXJ2aWNlcw0KZnJvbSBvdGhlciBzdGFmZiBhbmQgZ2V0IGl0IHJl\n"
- "dmlld2VkIGZpcnN0IGlzIEkgdGhpbmsgdGhlDQpmdW5jdGlvbmFsaXRpZXMgb2YgTUtUTUUga2V5\n"
- "IHR5cGUgaGFzIG5vdGhpbmcgdG8gZG8gdy8gTU0gY29kZS4gSU1ITw0Kd2hhdCBNS1RNRSBrZXkg\n"
- "dHlwZSBzaG91bGQgcHJvdmlkZSBpbmNsdWRlczoNCg0KMSkgU3VwcG9ydCBhZGRfa2V5LCBrZXlj\n"
- "dGwgKHJldm9rZSwgZXRjKSBvYnZpb3VzbHkuIFRIaXMgYWxzbyBpbXBsaWVzDQprZXlJRCBhbGxv\n"
- "Y2F0aW9uLCBzbyB5b3Ugd2lsbCBuZWVkIHNvbWUgaW5mbyBmcm9tIE1NIG9yIHg4NiBjb2RlIHRv\n"
- "IGdldA0KIGluZm8gc3VjaCBhcyBudW1iZXIgb2Yga2V5SURzLCBldGMuIEluIGZhY3QgSSB0aGlu\n"
- "ayBudW1iZXIgb2Yga2V5SURzDQppcyAgdGhlIG9ubHkgaW5mbyB5b3UgbmVlZCAoMCBrZXlJRHMg\n"
- "bWVhbnMgTUtUTUUgaXMgZGlzYWJsZWQpLg0KDQoyKSBZb3UgbmVlZCB0byBwcm92aWRlIHNvbWUg\n"
- "QVBJcyB0byBtdW5pcHVsYXRlIGtleSByZWZlcmVuY2UgY291bnQuDQpUaG9zZSBmdW5jdGlvbnMg\n"
- "Y2FuIGJlIGRlY2xhcmVkIGluIG1rdG1lLXR5cGUuaCwgYW5kIGltcGxlbWVudGVkIGluDQpta3Rt\n"
- "ZV9rZXlzLmMuIEkgdGhpbmsgdGhpcyBpcyBtb3JlIHJlYXNvbmFibGUsIGFzIGxvZ2ljYWxseSBy\n"
- "ZWZlcmVuY2UNCmNvdW50IGlzIHBhcnQgb2YgTUtUTUUga2V5IHNlcnZpY2UuDQoNCkkgZG9uJ3Qg\n"
- "dGhpbmsgeW91IG5lZWQgdG8gZG8gYW55dGhpbmcgZWxzZSBpbiBNS1RNRSBrZXkgdHlwZT8NCg0K\n"
- "SSB0aGluayB5b3UgY2FuIGV2ZW4gc3RhcnQgdXBzdHJlYW1pbmcgTUtUTUUga2V5IHR5cGUgbm93\n"
- "IHcvbyBLaXJpbGwncw0KY29yZS1NS1RNRSBzdXBwb3J0LCBzaW5jZSAxKSBhZGRpbmcgTUtUTUUg\n"
- "a2V5IHR5cGUgZG9lc24ndCBkbyBhbnkgaGFybQ0Kdy9vIGtpcmlsbCdzIGNvcmUtTUtUTUUgY29k\n"
- "ZTsgMikgbG9naWNhbGx5IE1LVE1FIGtleSB0eXBlIGhhcyBubyB0cnVlDQpkZXBlbmRlbmN5IG9u\n"
- "IGNvcmUtTUtUTUUgY29kZS4NCg0KU28gSU1ITywgYSBiZXR0ZXIgc3RydWN0dXJlIHNob3VsZCBi\n"
- "ZToNCg0KMSkgQ3VycmVudCB1cHN0cmVhbSBjb2RlIChtYXliZSB3aXRoIHNvbWUgZWFybHkgZGV0\n"
- "Y3Rpb24gY29kZSBjaGFuZ2UsDQppZSwgdG8gZGlzYWJsZSBNS1RNRSBmb3Igc29tZSBTVyByZWFz\n"
- "b24sIGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcw0KaXMgdHJ1ZWx5IG5lZWRlZCwgc2lu\n"
- "Y2Ugd2hlbiBNS1RNRSBrZXkgdHlwZSBnZXRzIGluaXRpYWxpemVkLCB0aGF0IHBhcnQNCnNob3Vs\n"
- "ZCBiZWVuIGRvbmUgYWxyZWFkeSkuDQoyKSBNS1RNRSBrZXkgdHlwZQ0KMykgS2lyaWxsJ3MgY29y\n"
- "ZS1NS1RNRQ0KNCkgbmV3IHN5c2NhbGwNCg0KQW5kIEkgdGhpbmsgQ09ORklHX01LVE1FX0tFWVMg\n"
- "ZG9lc24ndCByZWFsbHkgbmVlZCB0byBkZXBlbmQgb24NCkNPTkZJR19JTlRFTF9NS1RNRSBhdCB0\n"
- "aGlzIHBvaW50LCBhbHRob3VnaCB3ZSBjYW4gYWRkIHN1Y2ggaWYgbmVlZGVkDQp3aGVuIGtpcmls\n"
- "bCdzIGNvcmUtTUtUTUUgY29kZSBnZXRzIHVwc3RyZWFtZWQuDQoNClRoYW5rcywNCi1LYWkNCj4g\n"
- "DQo+IFN1Z2dlc3Rpb25zIHdlbGNvbWUsDQo+IEFsaXNvbg0KPiANCj4gPiBBbmQgc2luY2UgZW5j\n"
- "cnlwdF9tcHJvdGVjdCgpIGlzIGEgbmV3IHN5c2NhbGwsIHlvdSBtYXkgbmVlZCB0byBhZGQNCj4g\n"
- "PiBtb3JlIGxpc3RzIGZvciB0aGUgcmV2aWV3LCBpZSwgbGludXgtYXBpLCBhbmQgbWF5YmUgbGlu\n"
- "dXgta2VybmVsIGFzDQo+ID4gd2VsbC4NCj4gDQo+IEdvdCBpdC4gV2lsbCBpbmNsdWRlIHRoZXNl\n"
- "cyBpbiB2MS4NCj4gDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+IC1LYWkNCj4gPiANCj4gPiA+IA0K\n"
- "PiA+ID4gVGhpcyBwYXRjaHNldCBpcyBidWlsdCB1cG9uIEtpcmlsbCBTaHV0ZW1vdidzIHBhdGNo\n"
- "c2V0IGZvciB0aGUNCj4gPiA+IGNvcmUgTUtUTUUNCj4gPiA+IHN1cHBvcnQuIFlvdSBjYW4gZmlu\n"
- "ZCB0aGF0IGhlcmU6DQo+ID4gPiBnaXQ6Ly9naXQua2VybmVsLm9yZy9wdWIvc2NtL2xpbnV4L2tl\n"
- "cm5lbC9naXQva2FzL2xpbnV4LmdpdA0KPiA+ID4gbWt0bWUvd2lwDQo+ID4gPiANCj4gPiA+IA0K\n"
- "PiA+ID4gQWxpc29uIFNjaG9maWVsZCAoMTIpOg0KPiA+ID4gICBkb2NzL3g4NjogRG9jdW1lbnQg\n"
- "dGhlIE11bHRpLUtleSBUb3RhbCBNZW1vcnkgRW5jcnlwdGlvbiBBUEkNCj4gPiA+ICAgbW06IEdl\n"
- "bmVyYWxpemUgdGhlIG1wcm90ZWN0IGltcGxlbWVudGF0aW9uIHRvIHN1cHBvcnQNCj4gPiA+IGV4\n"
- "dGVuc2lvbnMNCj4gPiA+ICAgc3lzY2FsbC94ODY6IFdpcmUgdXAgYSBuZXcgc3lzdGVtIGNhbGwg\n"
- "Zm9yIG1lbW9yeSBlbmNyeXB0aW9uDQo+ID4gPiBrZXlzDQo+ID4gPiAgIHg4Ni9tbTogQWRkIGhl\n"
- "bHBlciBmdW5jdGlvbnMgdG8gbWFuYWdlIG1lbW9yeSBlbmNyeXB0aW9uIGtleXMNCj4gPiA+ICAg\n"
- "eDg2L21tOiBBZGQgYSBoZWxwZXIgZnVuY3Rpb24gdG8gc2V0IGtleWlkIGJpdHMgaW4gZW5jcnlw\n"
- "dGVkDQo+ID4gPiBWTUEncw0KPiA+ID4gICBtbTogQWRkIHRoZSBlbmNyeXB0X21wcm90ZWN0KCkg\n"
- "c3lzdGVtIGNhbGwNCj4gPiA+ICAgeDg2L21tOiBBZGQgaGVscGVyIGZ1bmN0aW9ucyB0byB0cmFj\n"
- "ayBlbmNyeXB0ZWQgVk1BJ3MNCj4gPiA+ICAgbW06IFRyYWNrIFZNQSdzIGluIHVzZSBmb3IgZWFj\n"
- "aCBtZW1vcnkgZW5jcnlwdGlvbiBrZXlpZA0KPiA+ID4gICBtbTogUmVzdHJpY3QgbWVtb3J5IGVu\n"
- "Y3J5cHRpb24gdG8gYW5vbnltb3VzIFZNQSdzDQo+ID4gPiAgIHg4Ni9wY29uZmlnOiBQcm9ncmFt\n"
- "IG1lbW9yeSBlbmNyeXB0aW9uIGtleXMgb24gYSBzeXN0ZW0td2lkZQ0KPiA+ID4gYmFzaXMNCj4g\n"
- "PiA+ICAga2V5cy9ta3RtZTogQWRkIGEgbmV3IGtleSBzZXJ2aWNlIHR5cGUgZm9yIG1lbW9yeSBl\n"
- "bmNyeXB0aW9uDQo+ID4gPiBrZXlzDQo+ID4gPiAgIGtleXMvbWt0bWU6IERvIG5vdCByZXZva2Ug\n"
- "aW4gdXNlIG1lbW9yeSBlbmNyeXB0aW9uIGtleXMNCj4gPiA+IA0KPiA+ID4gIERvY3VtZW50YXRp\n"
- "b24veDg2L21rdG1lLWtleXMudHh0ICAgICAgIHwgMTUzICsrKysrKysrKysrKysrKysNCj4gPiA+\n"
- "ICBhcmNoL3g4Ni9LY29uZmlnICAgICAgICAgICAgICAgICAgICAgICB8ICAgMSArDQo+ID4gPiAg\n"
- "YXJjaC94ODYvZW50cnkvc3lzY2FsbHMvc3lzY2FsbF8zMi50YmwgfCAgIDEgKw0KPiA+ID4gIGFy\n"
- "Y2gveDg2L2VudHJ5L3N5c2NhbGxzL3N5c2NhbGxfNjQudGJsIHwgICAxICsNCj4gPiA+ICBhcmNo\n"
- "L3g4Ni9pbmNsdWRlL2FzbS9pbnRlbF9wY29uZmlnLmggICB8ICA0MiArKysrLQ0KPiA+ID4gIGFy\n"
- "Y2gveDg2L2luY2x1ZGUvYXNtL21rdG1lLmggICAgICAgICAgIHwgIDIxICsrKw0KPiA+ID4gIGFy\n"
- "Y2gveDg2L21tL21rdG1lLmMgICAgICAgICAgICAgICAgICAgIHwgMTQxICsrKysrKysrKysrKysr\n"
- "DQo+ID4gPiAgZnMvZXhlYy5jICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDQgKy0N\n"
- "Cj4gPiA+ICBpbmNsdWRlL2tleXMvbWt0bWUtdHlwZS5oICAgICAgICAgICAgICB8ICAyOCArKysN\n"
- "Cj4gPiA+ICBpbmNsdWRlL2xpbnV4L2tleS5oICAgICAgICAgICAgICAgICAgICB8ICAgMiArDQo+\n"
- "ID4gPiAgaW5jbHVkZS9saW51eC9tbS5oICAgICAgICAgICAgICAgICAgICAgfCAgIDkgKy0NCj4g\n"
- "PiA+ICBpbmNsdWRlL2xpbnV4L3N5c2NhbGxzLmggICAgICAgICAgICAgICB8ICAgMiArDQo+ID4g\n"
- "PiAgaW5jbHVkZS91YXBpL2FzbS1nZW5lcmljL3VuaXN0ZC5oICAgICAgfCAgIDQgKy0NCj4gPiA+\n"
- "ICBrZXJuZWwvZm9yay5jICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMiArDQo+ID4gPiAg\n"
- "a2VybmVsL3N5c19uaS5jICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDIgKw0KPiA+ID4gIG1t\n"
- "L21tYXAuYyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDEyICsrDQo+ID4gPiAgbW0v\n"
- "bXByb3RlY3QuYyAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgOTMgKysrKysrKysrLQ0KPiA+\n"
- "ID4gIG1tL25vbW11LmMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICA0ICsNCj4gPiA+\n"
- "ICBzZWN1cml0eS9rZXlzL0tjb25maWcgICAgICAgICAgICAgICAgICB8ICAxMSArKw0KPiA+ID4g\n"
- "IHNlY3VyaXR5L2tleXMvTWFrZWZpbGUgICAgICAgICAgICAgICAgIHwgICAxICsNCj4gPiA+ICBz\n"
- "ZWN1cml0eS9rZXlzL2ludGVybmFsLmggICAgICAgICAgICAgICB8ICAgNiArDQo+ID4gPiAgc2Vj\n"
- "dXJpdHkva2V5cy9rZXljdGwuYyAgICAgICAgICAgICAgICAgfCAgIDcgKw0KPiA+ID4gIHNlY3Vy\n"
- "aXR5L2tleXMvbWt0bWVfa2V5cy5jICAgICAgICAgICAgIHwgMzI1DQo+ID4gPiArKysrKysrKysr\n"
- "KysrKysrKysrKysrKysrKysrKysrKysNCj4gPiA+ICAyMyBmaWxlcyBjaGFuZ2VkLCA4NTUgaW5z\n"
- "ZXJ0aW9ucygrKSwgMTcgZGVsZXRpb25zKC0pICBjcmVhdGUNCj4gPiA+IG1vZGUgMTAwNjQ0DQo+\n"
- "ID4gPiBEb2N1bWVudGF0aW9uL3g4Ni9ta3RtZS1rZXlzLnR4dCAgY3JlYXRlIG1vZGUgMTAwNjQ0\n"
- "DQo+ID4gPiBpbmNsdWRlL2tleXMvbWt0bWUtDQo+ID4gPiB0eXBlLmggIGNyZWF0ZSBtb2RlIDEw\n"
- "MDY0NCBzZWN1cml0eS9rZXlzL21rdG1lX2tleXMuYw0KPiA+ID4gDQo+ID4gPiAtLQ0KPiA+ID4g\n"
- Mi4xNC4x
+ "On Mon, 2018-09-10 at 12:10 -0700, Alison Schofield wrote:\n"
+ "> On Sun, Sep 09, 2018 at 06:10:19PM -0700, Huang, Kai wrote:\n"
+ "> > \n"
+ "> > > -----Original Message-----\n"
+ "> > > From: keyrings-owner@vger.kernel.org [mailto:keyrings-\n"
+ "> > > owner@vger.kernel.org] On Behalf Of Alison Schofield\n"
+ "> > > Sent: Saturday, September 8, 2018 10:23 AM\n"
+ "> > > To: dhowells@redhat.com; tglx@linutronix.de\n"
+ "> > > Cc: Huang, Kai <kai.huang@intel.com>; Nakajima, Jun\n"
+ "> > > <jun.nakajima@intel.com>; Shutemov, Kirill <kirill.shutemov@intel\n"
+ "> > > .com>;\n"
+ "> > > Hansen, Dave <dave.hansen@intel.com>; Sakkinen, Jarkko\n"
+ "> > > <jarkko.sakkinen@intel.com>; jmorris@namei.org; keyrings@vger.ker\n"
+ "> > > nel.org;\n"
+ "> > > linux-security-module@vger.kernel.org; mingo@redhat.com; hpa@zyto\n"
+ "> > > r.com;\n"
+ "> > > x86@kernel.org; linux-mm@kvack.org\n"
+ "> > > Subject: [RFC 00/12] Multi-Key Total Memory Encryption API\n"
+ "> > > (MKTME)\n"
+ "> > > \n"
+ "> > > Seeking comments on the APIs supporting MKTME on future Intel\n"
+ "> > > platforms.\n"
+ "> > > \n"
+ "> > > MKTME (Multi-Key Total Memory Encryption) is a technology\n"
+ "> > > supporting\n"
+ "> > > memory encryption on upcoming Intel platforms. Whereas TME allows\n"
+ "> > > encryption of the entire system memory using a single key, MKTME\n"
+ "> > > allows\n"
+ "> > > mulitple encryption domains, each having their own key. While the\n"
+ "> > > main use\n"
+ "> > > case for the feature is virtual machine isolation, the API needs\n"
+ "> > > the flexibility to\n"
+ "> > > work for a wide range of use cases.\n"
+ "> > > \n"
+ "> > > This RFC presents the 2 API additions that enable userspace to:\n"
+ "> > >  1) Create Encryption Keys: Kernel Key Service type \"mktme\"\n"
+ "> > >  2) Use the Encryption Keys: system call encrypt_mprotect()\n"
+ "> > > \n"
+ "> > > In order to share between: the Kernel Key Service, the new system\n"
+ "> > > call, and the\n"
+ "> > > existing mm code, helper functions were created in arch/x86/mktme\n"
+ "> > \n"
+ "> > IMHO, we can separate this series into 2 parts, as you did above,\n"
+ "> > and send out them separately. The reason is, in general I think\n"
+ "> > adding new MKTME type to key retention services is not that related\n"
+ "> > to memory management code, namely the encrypt_mprotect() API part.\n"
+ "> > \n"
+ "> > So if we split the two parts and send them out separately, the\n"
+ "> > first part can be reviewed by keyring and security guys, without\n"
+ "> > involving mm guys, and the encrypt_mprotect() part can be more\n"
+ "> > reviewed more by mm guys. \n"
+ "> > \n"
+ "> \n"
+ "> Kai,\n"
+ "> \n"
+ "> That was the direction I had in mind at the onset: the MKTME key\n"
+ "> service\n"
+ "> would be one patch(set) and the MKTME encrypt_mprotect() system call\n"
+ "> would\n"
+ "> be delivered in another patch(set).\n"
+ "> \n"
+ "> That separation falls apart when the shared structures and functions\n"
+ "> are\n"
+ "> introduced. That 'mktme_map' (maps userspace keys to hardware keyid\n"
+ "> slots),\n"
+ "> and the 'encrypt_count' array (counts vma's outstanding for each key)\n"
+ "> need\n"
+ "> to be shared by both pieces. These mktme special shared structures\n"
+ "> and the\n"
+ "> functions that operate on them are all defined in\n"
+ "> arch/x86/mm/mktme.h,.c.\n"
+ "> From there they can be shared with the security/keys/mktme_keys.c\n"
+ "> \n"
+ "> Once I made that separation, I stuck with it. Those structures, and\n"
+ "> any\n"
+ "> functions that manipulate those structures live in\n"
+ "> arch/x86/mm/mktme.h,c\n"
+ "> \n"
+ "> You noted that some of the functions that operate on the\n"
+ "> encrypt_count\n"
+ "> might not need to be over in arch/x86/mm/mktme.c because they are not\n"
+ "> used\n"
+ "> in the mm code. That is true.  \n"
+ "\n"
+ "Yes IMO this is better.\n"
+ "\n"
+ "> But, then I'd be splitting up the definition\n"
+ "> of the struct and the funcs that operate on it. So, I stuck with\n"
+ "> keeping it\n"
+ "> all together in the arch specific mktme files.\n"
+ "\n"
+ "Definition can also be in include/keys/mktme-type.h, right?\n"
+ "\n"
+ "> \n"
+ "> Having said all the above, I do welcome other ideas on how to better\n"
+ "> organize\n"
+ "> the code. \n"
+ "> \n"
+ "> Back to your request- to split it into smaller patchsets might look\n"
+ "> something\n"
+ "> like:\n"
+ "> 1) the MKTME API helpers\n"
+ "\n"
+ "Exactly what helpers?\n"
+ "\n"
+ "> 2) the MKTME Key Service\n"
+ "> 3) the MKTME syscall encrypt_mprotect()\n"
+ "> \n"
+ "> I'm not clear that would make anyones review life easier, than\n"
+ "> picking\n"
+ "> the same pieces out of the greater patchset.\n"
+ "\n"
+ "Well, the reason I suggested we should split key retention services\n"
+ "from other staff and get it reviewed first is I think the\n"
+ "functionalities of MKTME key type has nothing to do w/ MM code. IMHO\n"
+ "what MKTME key type should provide includes:\n"
+ "\n"
+ "1) Support add_key, keyctl (revoke, etc) obviously. THis also implies\n"
+ "keyID allocation, so you will need some info from MM or x86 code to get\n"
+ " info such as number of keyIDs, etc. In fact I think number of keyIDs\n"
+ "is  the only info you need (0 keyIDs means MKTME is disabled).\n"
+ "\n"
+ "2) You need to provide some APIs to munipulate key reference count.\n"
+ "Those functions can be declared in mktme-type.h, and implemented in\n"
+ "mktme_keys.c. I think this is more reasonable, as logically reference\n"
+ "count is part of MKTME key service.\n"
+ "\n"
+ "I don't think you need to do anything else in MKTME key type?\n"
+ "\n"
+ "I think you can even start upstreaming MKTME key type now w/o Kirill's\n"
+ "core-MKTME support, since 1) adding MKTME key type doesn't do any harm\n"
+ "w/o kirill's core-MKTME code; 2) logically MKTME key type has no true\n"
+ "dependency on core-MKTME code.\n"
+ "\n"
+ "So IMHO, a better structure should be:\n"
+ "\n"
+ "1) Current upstream code (maybe with some early detction code change,\n"
+ "ie, to disable MKTME for some SW reason, but I am not sure whether this\n"
+ "is truely needed, since when MKTME key type gets initialized, that part\n"
+ "should been done already).\n"
+ "2) MKTME key type\n"
+ "3) Kirill's core-MKTME\n"
+ "4) new syscall\n"
+ "\n"
+ "And I think CONFIG_MKTME_KEYS doesn't really need to depend on\n"
+ "CONFIG_INTEL_MKTME at this point, although we can add such if needed\n"
+ "when kirill's core-MKTME code gets upstreamed.\n"
+ "\n"
+ "Thanks,\n"
+ "-Kai\n"
+ "> \n"
+ "> Suggestions welcome,\n"
+ "> Alison\n"
+ "> \n"
+ "> > And since encrypt_mprotect() is a new syscall, you may need to add\n"
+ "> > more lists for the review, ie, linux-api, and maybe linux-kernel as\n"
+ "> > well.\n"
+ "> \n"
+ "> Got it. Will include theses in v1.\n"
+ "> \n"
+ "> > \n"
+ "> > Thanks,\n"
+ "> > -Kai\n"
+ "> > \n"
+ "> > > \n"
+ "> > > This patchset is built upon Kirill Shutemov's patchset for the\n"
+ "> > > core MKTME\n"
+ "> > > support. You can find that here:\n"
+ "> > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git\n"
+ "> > > mktme/wip\n"
+ "> > > \n"
+ "> > > \n"
+ "> > > Alison Schofield (12):\n"
+ "> > >   docs/x86: Document the Multi-Key Total Memory Encryption API\n"
+ "> > >   mm: Generalize the mprotect implementation to support\n"
+ "> > > extensions\n"
+ "> > >   syscall/x86: Wire up a new system call for memory encryption\n"
+ "> > > keys\n"
+ "> > >   x86/mm: Add helper functions to manage memory encryption keys\n"
+ "> > >   x86/mm: Add a helper function to set keyid bits in encrypted\n"
+ "> > > VMA's\n"
+ "> > >   mm: Add the encrypt_mprotect() system call\n"
+ "> > >   x86/mm: Add helper functions to track encrypted VMA's\n"
+ "> > >   mm: Track VMA's in use for each memory encryption keyid\n"
+ "> > >   mm: Restrict memory encryption to anonymous VMA's\n"
+ "> > >   x86/pconfig: Program memory encryption keys on a system-wide\n"
+ "> > > basis\n"
+ "> > >   keys/mktme: Add a new key service type for memory encryption\n"
+ "> > > keys\n"
+ "> > >   keys/mktme: Do not revoke in use memory encryption keys\n"
+ "> > > \n"
+ "> > >  Documentation/x86/mktme-keys.txt       | 153 ++++++++++++++++\n"
+ "> > >  arch/x86/Kconfig                       |   1 +\n"
+ "> > >  arch/x86/entry/syscalls/syscall_32.tbl |   1 +\n"
+ "> > >  arch/x86/entry/syscalls/syscall_64.tbl |   1 +\n"
+ "> > >  arch/x86/include/asm/intel_pconfig.h   |  42 ++++-\n"
+ "> > >  arch/x86/include/asm/mktme.h           |  21 +++\n"
+ "> > >  arch/x86/mm/mktme.c                    | 141 ++++++++++++++\n"
+ "> > >  fs/exec.c                              |   4 +-\n"
+ "> > >  include/keys/mktme-type.h              |  28 +++\n"
+ "> > >  include/linux/key.h                    |   2 +\n"
+ "> > >  include/linux/mm.h                     |   9 +-\n"
+ "> > >  include/linux/syscalls.h               |   2 +\n"
+ "> > >  include/uapi/asm-generic/unistd.h      |   4 +-\n"
+ "> > >  kernel/fork.c                          |   2 +\n"
+ "> > >  kernel/sys_ni.c                        |   2 +\n"
+ "> > >  mm/mmap.c                              |  12 ++\n"
+ "> > >  mm/mprotect.c                          |  93 +++++++++-\n"
+ "> > >  mm/nommu.c                             |   4 +\n"
+ "> > >  security/keys/Kconfig                  |  11 ++\n"
+ "> > >  security/keys/Makefile                 |   1 +\n"
+ "> > >  security/keys/internal.h               |   6 +\n"
+ "> > >  security/keys/keyctl.c                 |   7 +\n"
+ "> > >  security/keys/mktme_keys.c             | 325\n"
+ "> > > +++++++++++++++++++++++++++++++++\n"
+ "> > >  23 files changed, 855 insertions(+), 17 deletions(-)  create\n"
+ "> > > mode 100644\n"
+ "> > > Documentation/x86/mktme-keys.txt  create mode 100644\n"
+ "> > > include/keys/mktme-\n"
+ "> > > type.h  create mode 100644 security/keys/mktme_keys.c\n"
+ "> > > \n"
+ "> > > --\n"
+ > > > 2.14.1
 
-15f39306757d29823a45de7fd61c1b6361a20ea2166850417e2e33a1da3cf2a0
+9ba07e2ccacf1193a5403bd632ac5ac302831b183e9de19ff2dd605f31307ae9

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.