)]}'
{"specs/backlog/vm-mem-encryption-using-intel-mktme.rst":[{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"91afce7e1a8556117a6ed5d2f329fda225253b0e","unresolved":false,"context_lines":[{"line_number":81,"context_line":"        \u003cdomainCapabilities\u003e"},{"line_number":82,"context_line":"          \u003cfeatures\u003e"},{"line_number":83,"context_line":"            \u003csev supported\u003d\u0027no\u0027/\u003e"},{"line_number":84,"context_line":"            \u003cmktme supported \u003d \u0027yes\u003e"},{"line_number":85,"context_line":"              \u003ckeys_supported\u003eint-value\u003c/keys_supported\u003e"},{"line_number":86,"context_line":"              \u003ckeys_available\u003eint-value\u003c/keys_available\u003e"},{"line_number":87,"context_line":"            \u003c/mktme\u003e"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_384b0788","line":84,"range":{"start_line":84,"start_character":12,"end_line":84,"end_character":36},"updated":"2019-07-24 11:27:49.000000000","message":"Syntax error; should be\n\n     \u003cmktme supported\u003d\u0027yes\u0027/\u003e","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":81,"context_line":"        \u003cdomainCapabilities\u003e"},{"line_number":82,"context_line":"          \u003cfeatures\u003e"},{"line_number":83,"context_line":"            \u003csev supported\u003d\u0027no\u0027/\u003e"},{"line_number":84,"context_line":"            \u003cmktme supported \u003d \u0027yes\u003e"},{"line_number":85,"context_line":"              \u003ckeys_supported\u003eint-value\u003c/keys_supported\u003e"},{"line_number":86,"context_line":"              \u003ckeys_available\u003eint-value\u003c/keys_available\u003e"},{"line_number":87,"context_line":"            \u003c/mktme\u003e"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_1fe611ea","line":84,"range":{"start_line":84,"start_character":12,"end_line":84,"end_character":36},"in_reply_to":"7faddb67_384b0788","updated":"2019-07-26 03:01:40.000000000","message":"will fix","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"91afce7e1a8556117a6ed5d2f329fda225253b0e","unresolved":false,"context_lines":[{"line_number":92,"context_line":"above MKTME domain capabilities."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"A new resource class should be configured to support MKTME information with"},{"line_number":95,"context_line":"total `keys_supported` and `keys-available`. This resource class will be"},{"line_number":96,"context_line":"updated on the discovery of the MTKME capable host."},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"2. New meta data prefixes"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_f8448f76","line":95,"range":{"start_line":95,"start_character":28,"end_line":95,"end_character":42},"updated":"2019-07-24 11:27:49.000000000","message":"keys_available","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":92,"context_line":"above MKTME domain capabilities."},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"A new resource class should be configured to support MKTME information with"},{"line_number":95,"context_line":"total `keys_supported` and `keys-available`. This resource class will be"},{"line_number":96,"context_line":"updated on the discovery of the MTKME capable host."},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"2. New meta data prefixes"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_3fe98db6","line":95,"range":{"start_line":95,"start_character":28,"end_line":95,"end_character":42},"in_reply_to":"7faddb67_f8448f76","updated":"2019-07-26 03:01:40.000000000","message":"Done","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Image meta data values for Intel\u0027s MKTME policy will be as follows::"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"    mem_enc_sec:type\u003d{Intel-MKTME, AMD-SEV}"},{"line_number":117,"context_line":"    mem_enc_secpolicy:shared \u003d {True/False}"},{"line_number":118,"context_line":"    {True in case this policy is to share a key with already existing key}"},{"line_number":119,"context_line":"    mem_enc_secpolicy:id \u003d \"string-name\""},{"line_number":120,"context_line":"    {In case of key-type\u003duser this will be key reference value}"},{"line_number":121,"context_line":"    mem_enc_secpolicy:key-type \u003d {\"cpu\" or \"user\"}"},{"line_number":122,"context_line":"    mem_enc_secpolicy:encryption-algorithm \u003d {\"AES-XTS-128\"}"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"The aforementioned prefixes/policy information is only used to carry data to"},{"line_number":125,"context_line":"Libvirt API calls, however `mem_enc_secpolicy:shared` in meta data will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_3c1fb75b","line":122,"range":{"start_line":116,"start_character":2,"end_line":122,"end_character":60},"updated":"2019-07-01 22:49:21.000000000","message":"i am not sure that is compatible with \nhttps://specs.openstack.org/openstack/nova-specs/specs/train/approved/amd-sev-libvirt-support.html\nor rather i do not think its inline with the direction we had in mind for supporting mktme in the future.\n\nour current intention is to use \nhw:mem_encryption to request sev or mktme.\n\nif you just set hw:mem_encryption\u003dtrue it will request 1 mem encryption context which corraltates with 1 mktme key.\n\nto specifically select sev or mktme a trait request would be used instead of the propsed mem_enc_sec:type.\n\nnot that for sev we had planned to use the \"HW:\" namespace not that intoduce a new namespace which is one of the deltas between what has already been agreed for sev vs what this spec proposes.\n\nAt present we are not planning to allow the user to select an encrption algorithim or key type. i am not sure if this is something we should expose as configuarable paramaters.\nif we do we need to be able to schdule on the encryption algortioms and key types.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Image meta data values for Intel\u0027s MKTME policy will be as follows::"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"    mem_enc_sec:type\u003d{Intel-MKTME, AMD-SEV}"},{"line_number":117,"context_line":"    mem_enc_secpolicy:shared \u003d {True/False}"},{"line_number":118,"context_line":"    {True in case this policy is to share a key with already existing key}"},{"line_number":119,"context_line":"    mem_enc_secpolicy:id \u003d \"string-name\""},{"line_number":120,"context_line":"    {In case of key-type\u003duser this will be key reference value}"},{"line_number":121,"context_line":"    mem_enc_secpolicy:key-type \u003d {\"cpu\" or \"user\"}"},{"line_number":122,"context_line":"    mem_enc_secpolicy:encryption-algorithm \u003d {\"AES-XTS-128\"}"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"The aforementioned prefixes/policy information is only used to carry data to"},{"line_number":125,"context_line":"Libvirt API calls, however `mem_enc_secpolicy:shared` in meta data will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_1ffff167","line":122,"range":{"start_line":116,"start_character":2,"end_line":122,"end_character":60},"in_reply_to":"7faddb67_f839eff1","updated":"2019-07-26 03:01:40.000000000","message":"One of the key feature of MKTME is key can be defined and generated with in the CPU or the key can be provided by the user(through KMS). It is same used case on Openstack context, but providing user a choice for key usage for encryption.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"91afce7e1a8556117a6ed5d2f329fda225253b0e","unresolved":false,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Image meta data values for Intel\u0027s MKTME policy will be as follows::"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"    mem_enc_sec:type\u003d{Intel-MKTME, AMD-SEV}"},{"line_number":117,"context_line":"    mem_enc_secpolicy:shared \u003d {True/False}"},{"line_number":118,"context_line":"    {True in case this policy is to share a key with already existing key}"},{"line_number":119,"context_line":"    mem_enc_secpolicy:id \u003d \"string-name\""},{"line_number":120,"context_line":"    {In case of key-type\u003duser this will be key reference value}"},{"line_number":121,"context_line":"    mem_enc_secpolicy:key-type \u003d {\"cpu\" or \"user\"}"},{"line_number":122,"context_line":"    mem_enc_secpolicy:encryption-algorithm \u003d {\"AES-XTS-128\"}"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"The aforementioned prefixes/policy information is only used to carry data to"},{"line_number":125,"context_line":"Libvirt API calls, however `mem_enc_secpolicy:shared` in meta data will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_f839eff1","line":122,"range":{"start_line":116,"start_character":2,"end_line":122,"end_character":60},"in_reply_to":"9fb8cfa7_3c1fb75b","updated":"2019-07-24 11:27:49.000000000","message":"I agree with Sean here regarding mem_enc_sec.  Please read the SEV spec he links to understand the agreed architecture.  We specifically designed it to allow expansion to MKTME in the future whilst ensuring a user-friendly interface and allowing clouds to mix and match SEV and MKTME.\n\nRegarding mem_enc_secpolicy:key-type - when would \"cpu\" be selected vs. \"user\"?  Are they for different use cases in the OpenStack cloud context?","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Image meta data values for Intel\u0027s MKTME policy will be as follows::"},{"line_number":115,"context_line":""},{"line_number":116,"context_line":"    mem_enc_sec:type\u003d{Intel-MKTME, AMD-SEV}"},{"line_number":117,"context_line":"    mem_enc_secpolicy:shared \u003d {True/False}"},{"line_number":118,"context_line":"    {True in case this policy is to share a key with already existing key}"},{"line_number":119,"context_line":"    mem_enc_secpolicy:id \u003d \"string-name\""},{"line_number":120,"context_line":"    {In case of key-type\u003duser this will be key reference value}"},{"line_number":121,"context_line":"    mem_enc_secpolicy:key-type \u003d {\"cpu\" or \"user\"}"},{"line_number":122,"context_line":"    mem_enc_secpolicy:encryption-algorithm \u003d {\"AES-XTS-128\"}"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"The aforementioned prefixes/policy information is only used to carry data to"},{"line_number":125,"context_line":"Libvirt API calls, however `mem_enc_secpolicy:shared` in meta data will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_bfbfbda8","line":122,"range":{"start_line":116,"start_character":2,"end_line":122,"end_character":60},"in_reply_to":"9fb8cfa7_3c1fb75b","updated":"2019-07-26 03:01:40.000000000","message":"I wasn\u0027t aware of  hw:mem_encryption prefix during this write up. But I agree with the current design and will change the blueprint accordingly.\nBut MKTME requires kind of policy configuration, because with this user can configure with CPU generated key or user defined key. And also for now we can remove encryption algorithm. But wanted to suggest all the parameters associated with the policy.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":122,"context_line":"    mem_enc_secpolicy:encryption-algorithm \u003d {\"AES-XTS-128\"}"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"The aforementioned prefixes/policy information is only used to carry data to"},{"line_number":125,"context_line":"Libvirt API calls, however `mem_enc_secpolicy:shared` in meta data will be"},{"line_number":126,"context_line":"used to filter the compute nodes which will have available MKTME keys."},{"line_number":127,"context_line":"Since MKTME features allow keys to be shared between VMs, a new key will only"},{"line_number":128,"context_line":"be allocated if `mem_enc_secpolicy:shared` is set `False`. Hence, we propose"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_1c3d13ba","line":125,"range":{"start_line":125,"start_character":27,"end_line":125,"end_character":53},"updated":"2019-07-01 22:49:21.000000000","message":"I\u0027m not sure if we should support shared keys.\n\nIt would be incorrect to allow sharing between different tenants, as such i can only see this as useful if and only if\nwe combined it with server affinity groupe.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":122,"context_line":"    mem_enc_secpolicy:encryption-algorithm \u003d {\"AES-XTS-128\"}"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"The aforementioned prefixes/policy information is only used to carry data to"},{"line_number":125,"context_line":"Libvirt API calls, however `mem_enc_secpolicy:shared` in meta data will be"},{"line_number":126,"context_line":"used to filter the compute nodes which will have available MKTME keys."},{"line_number":127,"context_line":"Since MKTME features allow keys to be shared between VMs, a new key will only"},{"line_number":128,"context_line":"be allocated if `mem_enc_secpolicy:shared` is set `False`. Hence, we propose"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_9f4761bd","line":125,"range":{"start_line":125,"start_character":27,"end_line":125,"end_character":53},"in_reply_to":"7faddb67_dbaaedd0","updated":"2019-07-26 03:01:40.000000000","message":"Will add another used case scenario for shared keys among the tenants ..good suggestion.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"91afce7e1a8556117a6ed5d2f329fda225253b0e","unresolved":false,"context_lines":[{"line_number":122,"context_line":"    mem_enc_secpolicy:encryption-algorithm \u003d {\"AES-XTS-128\"}"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"The aforementioned prefixes/policy information is only used to carry data to"},{"line_number":125,"context_line":"Libvirt API calls, however `mem_enc_secpolicy:shared` in meta data will be"},{"line_number":126,"context_line":"used to filter the compute nodes which will have available MKTME keys."},{"line_number":127,"context_line":"Since MKTME features allow keys to be shared between VMs, a new key will only"},{"line_number":128,"context_line":"be allocated if `mem_enc_secpolicy:shared` is set `False`. Hence, we propose"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_dbaaedd0","line":125,"range":{"start_line":125,"start_character":27,"end_line":125,"end_character":53},"in_reply_to":"9fb8cfa7_1c3d13ba","updated":"2019-07-24 11:27:49.000000000","message":"I\u0027m equally uncertain about this.  If there is a use case for key sharing in the OpenStack context, this spec should explain it.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":122,"context_line":"    mem_enc_secpolicy:encryption-algorithm \u003d {\"AES-XTS-128\"}"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"The aforementioned prefixes/policy information is only used to carry data to"},{"line_number":125,"context_line":"Libvirt API calls, however `mem_enc_secpolicy:shared` in meta data will be"},{"line_number":126,"context_line":"used to filter the compute nodes which will have available MKTME keys."},{"line_number":127,"context_line":"Since MKTME features allow keys to be shared between VMs, a new key will only"},{"line_number":128,"context_line":"be allocated if `mem_enc_secpolicy:shared` is set `False`. Hence, we propose"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_df3dd92c","line":125,"range":{"start_line":125,"start_character":27,"end_line":125,"end_character":53},"in_reply_to":"9fb8cfa7_1c3d13ba","updated":"2019-07-26 03:01:40.000000000","message":"The suggestion is, a given user can use the same key for different VMs memory encryption launched by him. And was expecting no two users will have the same key.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":128,"context_line":"be allocated if `mem_enc_secpolicy:shared` is set `False`. Hence, we propose"},{"line_number":129,"context_line":"this meta data to be a part of Nova scheduling filtering for MKTME."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"AMD-SEV launch security type can use its own key:value pair for SEV policy."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Both image metadata and extra_specs will be checked to retrieve the policy"},{"line_number":134,"context_line":"information in Nova compute."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_7c852f59","line":131,"range":{"start_line":131,"start_character":0,"end_line":131,"end_character":74},"updated":"2019-07-01 22:49:21.000000000","message":"for sev we are always allocating one sev context per vm with a hard-coded policy\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/train/approved/amd-sev-libvirt-support.html#sev-launch-time-configuration modification of the policy is currently being defered until the basic support is completed.\n\nif we expose polices we should define a abstracted set that can be mapped to both mktme and sev withoug directly exposing the libvirt values.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":128,"context_line":"be allocated if `mem_enc_secpolicy:shared` is set `False`. Hence, we propose"},{"line_number":129,"context_line":"this meta data to be a part of Nova scheduling filtering for MKTME."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"AMD-SEV launch security type can use its own key:value pair for SEV policy."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Both image metadata and extra_specs will be checked to retrieve the policy"},{"line_number":134,"context_line":"information in Nova compute."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_1f0db18f","line":131,"range":{"start_line":131,"start_character":0,"end_line":131,"end_character":74},"in_reply_to":"9fb8cfa7_7c852f59","updated":"2019-07-26 03:01:40.000000000","message":"Since we are developing this feature for future releases, would like to have a dialog on how to configure encryption policy which will work out for both memory encryptions.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  in the process of constructing the XML string before the launch call to"},{"line_number":144,"context_line":"  Libvirt should check *key-type*."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"* If *key-type\u003duser*, using the *id* reference information, MKTME-key is"},{"line_number":147,"context_line":"  retrieved from the key management server (e.g Barbican)"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"* Nova compute will update *Libvirt* domain XML file\u0027s *LaunchSecurity*"},{"line_number":150,"context_line":"  attributes with security policy data and retrieved MKTME-key value if"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_5cf38b09","line":147,"range":{"start_line":146,"start_character":2,"end_line":147,"end_character":57},"updated":"2019-07-01 22:49:21.000000000","message":"i would initally suggest starting with only the cpu key type\nand defering user provided keys to U given how late this spec is and the time left to implement the feature.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  in the process of constructing the XML string before the launch call to"},{"line_number":144,"context_line":"  Libvirt should check *key-type*."},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"* If *key-type\u003duser*, using the *id* reference information, MKTME-key is"},{"line_number":147,"context_line":"  retrieved from the key management server (e.g Barbican)"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"* Nova compute will update *Libvirt* domain XML file\u0027s *LaunchSecurity*"},{"line_number":150,"context_line":"  attributes with security policy data and retrieved MKTME-key value if"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_bf49fdb7","line":147,"range":{"start_line":146,"start_character":2,"end_line":147,"end_character":57},"in_reply_to":"9fb8cfa7_5cf38b09","updated":"2019-07-26 03:01:40.000000000","message":"Targeting this feature for U and later releases and would like to see the feed back on user provided keys also.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":150,"context_line":"  attributes with security policy data and retrieved MKTME-key value if"},{"line_number":151,"context_line":"  required."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"* Nova compute will update newly created resource provider tree with new"},{"line_number":154,"context_line":"  \u0027keys_available\u0027 data after the execution of every instance launch request"},{"line_number":155,"context_line":"  with VM memory encryption of MKTME type."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"  The following MKTME configuration is used for launch of VM instance with"},{"line_number":158,"context_line":"  memory encryption in Libvirt domain XML::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_7c38cf9e","line":155,"range":{"start_line":153,"start_character":0,"end_line":155,"end_character":42},"updated":"2019-07-01 22:49:21.000000000","message":"that is not how placement works.\n\nthe placement inventory would be created by the compute manager as part of update_provider_tree then when scheduling a instance to a host an allocation is claimed in placement before we spawn an instance on the host.\n\nthe nova compute agent does not need to update the placement on every instance spawn because we claim the allocation in the scheduler before we select the host. if we can claim the allocation we select one of the alternate host and repeat until we no longer have any alternates or have successfully claimed an allocation candidate in placement.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":150,"context_line":"  attributes with security policy data and retrieved MKTME-key value if"},{"line_number":151,"context_line":"  required."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"* Nova compute will update newly created resource provider tree with new"},{"line_number":154,"context_line":"  \u0027keys_available\u0027 data after the execution of every instance launch request"},{"line_number":155,"context_line":"  with VM memory encryption of MKTME type."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"  The following MKTME configuration is used for launch of VM instance with"},{"line_number":158,"context_line":"  memory encryption in Libvirt domain XML::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_5fc6c918","line":155,"range":{"start_line":153,"start_character":0,"end_line":155,"end_character":42},"in_reply_to":"9fb8cfa7_7c38cf9e","updated":"2019-07-26 03:01:40.000000000","message":"Will look more into it and will update the documentation. Thanks for info..","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":177,"context_line":"          \u003ctenant\u003ename\u003c/tenant\u003e"},{"line_number":178,"context_line":"          \u003cid\u003efake-name0\u003c/id\u003e"},{"line_number":179,"context_line":"          \u003ckey_type\u003ecpu\u003c/key_type\u003e"},{"line_number":180,"context_line":"          \u003ckey\u003eAQAAAAAOAAAAQAAAAAOAAAAQAAAAAOAAAAQAAAAAOAAAAQAAAAAOAAA\u003c/key\u003e"},{"line_number":181,"context_line":"          \u003cencryption_algorithm\u003eAES-XTS-128\u003c/encryption_algorithm\u003e"},{"line_number":182,"context_line":"       \u003c/launchSecurity\u003e"},{"line_number":183,"context_line":"      \u003c/domain\u003e"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_5c414b09","line":180,"range":{"start_line":180,"start_character":10,"end_line":180,"end_character":76},"updated":"2019-07-01 22:49:21.000000000","message":"what is this?\n\nis this a shared key e.g. a two way key that is used for both encryption and decryption?\n\nif so how would this provdie any security when any user with libvirt acess could jsut use it + the encryption algortihm to decypt the guest memroy.\n\nif its a public key how is the private key passed to the geust?","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":182,"context_line":"       \u003c/launchSecurity\u003e"},{"line_number":183,"context_line":"      \u003c/domain\u003e"},{"line_number":184,"context_line":""},{"line_number":185,"context_line":"VM delete and suspend operations will detach the MTKME key from the memory"},{"line_number":186,"context_line":"encryption and key will be deleted by the kernel key services if key is not"},{"line_number":187,"context_line":"shared or used by any of the VMs in the compute node."},{"line_number":188,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_fc4b5f27","line":185,"range":{"start_line":185,"start_character":13,"end_line":185,"end_character":21},"updated":"2019-07-01 22:49:21.000000000","message":"on suspend is the memory saved in encryped form to disk.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":195,"context_line":"not guaranteed. The number of available keys could be reduced if, for"},{"line_number":196,"context_line":"instance, additional physical address space is desired over additional KeyIDs."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Currently only AES-XTS-128 encryption algorithm is supported for VM encryption."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Having a generic resource class for the memory encryption feature will give"},{"line_number":201,"context_line":"user good understanding of the security features in Nova and flexibility use"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_1c47531f","line":198,"range":{"start_line":198,"start_character":0,"end_line":198,"end_character":79},"updated":"2019-07-01 22:49:21.000000000","message":"if this is the only supported algortim then we do not need to expose a extra spec or image metadata property until such a time as others are supported.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":195,"context_line":"not guaranteed. The number of available keys could be reduced if, for"},{"line_number":196,"context_line":"instance, additional physical address space is desired over additional KeyIDs."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Currently only AES-XTS-128 encryption algorithm is supported for VM encryption."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Having a generic resource class for the memory encryption feature will give"},{"line_number":201,"context_line":"user good understanding of the security features in Nova and flexibility use"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_9fe3e1a4","line":198,"range":{"start_line":198,"start_character":0,"end_line":198,"end_character":79},"in_reply_to":"9fb8cfa7_1c47531f","updated":"2019-07-26 03:01:40.000000000","message":"agree, kept it for future updates to MKTME","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Currently only AES-XTS-128 encryption algorithm is supported for VM encryption."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Having a generic resource class for the memory encryption feature will give"},{"line_number":201,"context_line":"user good understanding of the security features in Nova and flexibility use"},{"line_number":202,"context_line":"this resource class in Nova scheduler. Since Intel and AMD\u0027s"},{"line_number":203,"context_line":"encryption feature has different requirement we have to stick to one resource"},{"line_number":204,"context_line":"class for both the implementations."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_9c0903de","line":204,"range":{"start_line":200,"start_character":0,"end_line":204,"end_character":35},"updated":"2019-07-01 22:49:21.000000000","message":"the MEM_ENCRYPTION_CONTEXT intoduced by https://specs.openstack.org/openstack/nova-specs/specs/train/approved/amd-sev-libvirt-support.html was selected to be the single resource class used for both implementations.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Currently only AES-XTS-128 encryption algorithm is supported for VM encryption."},{"line_number":199,"context_line":""},{"line_number":200,"context_line":"Having a generic resource class for the memory encryption feature will give"},{"line_number":201,"context_line":"user good understanding of the security features in Nova and flexibility use"},{"line_number":202,"context_line":"this resource class in Nova scheduler. Since Intel and AMD\u0027s"},{"line_number":203,"context_line":"encryption feature has different requirement we have to stick to one resource"},{"line_number":204,"context_line":"class for both the implementations."},{"line_number":205,"context_line":""},{"line_number":206,"context_line":""},{"line_number":207,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_3fec2d8e","line":204,"range":{"start_line":200,"start_character":0,"end_line":204,"end_character":35},"in_reply_to":"9fb8cfa7_9c0903de","updated":"2019-07-26 03:01:40.000000000","message":"Will update according to the SEV spec.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":233,"context_line":"This feature does not alter any of the data and objects in Nova. VM memory"},{"line_number":234,"context_line":"encryption is transparent to the user and it is done at the Libvirt and QEMU"},{"line_number":235,"context_line":"level."},{"line_number":236,"context_line":"If the MKTME key is a tenant provided key, vulnerability of the key in"},{"line_number":237,"context_line":"Nova code is unclear. Our plan is to make the key obsolete once the key is"},{"line_number":238,"context_line":"retrieved and updatedin the Domain XML file of libvirt."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_5c0f0bdf","line":237,"range":{"start_line":236,"start_character":0,"end_line":237,"end_character":22},"updated":"2019-07-01 22:49:21.000000000","message":"i think this need more explanaitnion of the risk vectors.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":233,"context_line":"This feature does not alter any of the data and objects in Nova. VM memory"},{"line_number":234,"context_line":"encryption is transparent to the user and it is done at the Libvirt and QEMU"},{"line_number":235,"context_line":"level."},{"line_number":236,"context_line":"If the MKTME key is a tenant provided key, vulnerability of the key in"},{"line_number":237,"context_line":"Nova code is unclear. Our plan is to make the key obsolete once the key is"},{"line_number":238,"context_line":"retrieved and updatedin the Domain XML file of libvirt."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_df02b93e","line":237,"range":{"start_line":236,"start_character":0,"end_line":237,"end_character":22},"in_reply_to":"9fb8cfa7_5c0f0bdf","updated":"2019-07-26 03:01:40.000000000","message":"Done","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":234,"context_line":"encryption is transparent to the user and it is done at the Libvirt and QEMU"},{"line_number":235,"context_line":"level."},{"line_number":236,"context_line":"If the MKTME key is a tenant provided key, vulnerability of the key in"},{"line_number":237,"context_line":"Nova code is unclear. Our plan is to make the key obsolete once the key is"},{"line_number":238,"context_line":"retrieved and updatedin the Domain XML file of libvirt."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":""},{"line_number":241,"context_line":"Notifications impact"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_fcf91fc7","line":238,"range":{"start_line":237,"start_character":22,"end_line":238,"end_character":55},"updated":"2019-07-01 22:49:21.000000000","message":"do we need to ever have the key in in plain text or can we ensure that nova never actully handels the plain text key.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":234,"context_line":"encryption is transparent to the user and it is done at the Libvirt and QEMU"},{"line_number":235,"context_line":"level."},{"line_number":236,"context_line":"If the MKTME key is a tenant provided key, vulnerability of the key in"},{"line_number":237,"context_line":"Nova code is unclear. Our plan is to make the key obsolete once the key is"},{"line_number":238,"context_line":"retrieved and updatedin the Domain XML file of libvirt."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":""},{"line_number":241,"context_line":"Notifications impact"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_ffabf51a","line":238,"range":{"start_line":237,"start_character":22,"end_line":238,"end_character":55},"in_reply_to":"9fb8cfa7_fcf91fc7","updated":"2019-07-26 03:01:40.000000000","message":"For now it looks like key is going to be in plain text, still investigating on actual implementation of retrieving keys in Nova compute. We are depending the keystone authentication for this key in plain text in nova compute.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":238,"context_line":"retrieved and updatedin the Domain XML file of libvirt."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":""},{"line_number":241,"context_line":"Notifications impact"},{"line_number":242,"context_line":"--------------------"},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Since MKTME is a security resource and as mentioned above is treated as a new"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_1cf513cb","line":241,"range":{"start_line":241,"start_character":0,"end_line":241,"end_character":20},"updated":"2019-07-01 22:49:21.000000000","message":"this is more or less covered by \nhttps://specs.openstack.org/openstack/nova-specs/specs/train/approved/amd-sev-libvirt-support.html#notifications-impact","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":238,"context_line":"retrieved and updatedin the Domain XML file of libvirt."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":""},{"line_number":241,"context_line":"Notifications impact"},{"line_number":242,"context_line":"--------------------"},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Since MKTME is a security resource and as mentioned above is treated as a new"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_bfa57d49","line":241,"range":{"start_line":241,"start_character":0,"end_line":241,"end_character":20},"in_reply_to":"9fb8cfa7_1cf513cb","updated":"2019-07-26 03:01:40.000000000","message":"Done","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"679d5e6ca70ef5e870b1b5c4e226aaa83bb7d604","unresolved":false,"context_lines":[{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Other deployer impact"},{"line_number":266,"context_line":"---------------------"},{"line_number":267,"context_line":"A key manager - like Barbican - is required."},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"The key manager needs to be accessible from compute, requiring appropriate"},{"line_number":270,"context_line":"nova.conf adjustments."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9fb8cfa7_dcfa1bb8","line":267,"range":{"start_line":267,"start_character":0,"end_line":267,"end_character":44},"updated":"2019-07-01 22:49:21.000000000","message":"mktme does not supprot generating vms keys on the fly for a vm as SEV does?","commit_id":"312daae251fe062fa6c21f742eea020226df7472"},{"author":{"_account_id":28171,"name":"karim","email":"karimullah.mohammed@intel.com","username":"karimull"},"change_message_id":"cdd56c8d9cd48f2475f3d5ddb2e453dba850fbf5","unresolved":false,"context_lines":[{"line_number":264,"context_line":""},{"line_number":265,"context_line":"Other deployer impact"},{"line_number":266,"context_line":"---------------------"},{"line_number":267,"context_line":"A key manager - like Barbican - is required."},{"line_number":268,"context_line":""},{"line_number":269,"context_line":"The key manager needs to be accessible from compute, requiring appropriate"},{"line_number":270,"context_line":"nova.conf adjustments."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7faddb67_7f65c51c","line":267,"range":{"start_line":267,"start_character":0,"end_line":267,"end_character":44},"in_reply_to":"9fb8cfa7_dcfa1bb8","updated":"2019-07-26 03:01:40.000000000","message":"It does in case of when the key-type chosen is CPU generated key. If the key-type is tenant/user depending on the KMS url the key is retrieved. So the plan is to retrieve the key from the barbican server.","commit_id":"312daae251fe062fa6c21f742eea020226df7472"}]}