)]}'
{"specs/queens/approved/ovmf-with-secure-boot-and-smm.rst":[{"author":{"_account_id":6874,"name":"Patrick Uiterwijk","email":"puiterwijk@gmail.com","username":"puiterwijk"},"change_message_id":"51901af3b86f2a61b0f339e7d60fc7aaeef68012","unresolved":false,"context_lines":[{"line_number":32,"context_line":""},{"line_number":33,"context_line":"A non-exhaustive list:"},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"* The OVMF This will allow trustworthy code in Nova instances to: (a)"},{"line_number":36,"context_line":"  enable the Secure Boot operational mode (for protecting itself); and"},{"line_number":37,"context_line":"  (b) _also_ prevent malicious code in the guests from circumventing the"},{"line_number":38,"context_line":"  actual security of the Secure Boot operational mode."}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_0c321b60","line":35,"updated":"2017-11-24 10:38:51.000000000","message":"I think that you are trying to mash SMM and SB into a single use case, while they might benefit from being split.\nMaybe something like:\n* SMM: This will allow parts of the system firmware (OVMF) to protect itself from malicious software.\n* Secure Boot: This will prevent the VM from running untrusted code by requiring a trusted signature on any UEFI binaries.","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":32,"context_line":""},{"line_number":33,"context_line":"A non-exhaustive list:"},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"* The OVMF This will allow trustworthy code in Nova instances to: (a)"},{"line_number":36,"context_line":"  enable the Secure Boot operational mode (for protecting itself); and"},{"line_number":37,"context_line":"  (b) _also_ prevent malicious code in the guests from circumventing the"},{"line_number":38,"context_line":"  actual security of the Secure Boot operational mode."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f515b1d_a33d1b90","line":35,"range":{"start_line":35,"start_character":2,"end_line":35,"end_character":20},"updated":"2018-01-02 17:31:42.000000000","message":"Not sure, but it seems like you started one sentence but then switched to another?","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"0972943557e392f3169d351fc70e18724fec6176","unresolved":false,"context_lines":[{"line_number":32,"context_line":""},{"line_number":33,"context_line":"A non-exhaustive list:"},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"* The OVMF This will allow trustworthy code in Nova instances to: (a)"},{"line_number":36,"context_line":"  enable the Secure Boot operational mode (for protecting itself); and"},{"line_number":37,"context_line":"  (b) _also_ prevent malicious code in the guests from circumventing the"},{"line_number":38,"context_line":"  actual security of the Secure Boot operational mode."}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_5c30d2e8","line":35,"in_reply_to":"ff82abbf_0c321b60","updated":"2017-11-28 10:39:10.000000000","message":"Yeah, that\u0027s clearer, I\u0027ll fix the wording.\n\nThe use case \"mashing\" was because I was also listing the advantages of OVMF in general, as a reminder to those who don\u0027t normally dwell on this topic :-).\n\nBut you\u0027re right -- probably I should just stick to describing Secure Boot.","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6874,"name":"Patrick Uiterwijk","email":"puiterwijk@gmail.com","username":"puiterwijk"},"change_message_id":"51901af3b86f2a61b0f339e7d60fc7aaeef68012","unresolved":false,"context_lines":[{"line_number":37,"context_line":"  (b) _also_ prevent malicious code in the guests from circumventing the"},{"line_number":38,"context_line":"  actual security of the Secure Boot operational mode."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* Using UEFI BIOS with OVMF: A PCI Express graphics card with a UEFI"},{"line_number":41,"context_line":"  driver has no legacy baggage (no central IO ports) that would result"},{"line_number":42,"context_line":"  in conflicts if you had multiple such devices in your system. This"},{"line_number":43,"context_line":"  means several emulated and assigned UEFI graphics cards can peacefully"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_0c969b40","line":40,"updated":"2017-11-24 10:38:51.000000000","message":"I don\u0027t think that this is new functionality with SMM/SB, right? You don\u0027t need either to use a PCI Express graphics card with UEFI I think.","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"0972943557e392f3169d351fc70e18724fec6176","unresolved":false,"context_lines":[{"line_number":37,"context_line":"  (b) _also_ prevent malicious code in the guests from circumventing the"},{"line_number":38,"context_line":"  actual security of the Secure Boot operational mode."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"* Using UEFI BIOS with OVMF: A PCI Express graphics card with a UEFI"},{"line_number":41,"context_line":"  driver has no legacy baggage (no central IO ports) that would result"},{"line_number":42,"context_line":"  in conflicts if you had multiple such devices in your system. This"},{"line_number":43,"context_line":"  means several emulated and assigned UEFI graphics cards can peacefully"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_aac95759","line":40,"in_reply_to":"ff82abbf_0c969b40","updated":"2017-11-28 10:39:10.000000000","message":"Correct.  I wrote it after reading the Kernel VFIO maintainer\u0027s blogpost[*], where he wrote: \"Dont use VGA: This is actually a promising path, and one that we\u0027ll talk more about in the future...\"\n\nAnd when asked on IRC, he clarified that it means: \" Using a PCIe card with UEFI BIOS + OVMF\".\n\nSo I thought it\u0027s a reasonable to put it in (again, as part of \"Why use OVMF?\")\n\n[*]  http://vfio.blogspot.be/2014/08/whats-deal-with-vga-arbitration.html","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6874,"name":"Patrick Uiterwijk","email":"puiterwijk@gmail.com","username":"puiterwijk"},"change_message_id":"51901af3b86f2a61b0f339e7d60fc7aaeef68012","unresolved":false,"context_lines":[{"line_number":43,"context_line":"  means several emulated and assigned UEFI graphics cards can peacefully"},{"line_number":44,"context_line":"  co-exist."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"* More benefits of using OVMF are listed in the \"Motivation\" section of"},{"line_number":47,"context_line":"  the OVMF white paper."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_4c4343b0","line":46,"updated":"2017-11-24 10:38:51.000000000","message":"Isn\u0027t it already possible to use OVMF? I thought that this proposal is purely for SMM/secureboot, not generally for switching to OVMF?","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"0972943557e392f3169d351fc70e18724fec6176","unresolved":false,"context_lines":[{"line_number":43,"context_line":"  means several emulated and assigned UEFI graphics cards can peacefully"},{"line_number":44,"context_line":"  co-exist."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"* More benefits of using OVMF are listed in the \"Motivation\" section of"},{"line_number":47,"context_line":"  the OVMF white paper."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_aa22b7b7","line":46,"in_reply_to":"ff82abbf_4c4343b0","updated":"2017-11-28 10:39:10.000000000","message":"Yep, you\u0027re right. I pointed it out merely as a refresher to those who are reading this specification and are unfamiliar with OVMF.","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":54,"context_line":""},{"line_number":55,"context_line":"What is System Management Mode (SMM)?"},{"line_number":56,"context_line":"-------------------------------------"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Background on different kinds of OVMF builds"},{"line_number":60,"context_line":"--------------------------------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f515b1d_434c2741","line":57,"updated":"2018-01-02 17:31:42.000000000","message":"I presume the above sections are just TODOs?","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6874,"name":"Patrick Uiterwijk","email":"puiterwijk@gmail.com","username":"puiterwijk"},"change_message_id":"51901af3b86f2a61b0f339e7d60fc7aaeef68012","unresolved":false,"context_lines":[{"line_number":104,"context_line":"REST API impact"},{"line_number":105,"context_line":"---------------"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"None."},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"Security impact"},{"line_number":110,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_4c4a63ac","line":107,"updated":"2017-11-24 10:38:51.000000000","message":"I could see the use of always, unconditionally, enabling SMM and secureboot when using UEFI, that part sounds reasonable, but you still need configuration for which keys are going to be acceptable (and enable secureboot). It might be useful to make that an option from the API at the very least.","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"0972943557e392f3169d351fc70e18724fec6176","unresolved":false,"context_lines":[{"line_number":104,"context_line":"REST API impact"},{"line_number":105,"context_line":"---------------"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"None."},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"Security impact"},{"line_number":110,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_4d1b0572","line":107,"in_reply_to":"ff82abbf_4c4a63ac","updated":"2017-11-28 10:39:10.000000000","message":"Yes, this (the configuration of default keys in the UEFI shell) is the important bit that I didn\u0027t write out yet.\n\nMeanwhile, over the last week, we\u0027ve got the OVMF variables (\"VARS\") file generator that\u0027ll take care of it: https://github.com/puiterwijk/qemu-ovmf-secureboot/blob/master/ovmf-vars-generator.py\n\nI have a TODO item to explore integrating that into Nova.\n\nAnd, here I\u0027m looking for some more feedback from other Nova developers who are experienced in the Nova API design.","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"e09c5af4d2e13c1ea189ccfc1c5bc18df45c4c77","unresolved":false,"context_lines":[{"line_number":185,"context_line":"  machine type is supported.  And a minimum QEMU version of at least 2.9"},{"line_number":186,"context_line":"  is required."},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"* Mininum libvirt version of 2.1.0 for the \u0027loader\u0027 / \u0027secure\u0027 attribute "},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Testing"},{"line_number":191,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f515b1d_e8c3f255","line":188,"range":{"start_line":188,"start_character":72,"end_line":188,"end_character":73},"updated":"2017-09-28 18:57:29.000000000","message":"thou hast committed the gravest of crimes, dear sir. thou hast left a trailing space.","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"2360810b80593ee9a26fd1710bc9e2e9de0e33ce","unresolved":false,"context_lines":[{"line_number":185,"context_line":"  machine type is supported.  And a minimum QEMU version of at least 2.9"},{"line_number":186,"context_line":"  is required."},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"* Mininum libvirt version of 2.1.0 for the \u0027loader\u0027 / \u0027secure\u0027 attribute "},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"Testing"},{"line_number":191,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f4e5783_8c4ede6c","line":188,"range":{"start_line":188,"start_character":72,"end_line":188,"end_character":73},"in_reply_to":"7f515b1d_e8c3f255","updated":"2017-10-16 10:52:04.000000000","message":"Hehe, will fix it in the next iteration.  Also hope to remove the \"WIP\" part of it.  This cycle I don\u0027t think I\u0027d have time to bring this to fruition.\n\nBut this spec is on my radar.","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6874,"name":"Patrick Uiterwijk","email":"puiterwijk@gmail.com","username":"puiterwijk"},"change_message_id":"51901af3b86f2a61b0f339e7d60fc7aaeef68012","unresolved":false,"context_lines":[{"line_number":223,"context_line":"* The BIOS boot loader libvirt guest XML attributes:"},{"line_number":224,"context_line":"  https://libvirt.org/formatdomain.html#elementsOSBIOS"},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"* Notes on what exactly is \"VGA arbitration\""},{"line_number":227,"context_line":"  http://vfio.blogspot.be/2014/08/whats-deal-with-vga-arbitration.html"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"* Blog post discussing UEFI and SMM "}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_4c54a321","line":226,"updated":"2017-11-24 10:38:51.000000000","message":"I don\u0027t think that this depends on SMM/SB.","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"0972943557e392f3169d351fc70e18724fec6176","unresolved":false,"context_lines":[{"line_number":223,"context_line":"* The BIOS boot loader libvirt guest XML attributes:"},{"line_number":224,"context_line":"  https://libvirt.org/formatdomain.html#elementsOSBIOS"},{"line_number":225,"context_line":""},{"line_number":226,"context_line":"* Notes on what exactly is \"VGA arbitration\""},{"line_number":227,"context_line":"  http://vfio.blogspot.be/2014/08/whats-deal-with-vga-arbitration.html"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"* Blog post discussing UEFI and SMM "}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_705d8013","line":226,"in_reply_to":"ff82abbf_4c54a321","updated":"2017-11-28 10:39:10.000000000","message":"It doesn\u0027t; I\u0027ll probably remove it.","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6874,"name":"Patrick Uiterwijk","email":"puiterwijk@gmail.com","username":"puiterwijk"},"change_message_id":"51901af3b86f2a61b0f339e7d60fc7aaeef68012","unresolved":false,"context_lines":[{"line_number":226,"context_line":"* Notes on what exactly is \"VGA arbitration\""},{"line_number":227,"context_line":"  http://vfio.blogspot.be/2014/08/whats-deal-with-vga-arbitration.html"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"* Blog post discussing UEFI and SMM "},{"line_number":230,"context_line":"  https://firmwaresecurity.com/2017/07/13/uefismm-stability-and-performance-improvements-in-qemu-2-9-and-edk2ovmf-git-296153c5-included-with-fedora-26/"},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"History"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_6c616705","line":229,"updated":"2017-11-24 10:38:51.000000000","message":"More trailing whitespace :)","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":226,"context_line":"* Notes on what exactly is \"VGA arbitration\""},{"line_number":227,"context_line":"  http://vfio.blogspot.be/2014/08/whats-deal-with-vga-arbitration.html"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"* Blog post discussing UEFI and SMM "},{"line_number":230,"context_line":"  https://firmwaresecurity.com/2017/07/13/uefismm-stability-and-performance-improvements-in-qemu-2-9-and-edk2ovmf-git-296153c5-included-with-fedora-26/"},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"History"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7f515b1d_43754763","line":229,"range":{"start_line":229,"start_character":35,"end_line":229,"end_character":36},"updated":"2018-01-02 17:31:42.000000000","message":"whitespace...","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"0972943557e392f3169d351fc70e18724fec6176","unresolved":false,"context_lines":[{"line_number":226,"context_line":"* Notes on what exactly is \"VGA arbitration\""},{"line_number":227,"context_line":"  http://vfio.blogspot.be/2014/08/whats-deal-with-vga-arbitration.html"},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"* Blog post discussing UEFI and SMM "},{"line_number":230,"context_line":"  https://firmwaresecurity.com/2017/07/13/uefismm-stability-and-performance-improvements-in-qemu-2-9-and-edk2ovmf-git-296153c5-included-with-fedora-26/"},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"History"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff82abbf_30a138f9","line":229,"in_reply_to":"ff82abbf_6c616705","updated":"2017-11-28 10:39:10.000000000","message":"Yep, will fix.","commit_id":"3bbde99c3e39236bf66f4ba2c56503b046d2e743"}],"specs/rocky/approved/ovmf-with-secure-boot-and-smm.rst":[{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":34,"context_line":"is straight-forward to add to Nova\u0027s guest XML configs). Refer to the"},{"line_number":35,"context_line":"following sections for more details, and what needs to be done in"},{"line_number":36,"context_line":"context of Nova to support the Secure Boot for KVM / QEMU guests."},{"line_number":37,"context_line":"(NB: We focus only on x86_64 architecutre and ignore AArch64 for now.)"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"If you\u0027re familiar with this area, you can skip ahead directly to the"},{"line_number":40,"context_line":"\u0027Work Items\u0027 section for design discussion."}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_78b17c8f","line":37,"range":{"start_line":37,"start_character":29,"end_line":37,"end_character":41},"updated":"2018-01-02 17:31:42.000000000","message":"architecture","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":88,"context_line":"required."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"The Secure Boot Feature and the SMM feature stack are orthogonal. You"},{"line_number":91,"context_line":"can build OVMF in all four configurations. However, if you want to allow"},{"line_number":92,"context_line":"trustworthy code in your guests to enable the Secure Boot operational"},{"line_number":93,"context_line":"mode (for protecting itself), and *also* want to prevent malicious code"},{"line_number":94,"context_line":"in your guests from *circumventing* the actual security of the Secure"},{"line_number":95,"context_line":"Boot operational mode, then you have to build *both* features into OVMF."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"NB: Different distributions ship different kinds of builds.  E.g."},{"line_number":98,"context_line":"Fedora ships both variants of OVMF firmware binaries: one without either"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_18363005","line":95,"range":{"start_line":91,"start_character":43,"end_line":95,"end_character":72},"updated":"2018-01-02 17:31:42.000000000","message":"does anyone else think this is kind of silly? I mean, what exactly is the use case for a VM to protect itself but at the same time allow guests to circumvent that security? Doesn\u0027t make any sense to me, frankly.","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":6874,"name":"Patrick Uiterwijk","email":"puiterwijk@gmail.com","username":"puiterwijk"},"change_message_id":"484b883f199ae0bd423ea366d2127fd8cf7f2fd7","unresolved":false,"context_lines":[{"line_number":88,"context_line":"required."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"The Secure Boot Feature and the SMM feature stack are orthogonal. You"},{"line_number":91,"context_line":"can build OVMF in all four configurations. However, if you want to allow"},{"line_number":92,"context_line":"trustworthy code in your guests to enable the Secure Boot operational"},{"line_number":93,"context_line":"mode (for protecting itself), and *also* want to prevent malicious code"},{"line_number":94,"context_line":"in your guests from *circumventing* the actual security of the Secure"},{"line_number":95,"context_line":"Boot operational mode, then you have to build *both* features into OVMF."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"NB: Different distributions ship different kinds of builds.  E.g."},{"line_number":98,"context_line":"Fedora ships both variants of OVMF firmware binaries: one without either"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_3931ac0c","line":95,"range":{"start_line":91,"start_character":43,"end_line":95,"end_character":72},"in_reply_to":"9f91af0f_18363005","updated":"2018-01-03 09:27:57.000000000","message":"Yeah, I think it is somewhat silly. I think the main reason they\u0027re orthogonal is because the actual feature implementations are mostly unrelated.","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"4af013671861994eb0e84c968d9c7b59cd68a848","unresolved":false,"context_lines":[{"line_number":88,"context_line":"required."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"The Secure Boot Feature and the SMM feature stack are orthogonal. You"},{"line_number":91,"context_line":"can build OVMF in all four configurations. However, if you want to allow"},{"line_number":92,"context_line":"trustworthy code in your guests to enable the Secure Boot operational"},{"line_number":93,"context_line":"mode (for protecting itself), and *also* want to prevent malicious code"},{"line_number":94,"context_line":"in your guests from *circumventing* the actual security of the Secure"},{"line_number":95,"context_line":"Boot operational mode, then you have to build *both* features into OVMF."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"NB: Different distributions ship different kinds of builds.  E.g."},{"line_number":98,"context_line":"Fedora ships both variants of OVMF firmware binaries: one without either"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_77173853","line":95,"range":{"start_line":91,"start_character":43,"end_line":95,"end_character":72},"in_reply_to":"9f91af0f_3931ac0c","updated":"2018-01-03 14:57:40.000000000","message":"Well, that\u0027s just implementation leaking out of the user-facing interface then... which is poor design. :)","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"ed70e49c14c6e8572723b8b1a2f353be1f024839","unresolved":false,"context_lines":[{"line_number":88,"context_line":"required."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"The Secure Boot Feature and the SMM feature stack are orthogonal. You"},{"line_number":91,"context_line":"can build OVMF in all four configurations. However, if you want to allow"},{"line_number":92,"context_line":"trustworthy code in your guests to enable the Secure Boot operational"},{"line_number":93,"context_line":"mode (for protecting itself), and *also* want to prevent malicious code"},{"line_number":94,"context_line":"in your guests from *circumventing* the actual security of the Secure"},{"line_number":95,"context_line":"Boot operational mode, then you have to build *both* features into OVMF."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"NB: Different distributions ship different kinds of builds.  E.g."},{"line_number":98,"context_line":"Fedora ships both variants of OVMF firmware binaries: one without either"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_75ece7f2","line":95,"range":{"start_line":91,"start_character":43,"end_line":95,"end_character":72},"in_reply_to":"9f91af0f_77173853","updated":"2018-01-09 14:49:23.000000000","message":"So I clarified with Laszlo, on your remark if there\u0027s really any leakage of implementation detail — there isn\u0027t any.\n\nQuoting Laszlo (with his permission):\n\n    (1) the Secure Boot feature itself is standardized, so the guest OS \n    (and 3rd party UEFI applications / drivers) *are* expected to see\n    whether the UEFI authenticated variables exist at all (i.e. if they\n    can even attempt enrolling certificates and such). So that takes\n    care of one of the dimensions -- it\u0027s not a leaking implementation\n    detail.\n    \n    (2) The second dimension, SMM, is not visible to the OS. It is\n    indeed an implementation detail, but it does not leak to the OS, let\n    alone a human end-user. It is only exposed to the person or utility\n    that *builds* OVMF.","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":127,"context_line":"      - \"/usr/share/OVMF/OVMF_CODE.secboot.fd\" is the firmware binary,"},{"line_number":128,"context_line":"        built with SB+SMM."},{"line_number":129,"context_line":"      - matching variable sstore template is"},{"line_number":130,"context_line":"        \"/usr/share/OVMF/OVMF_VARS.fd\"."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_f8190c88","line":130,"updated":"2018-01-02 17:31:42.000000000","message":"What about Debian derivatives?","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"ed70e49c14c6e8572723b8b1a2f353be1f024839","unresolved":false,"context_lines":[{"line_number":127,"context_line":"      - \"/usr/share/OVMF/OVMF_CODE.secboot.fd\" is the firmware binary,"},{"line_number":128,"context_line":"        built with SB+SMM."},{"line_number":129,"context_line":"      - matching variable sstore template is"},{"line_number":130,"context_line":"        \"/usr/share/OVMF/OVMF_VARS.fd\"."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_1538fb9d","line":130,"in_reply_to":"9f91af0f_170eec3a","updated":"2018-01-09 14:49:23.000000000","message":"I meant to spell that out (about Debian-variants), but missed to do so.","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"4af013671861994eb0e84c968d9c7b59cd68a848","unresolved":false,"context_lines":[{"line_number":127,"context_line":"      - \"/usr/share/OVMF/OVMF_CODE.secboot.fd\" is the firmware binary,"},{"line_number":128,"context_line":"        built with SB+SMM."},{"line_number":129,"context_line":"      - matching variable sstore template is"},{"line_number":130,"context_line":"        \"/usr/share/OVMF/OVMF_VARS.fd\"."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_170eec3a","line":130,"in_reply_to":"9f91af0f_ccab20d4","updated":"2018-01-03 14:57:40.000000000","message":"gotcha, thanks.","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":6874,"name":"Patrick Uiterwijk","email":"puiterwijk@gmail.com","username":"puiterwijk"},"change_message_id":"484b883f199ae0bd423ea366d2127fd8cf7f2fd7","unresolved":false,"context_lines":[{"line_number":127,"context_line":"      - \"/usr/share/OVMF/OVMF_CODE.secboot.fd\" is the firmware binary,"},{"line_number":128,"context_line":"        built with SB+SMM."},{"line_number":129,"context_line":"      - matching variable sstore template is"},{"line_number":130,"context_line":"        \"/usr/share/OVMF/OVMF_VARS.fd\"."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_ccab20d4","line":130,"in_reply_to":"9f91af0f_f8190c88","updated":"2018-01-03 09:27:57.000000000","message":"Supposedly, all the OVMF binaries shipped by Debian have secureboot enabled.","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":6874,"name":"Patrick Uiterwijk","email":"puiterwijk@gmail.com","username":"puiterwijk"},"change_message_id":"484b883f199ae0bd423ea366d2127fd8cf7f2fd7","unresolved":false,"context_lines":[{"line_number":144,"context_line":"---------------"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"None yet.  Need Opinion: I\u0027m not quite sure if we should provide an"},{"line_number":147,"context_line":"option via the API, as to *which* signing keys will be acceptable (and"},{"line_number":148,"context_line":"will let one enable Secure Boot)."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_8cb51834","line":147,"updated":"2018-01-03 09:27:57.000000000","message":"I do think this should be API controlled, or at least the admin should be able to indicate enabling and keyset somehow","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"16f3e259deca854b59460679a8939ff85e780782","unresolved":false,"context_lines":[{"line_number":144,"context_line":"---------------"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"None yet.  Need Opinion: I\u0027m not quite sure if we should provide an"},{"line_number":147,"context_line":"option via the API, as to *which* signing keys will be acceptable (and"},{"line_number":148,"context_line":"will let one enable Secure Boot)."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7f96bb07_3969d824","line":147,"in_reply_to":"9f91af0f_0b269cb8","updated":"2018-01-11 00:41:03.000000000","message":"yes. I don\u0027t believe they\u0027ve changed in 3+ years.","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"4af013671861994eb0e84c968d9c7b59cd68a848","unresolved":false,"context_lines":[{"line_number":144,"context_line":"---------------"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"None yet.  Need Opinion: I\u0027m not quite sure if we should provide an"},{"line_number":147,"context_line":"option via the API, as to *which* signing keys will be acceptable (and"},{"line_number":148,"context_line":"will let one enable Secure Boot)."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_fa456d44","line":147,"in_reply_to":"9f91af0f_8cb51834","updated":"2018-01-03 14:57:40.000000000","message":"What about metadata keys associated with the image? Glance has this concept of protected (from end-user changes) properties and those might be a good fit here?","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"ed70e49c14c6e8572723b8b1a2f353be1f024839","unresolved":false,"context_lines":[{"line_number":144,"context_line":"---------------"},{"line_number":145,"context_line":""},{"line_number":146,"context_line":"None yet.  Need Opinion: I\u0027m not quite sure if we should provide an"},{"line_number":147,"context_line":"option via the API, as to *which* signing keys will be acceptable (and"},{"line_number":148,"context_line":"will let one enable Secure Boot)."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Security impact"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_0b269cb8","line":147,"in_reply_to":"9f91af0f_fa456d44","updated":"2018-01-09 14:49:23.000000000","message":"I was also thinking of Glance metadata properties.\n\nIs this the latest document on \"protected properties\"?:\n\nhttps://wiki.openstack.org/wiki/Glance-property-protections","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":253,"context_line":""},{"line_number":254,"context_line":"    TODO / Need Opinions:"},{"line_number":255,"context_line":""},{"line_number":256,"context_line":"     - When using UEFI / OVMF, it maybe fine to unconditionally enable"},{"line_number":257,"context_line":"       SMM and Secure Boot. But we should explore how to expose in the"},{"line_number":258,"context_line":"       Nova API _which_ keys are going to be acceptable (and enable SB)."},{"line_number":259,"context_line":"       But *should* we do it?"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_538edb78","line":256,"range":{"start_line":256,"start_character":34,"end_line":256,"end_character":39},"updated":"2018-01-02 17:31:42.000000000","message":"may be","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":258,"context_line":"       Nova API _which_ keys are going to be acceptable (and enable SB)."},{"line_number":259,"context_line":"       But *should* we do it?"},{"line_number":260,"context_line":""},{"line_number":261,"context_line":"     - Workout ways to integreate the external Python tool,"},{"line_number":262,"context_line":"       `ovmf-vars-generator` into Nova."},{"line_number":263,"context_line":""},{"line_number":264,"context_line":"(4) One of the tricky and messy parts. Ensure we detect the firmware"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_b3f2c705","line":261,"range":{"start_line":261,"start_character":7,"end_line":261,"end_character":14},"updated":"2018-01-02 17:31:42.000000000","message":"Work out","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":258,"context_line":"       Nova API _which_ keys are going to be acceptable (and enable SB)."},{"line_number":259,"context_line":"       But *should* we do it?"},{"line_number":260,"context_line":""},{"line_number":261,"context_line":"     - Workout ways to integreate the external Python tool,"},{"line_number":262,"context_line":"       `ovmf-vars-generator` into Nova."},{"line_number":263,"context_line":""},{"line_number":264,"context_line":"(4) One of the tricky and messy parts. Ensure we detect the firmware"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_13ee1322","line":261,"range":{"start_line":261,"start_character":23,"end_line":261,"end_character":33},"updated":"2018-01-02 17:31:42.000000000","message":"integrate","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"4905912ef9c01b92c86d41ae05f69c4a7dd5c8bf","unresolved":false,"context_lines":[{"line_number":265,"context_line":"    OVMF path names. Because as noted earlier, OVMF ships with different"},{"line_number":266,"context_line":"    kinds of builds."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"    An approach is to use libvirt\u0027s getDomainCapabilities() API.  Then,"},{"line_number":269,"context_line":"    we can make an `xpath` query as following to detect the binary path"},{"line_number":270,"context_line":"    names::"},{"line_number":271,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fdfeff1_ee24680f","line":268,"range":{"start_line":268,"start_character":4,"end_line":268,"end_character":63},"updated":"2019-02-26 10:42:39.000000000","message":"Worth mentioning that I have submitted https://review.openstack.org/#/c/633855/ which adds support for invoking getDomainCapabilities() and partially parsing the returned XML, so if that gets merged then I\u0027ve saved you a little bit of work here :-)  You would just need to flesh out the XML tree parsing a bit further.","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"6d241c0ae1509cacbded90d021c5c709dd5a59d1","unresolved":false,"context_lines":[{"line_number":265,"context_line":"    OVMF path names. Because as noted earlier, OVMF ships with different"},{"line_number":266,"context_line":"    kinds of builds."},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"    An approach is to use libvirt\u0027s getDomainCapabilities() API.  Then,"},{"line_number":269,"context_line":"    we can make an `xpath` query as following to detect the binary path"},{"line_number":270,"context_line":"    names::"},{"line_number":271,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9fdfeff1_8f627115","line":268,"range":{"start_line":268,"start_character":4,"end_line":268,"end_character":63},"in_reply_to":"9fdfeff1_ee24680f","updated":"2019-02-26 16:33:55.000000000","message":"Yes, indeed.  Thanks for that! :-)","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":293,"context_line":"    various projects who use OVMF are all inventing slightly different"},{"line_number":294,"context_line":"    ways to do it.  To that end there\u0027s an upstream libvirt bug(+)"},{"line_number":295,"context_line":"    from a couple of years ago to to simplify this.  Daniel Berrange had"},{"line_number":296,"context_line":"    a POC upstream implementation[*].  However, he reached to the"},{"line_number":297,"context_line":"    conclusion that it is a flawed idea."},{"line_number":298,"context_line":""},{"line_number":299,"context_line":"    [+] https://bugzilla.redhat.com/show_bug.cgi?id\u003d1295146 -- RFE:"},{"line_number":300,"context_line":"          provide a bios\u003duefi XML convenience option"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_1365b3b5","line":297,"range":{"start_line":296,"start_character":38,"end_line":297,"end_character":40},"updated":"2018-01-02 17:31:42.000000000","message":"that *what* is a flawed idea? the idea of trying to simplify setting OVMF configuration options? or the idea of trying to standardize what distros were doing differently in using OVMF? or something entirely different?","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"ed70e49c14c6e8572723b8b1a2f353be1f024839","unresolved":false,"context_lines":[{"line_number":293,"context_line":"    various projects who use OVMF are all inventing slightly different"},{"line_number":294,"context_line":"    ways to do it.  To that end there\u0027s an upstream libvirt bug(+)"},{"line_number":295,"context_line":"    from a couple of years ago to to simplify this.  Daniel Berrange had"},{"line_number":296,"context_line":"    a POC upstream implementation[*].  However, he reached to the"},{"line_number":297,"context_line":"    conclusion that it is a flawed idea."},{"line_number":298,"context_line":""},{"line_number":299,"context_line":"    [+] https://bugzilla.redhat.com/show_bug.cgi?id\u003d1295146 -- RFE:"},{"line_number":300,"context_line":"          provide a bios\u003duefi XML convenience option"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_a6de7d0e","line":297,"range":{"start_line":296,"start_character":38,"end_line":297,"end_character":40},"in_reply_to":"9f91af0f_1365b3b5","updated":"2018-01-09 14:49:23.000000000","message":"That his implementation approach was flawed.  And suggested an alternative way (which requires changes to libvirt, and potentially QEMU):\n\n    We need to do what has been loosely discussed in the past.  For each\n    firmware file we need a metadata file in a well defined location eg\n    /usr/share/qemu/bios/  that lists stuff like:\n\n     - Path to the binary\n     - Path to the pre-built \u0027vars\u0027 file (if any)\n     - Support architectures\n     - Associated QEMU feature flags (secure boot)\n\n    Libvirt can read these metadata files and then pick the correct \n    firmware image based on the settings for the guest.\n\n    Essentially QEMU would define the file format, and provide metadata\n    files from any ROMs it ships directly.  If vendors ship extra ROMs\n    like OVMF etc the vendor (disto) should provide suitable metadata\n    files).","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":312,"context_line":"    TODO / Need Opinions:"},{"line_number":313,"context_line":""},{"line_number":314,"context_line":"     - Should we introduce a *new* metadata property for KVM / QEMU"},{"line_number":315,"context_line":"       guests? This xounds clunky. We should be able to use reuse the"},{"line_number":316,"context_line":"       single metadata property: \u0027os_secure_boot\u0027, and depending on the"},{"line_number":317,"context_line":"       hypervisor being used, set the value appropriately."},{"line_number":318,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_7373df81","line":315,"range":{"start_line":315,"start_character":20,"end_line":315,"end_character":26},"updated":"2018-01-02 17:31:42.000000000","message":"sounds","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":312,"context_line":"    TODO / Need Opinions:"},{"line_number":313,"context_line":""},{"line_number":314,"context_line":"     - Should we introduce a *new* metadata property for KVM / QEMU"},{"line_number":315,"context_line":"       guests? This xounds clunky. We should be able to use reuse the"},{"line_number":316,"context_line":"       single metadata property: \u0027os_secure_boot\u0027, and depending on the"},{"line_number":317,"context_line":"       hypervisor being used, set the value appropriately."},{"line_number":318,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_b30e47e3","line":315,"range":{"start_line":315,"start_character":35,"end_line":315,"end_character":65},"updated":"2018-01-02 17:31:42.000000000","message":"this would definitely be my preference. there\u0027s no reason to expose implementation details (and everything about OVMF is an implementation detail, frankly) about *how* the secure boot is obtained.","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"86eb4fae807ecc1f236242b253319161c6d101d7","unresolved":false,"context_lines":[{"line_number":330,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"This feature should be possible to test in the upstream Gate"},{"line_number":333,"context_line":"environment, where the Nova instance should be able to boot an OVMF"},{"line_number":334,"context_line":"(built with SB + SMM) enabled guest.  And also verify in `dmesg` that"},{"line_number":335,"context_line":"Secure Boot is *actually* enabled."},{"line_number":336,"context_line":""},{"line_number":337,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_330237b6","line":334,"range":{"start_line":333,"start_character":55,"end_line":334,"end_character":35},"updated":"2018-01-02 17:31:42.000000000","message":"who\u0027s going to create (and importantly, MAINTAIN) this new guest image dependency for the gate?","commit_id":"918cfb78a27871265612b3fee98676523a007323"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"ed70e49c14c6e8572723b8b1a2f353be1f024839","unresolved":false,"context_lines":[{"line_number":330,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":331,"context_line":""},{"line_number":332,"context_line":"This feature should be possible to test in the upstream Gate"},{"line_number":333,"context_line":"environment, where the Nova instance should be able to boot an OVMF"},{"line_number":334,"context_line":"(built with SB + SMM) enabled guest.  And also verify in `dmesg` that"},{"line_number":335,"context_line":"Secure Boot is *actually* enabled."},{"line_number":336,"context_line":""},{"line_number":337,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"9f91af0f_66fdd56c","line":334,"range":{"start_line":333,"start_character":55,"end_line":334,"end_character":35},"in_reply_to":"9f91af0f_330237b6","updated":"2018-01-09 14:49:23.000000000","message":"I can help create the image.  And near as I see, there isn\u0027t a whole lot of maintenance involved here.","commit_id":"918cfb78a27871265612b3fee98676523a007323"}],"specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.rst":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"b8312a22e0fe221cb8e6713214edf139da5d331f","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Currently Nova does not support UEFI Secure Boot (i.e. the goal of which"},{"line_number":20,"context_line":"is to: \"make sure no unsigned (kernel) code runs on the machine\") for"},{"line_number":21,"context_line":"QEMU / KVM Virutal Machines. This spec aims to add that. (NB: Support"},{"line_number":22,"context_line":"for Hyper-V in Nova was added in commit: 29dab99 -- \"Hyper-V: Adds"},{"line_number":23,"context_line":"Hyper-V UEFI Secure Boot\")"},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5fc1f717_87b80375","line":21,"range":{"start_line":21,"start_character":11,"end_line":21,"end_character":18},"updated":"2019-04-09 15:04:24.000000000","message":"virtual","commit_id":"a1380a054b0c374686a8d9364b51614f1f1ee698"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"b8312a22e0fe221cb8e6713214edf139da5d331f","unresolved":false,"context_lines":[{"line_number":162,"context_line":"Consider if we should allow a way via to API, as to *which* signing keys"},{"line_number":163,"context_line":"will be acceptable (and allow one of them to enable Secure Boot)."},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"Also consider if we should take into accout Glance\u0027s \"protected"},{"line_number":166,"context_line":"properties\"."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"5fc1f717_22cb3d53","line":165,"range":{"start_line":165,"start_character":37,"end_line":165,"end_character":43},"updated":"2019-04-09 15:04:24.000000000","message":"account","commit_id":"a1380a054b0c374686a8d9364b51614f1f1ee698"},{"author":{"_account_id":7634,"name":"Takashi Natsume","email":"takanattie@gmail.com","username":"natsumet"},"change_message_id":"51ecf35376c36ad607e333157dd8c038347d22f9","unresolved":false,"context_lines":[{"line_number":294,"context_line":"    and fixes the above mentioned problem by providing a robust"},{"line_number":295,"context_line":"    interface.  As in, libvirt can now pick up the *correct* OVMF"},{"line_number":296,"context_line":"    binary, with Secure Boot (SB) and System Management Mode (SMM)"},{"line_number":297,"context_line":"    enabled, with a convenient XML config:"},{"line_number":298,"context_line":""},{"line_number":299,"context_line":"        \u003cos firmware\u003d\u0027efi\u0027\u003e"},{"line_number":300,"context_line":"          \u003cloader secure\u003d\u0027yes\u0027/\u003e"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5fc1f717_c1f6575e","line":297,"range":{"start_line":297,"start_character":41,"end_line":297,"end_character":42},"updated":"2019-04-04 06:47:47.000000000","message":"::","commit_id":"a1380a054b0c374686a8d9364b51614f1f1ee698"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":13,"context_line":"Problem description"},{"line_number":14,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Nova does not support UEFI Secure Boot (i.e. the goal of which is to:"},{"line_number":17,"context_line":"\"make sure no unsigned (kernel) code runs on the machine\") for QEMU and"},{"line_number":18,"context_line":"and KVM guests.  Secure Boot protects guests from boot-time malware, and"},{"line_number":19,"context_line":"provides a trusted boot path."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_20e2bd02","line":16,"range":{"start_line":16,"start_character":0,"end_line":16,"end_character":4},"updated":"2019-04-16 09:57:53.000000000","message":"the nova libvirt driver.\n\nthe hyperv driver does support secure boot","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d129c2557cd9ff3d00b560d86b6ad6cb006eb992","unresolved":false,"context_lines":[{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Nova does not support UEFI Secure Boot (i.e. the goal of which is to:"},{"line_number":17,"context_line":"\"make sure no unsigned (kernel) code runs on the machine\") for QEMU and"},{"line_number":18,"context_line":"and KVM guests.  Secure Boot protects guests from boot-time malware, and"},{"line_number":19,"context_line":"provides a trusted boot path."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Currently, Nova just checks for the OVMF (the open source implementation"},{"line_number":22,"context_line":"of UEFI) binary file\u0027s path, hard-coded in the variable"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_04c27c34","line":19,"range":{"start_line":18,"start_character":17,"end_line":19,"end_character":29},"updated":"2019-04-16 14:00:53.000000000","message":"From reading some of the (very dense) literature included as links at the bottom of this spec, I see that the only real use case for this is actually to support development and testing of UEFI Secure Boot itself.\n\nIn other words, it\u0027s kind of a tautological use case: we need to support Secure Boot in UEFI for VMs so we can develop and test Secure Boot for UEFI.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"2e7194d98b37c549ea200f7f014fd1c9171eef34","unresolved":false,"context_lines":[{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Nova does not support UEFI Secure Boot (i.e. the goal of which is to:"},{"line_number":17,"context_line":"\"make sure no unsigned (kernel) code runs on the machine\") for QEMU and"},{"line_number":18,"context_line":"and KVM guests.  Secure Boot protects guests from boot-time malware, and"},{"line_number":19,"context_line":"provides a trusted boot path."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Currently, Nova just checks for the OVMF (the open source implementation"},{"line_number":22,"context_line":"of UEFI) binary file\u0027s path, hard-coded in the variable"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_e0701cdf","line":19,"range":{"start_line":18,"start_character":17,"end_line":19,"end_character":29},"in_reply_to":"3fce034c_04c27c34","updated":"2019-04-17 08:01:13.000000000","message":"\u003e From reading some of the (very dense) literature included as links\n \u003e at the bottom of this spec, I see that the only real use case for\n \u003e this is actually to support development and testing of UEFI Secure\n \u003e Boot itself.\n\nIncorrect. :-) What you say is *one* of the use cases.  The primary use case, as Patrick explains below, is to protect the instance from malware in the guest boot chain, or to borrow Ubuntu Wiki\u0027s[1] words: \n\n\"UEFI Secure boot is a verification mechanism for ensuring that code launched by firmware is trusted.\n\n\"Proper, secure use of UEFI Secure Boot requires that each binary loaded at boot is validated against known keys, located in firmware, that denote trusted vendors and sources for the binaries, or trusted specific binaries that can be identified via cryptographic hashing.\"\n\n[1] https://wiki.ubuntu.com/UEFI/SecureBoot\n\n \u003e \n \u003e In other words, it\u0027s kind of a tautological use case: we need to\n \u003e support Secure Boot in UEFI for VMs so we can develop and test\n \u003e Secure Boot for UEFI.\n\nAgain, that\u0027s not the *only* use case.  Refer my response above, and Patrick\u0027s below.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6874,"name":"Patrick Uiterwijk","email":"puiterwijk@gmail.com","username":"puiterwijk"},"change_message_id":"dd46918e37af7f58823894ec489da2a53ab44ce0","unresolved":false,"context_lines":[{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Nova does not support UEFI Secure Boot (i.e. the goal of which is to:"},{"line_number":17,"context_line":"\"make sure no unsigned (kernel) code runs on the machine\") for QEMU and"},{"line_number":18,"context_line":"and KVM guests.  Secure Boot protects guests from boot-time malware, and"},{"line_number":19,"context_line":"provides a trusted boot path."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Currently, Nova just checks for the OVMF (the open source implementation"},{"line_number":22,"context_line":"of UEFI) binary file\u0027s path, hard-coded in the variable"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_e05fbc6f","line":19,"range":{"start_line":18,"start_character":17,"end_line":19,"end_character":29},"in_reply_to":"3fce034c_04c27c34","updated":"2019-04-17 07:36:51.000000000","message":"While I personally think that enabling Secure Boot for the sake of SB development is not crazy in itself, the main reason for Secure Boot is to protect against things like malware in the boot chain or other kernel-mode code like modules.\n\nSo enabling Secure Boot in UEFI for VMs will hopefully allow users to enforce that the boot and ring 0 code in their VMs comes from a known source.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"103f0831f87e2c581fd05927ca5b7de4ab80520a","unresolved":false,"context_lines":[{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Nova does not support UEFI Secure Boot (i.e. the goal of which is to:"},{"line_number":17,"context_line":"\"make sure no unsigned (kernel) code runs on the machine\") for QEMU and"},{"line_number":18,"context_line":"and KVM guests.  Secure Boot protects guests from boot-time malware, and"},{"line_number":19,"context_line":"provides a trusted boot path."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Currently, Nova just checks for the OVMF (the open source implementation"},{"line_number":22,"context_line":"of UEFI) binary file\u0027s path, hard-coded in the variable"}],"source_content_type":"text/x-rst","patch_set":8,"id":"ffb9cba7_7cabbad5","line":19,"range":{"start_line":18,"start_character":17,"end_line":19,"end_character":29},"in_reply_to":"3fce034c_a0ff3ba9","updated":"2019-04-24 10:05:03.000000000","message":"It\u0027s actually a very good question.\n\nOut-of-the-box, there is no need to setup a certificate authority.  Almost all Linux distributions that matter ship a convenient \"variable store\" (VARS) file template with the default Microsoft keys enrolled in them.  And these keys suffice to boot released versions of the said popular Linux distributions, Windows 8 and Windows Server 2012 R2, in Secure Boot mode.\n\nIf you want to setup a custom CA, you need to enroll your own keys, instead of Microsoft\u0027s keys.  That is a laborious process, and is out-of-scope for this spec.  Maybe I can mention it somewhere in the documentation\n\n        - - -\n\nFWIW, Ubuntu even uses and ships a script we wrote (called `ovmf-vars-generator`) to create the OVMF \"variable store\" (VARS) file template with the default MS keys enrolled.  This tool can be used when your distribution doesn\u0027t yet ship a VARS file enrolled with the said default keys.  I showed the example invocation (only one invocation needed) here in my response to Andrey Volkov: \n\nhttps://review.opendev.org/#/c/506720/10/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.rst@263\n        - - -\n\nAdditional info: To understand Ubuntu\u0027s \"chain of trust\", read this section here: https://wiki.ubuntu.com/UEFI/SecureBoot/Testing#Shim_bootloader_signed_with_Microsoft_key","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"102474a9542e16c4d3d8420de11a7b509001468c","unresolved":false,"context_lines":[{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Nova does not support UEFI Secure Boot (i.e. the goal of which is to:"},{"line_number":17,"context_line":"\"make sure no unsigned (kernel) code runs on the machine\") for QEMU and"},{"line_number":18,"context_line":"and KVM guests.  Secure Boot protects guests from boot-time malware, and"},{"line_number":19,"context_line":"provides a trusted boot path."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Currently, Nova just checks for the OVMF (the open source implementation"},{"line_number":22,"context_line":"of UEFI) binary file\u0027s path, hard-coded in the variable"}],"source_content_type":"text/x-rst","patch_set":8,"id":"ffb9cba7_25cb9e1e","line":19,"range":{"start_line":18,"start_character":17,"end_line":19,"end_character":29},"in_reply_to":"3fce034c_a0ff3ba9","updated":"2019-04-26 09:18:52.000000000","message":"[...]\n\n \u003e I don\u0027t see any discussion of what will need to be added to nova (or\n \u003e some other OpenStack component?) to set up the certificate\n \u003e authority from which the virtual firmware in the guest images will\n \u003e be verified. Is the setup of a certificate authority left as an\n \u003e exercise for the operator or was that in a different spec\n \u003e somewhere? Or is my question stupid?\n\nAlso: if you have a Nova instance that references \"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd\" as its firmware binary, then your concern about that file\u0027s integrity amounts to doubting the compute host\u0027s filesystem integrity.\n\nSo I (and the OVMF maintainer, too) don\u0027t see what it is in Google\u0027s cloud that makes such a feature necessary or attractive.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"38ba7f9a905bdf378b08f93523274ccfa1f6906d","unresolved":false,"context_lines":[{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Nova does not support UEFI Secure Boot (i.e. the goal of which is to:"},{"line_number":17,"context_line":"\"make sure no unsigned (kernel) code runs on the machine\") for QEMU and"},{"line_number":18,"context_line":"and KVM guests.  Secure Boot protects guests from boot-time malware, and"},{"line_number":19,"context_line":"provides a trusted boot path."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Currently, Nova just checks for the OVMF (the open source implementation"},{"line_number":22,"context_line":"of UEFI) binary file\u0027s path, hard-coded in the variable"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_a0ff3ba9","line":19,"range":{"start_line":18,"start_character":17,"end_line":19,"end_character":29},"in_reply_to":"3fce034c_e0701cdf","updated":"2019-04-19 12:12:12.000000000","message":"Guys, I didn\u0027t -1 the spec. I was just noting something that popped into my head while reading the underlying literature. Forgive me for wanting to fully understand this. :)\n\nInterestingly, Google just released their \"Shielded VMs\" functionality yesterday, and it looks like Secure Boot is one of the options for these Shielded VMs:\n\nhttps://cloud.google.com/security/shielded-cloud/shielded-vm#secure-boot\n\nFrom reading their documentation:\n\n\"Shielded VM instances run firmware which is signed and verified using Google\u0027s Certificate Authority, ensuring that the instance\u0027s firmware is unmodified and establishing the root of trust for Secure Boot.\"\n\nThis spec goes into quite a bit of detail about the  proposed implementation of enabling Secure Boot for QEMU/KVM guests, but I don\u0027t see any discussion of what will need to be added to nova (or some other OpenStack component?) to set up the certificate authority from which the virtual firmware in the guest images will be verified. Is the setup of a certificate authority left as an exercise for the operator or was that in a different spec somewhere? Or is my question stupid?","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c250e1efdf1cc85046efbfd96b8b9935f9a583a3","unresolved":false,"context_lines":[{"line_number":19,"context_line":"provides a trusted boot path."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Currently, Nova just checks for the OVMF (the open source implementation"},{"line_number":22,"context_line":"of UEFI) binary file\u0027s path, hard-coded in the variable"},{"line_number":23,"context_line":"``DEFAULT_UEFI_LOADER_PATH``::"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"    [...]"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5fc1f717_e21c55c3","line":22,"range":{"start_line":22,"start_character":3,"end_line":22,"end_character":7},"updated":"2019-04-09 15:10:12.000000000","message":"UEFI for virtual machines","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":29,"context_line":"    }"},{"line_number":30,"context_line":"    [...]"},{"line_number":31,"context_line":""},{"line_number":32,"context_line":"That is incomplete, not robust, and most importantly, while not"},{"line_number":33,"context_line":"providing Secure Boot, it can give a *false* sense of security."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Fix that by providing support for Secure that is *actually* secure"},{"line_number":36,"context_line":"requires.  Refer to the :ref:`below \u003cProposed change\u003e` section further"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_c09e5962","line":33,"range":{"start_line":32,"start_character":0,"end_line":33,"end_character":63},"updated":"2019-04-16 09:57:53.000000000","message":"the existing code was not added for secure boot.\n\nit was added to provide generic UEFI boot.\nthere is currently 0 support for secure boot in the libvirt driver and we have never suggested that there is.\n\nthe libvirt dirver simply supprot uefi boot.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c250e1efdf1cc85046efbfd96b8b9935f9a583a3","unresolved":false,"context_lines":[{"line_number":32,"context_line":"That is incomplete, not robust, and most importantly, while not"},{"line_number":33,"context_line":"providing Secure Boot, it can give a *false* sense of security."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Fix that by providing support for Secure that is *actually* secure"},{"line_number":36,"context_line":"requires.  Refer to the :ref:`below \u003cProposed change\u003e` section further"},{"line_number":37,"context_line":"below for what needs to be done to support the Secure Boot for KVM /"},{"line_number":38,"context_line":"QEMU guests.  (In this spec, we focus mainly on ``x86_64``"},{"line_number":39,"context_line":"architecture.)"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5fc1f717_a2ef2d85","line":36,"range":{"start_line":35,"start_character":0,"end_line":36,"end_character":8},"updated":"2019-04-09 15:10:12.000000000","message":"This sentence doesn\u0027t make any sense and it\u0027s pretty crucial. I assume you meant:\n\n  Fix that by providing support for Secure Boot that\n  is *actually* secure","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"2e7194d98b37c549ea200f7f014fd1c9171eef34","unresolved":false,"context_lines":[{"line_number":32,"context_line":"That is incomplete, not robust, and most importantly, while not"},{"line_number":33,"context_line":"providing Secure Boot, it can give a *false* sense of security."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Fix that by providing support for Secure that is *actually* secure"},{"line_number":36,"context_line":"requires.  Refer to the :ref:`below \u003cProposed change\u003e` section further"},{"line_number":37,"context_line":"below for what needs to be done to support the Secure Boot for KVM /"},{"line_number":38,"context_line":"QEMU guests.  (In this spec, we focus mainly on ``x86_64``"},{"line_number":39,"context_line":"architecture.)"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_c3572a02","line":36,"range":{"start_line":35,"start_character":0,"end_line":36,"end_character":8},"in_reply_to":"3fce034c_04d7dcef","updated":"2019-04-17 08:01:13.000000000","message":"It\u0027s already addressed in later versions.  (PS-11 upcoming.)","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":32,"context_line":"That is incomplete, not robust, and most importantly, while not"},{"line_number":33,"context_line":"providing Secure Boot, it can give a *false* sense of security."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Fix that by providing support for Secure that is *actually* secure"},{"line_number":36,"context_line":"requires.  Refer to the :ref:`below \u003cProposed change\u003e` section further"},{"line_number":37,"context_line":"below for what needs to be done to support the Secure Boot for KVM /"},{"line_number":38,"context_line":"QEMU guests.  (In this spec, we focus mainly on ``x86_64``"},{"line_number":39,"context_line":"architecture.)"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_a0178da3","line":36,"range":{"start_line":35,"start_character":0,"end_line":36,"end_character":8},"in_reply_to":"3fce034c_8a718ae3","updated":"2019-04-16 09:57:53.000000000","message":"Fix implies secure boot is broken which is incorrect.\nit has never been supported for libvirt.\n\nthe existing uefi boot was added by \n\nhttps://github.com/openstack/nova/commit/9e2dfb61ed1c8f8c891c34ca4da2b46b69abd661#diff-eacc3a31286fee020c9137ecd26a67c8\n\nwhich make no reference to secure boot.\n\nthis spec is propose extending the existing uefi boot to also support secure boot. please remove any implication that this was previously supported by the nova libvirt driver.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"d0e453f26a9e11e14f4175f9c0fa5315bcb11aa8","unresolved":false,"context_lines":[{"line_number":32,"context_line":"That is incomplete, not robust, and most importantly, while not"},{"line_number":33,"context_line":"providing Secure Boot, it can give a *false* sense of security."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Fix that by providing support for Secure that is *actually* secure"},{"line_number":36,"context_line":"requires.  Refer to the :ref:`below \u003cProposed change\u003e` section further"},{"line_number":37,"context_line":"below for what needs to be done to support the Secure Boot for KVM /"},{"line_number":38,"context_line":"QEMU guests.  (In this spec, we focus mainly on ``x86_64``"},{"line_number":39,"context_line":"architecture.)"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_8a718ae3","line":36,"range":{"start_line":35,"start_character":0,"end_line":36,"end_character":8},"in_reply_to":"5fc1f717_a2ef2d85","updated":"2019-04-12 09:27:04.000000000","message":"Will fix.  The \"requires\" was spurious.  (Missed to clean it up while rewriting the sentence.)","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d129c2557cd9ff3d00b560d86b6ad6cb006eb992","unresolved":false,"context_lines":[{"line_number":32,"context_line":"That is incomplete, not robust, and most importantly, while not"},{"line_number":33,"context_line":"providing Secure Boot, it can give a *false* sense of security."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Fix that by providing support for Secure that is *actually* secure"},{"line_number":36,"context_line":"requires.  Refer to the :ref:`below \u003cProposed change\u003e` section further"},{"line_number":37,"context_line":"below for what needs to be done to support the Secure Boot for KVM /"},{"line_number":38,"context_line":"QEMU guests.  (In this spec, we focus mainly on ``x86_64``"},{"line_number":39,"context_line":"architecture.)"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_04d7dcef","line":36,"range":{"start_line":35,"start_character":0,"end_line":36,"end_character":8},"in_reply_to":"5fc1f717_a2ef2d85","updated":"2019-04-16 14:00:53.000000000","message":"agree with Stephen\u0027s suggestion here.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":38,"context_line":"QEMU guests.  (In this spec, we focus mainly on ``x86_64``"},{"line_number":39,"context_line":"architecture.)"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"NB: Nova already supports UEFI boot [1]_, but not UEFI Secure Boot.  And"},{"line_number":42,"context_line":"support for Hyper-V in Nova was added in commit: 29dab99 -- \"Hyper-V:"},{"line_number":43,"context_line":"Adds Hyper-V UEFI Secure Boot\" [2]_."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_605f6572","line":42,"range":{"start_line":41,"start_character":69,"end_line":42,"end_character":28},"updated":"2019-04-16 09:57:53.000000000","message":"this intially reads as if support for hyperv as a hypervior was added in that commit not support for secure boot was added to the hyperv dirve in ...","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":74,"context_line":""},{"line_number":75,"context_line":".. _`Proposed change`:"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Proposed change"},{"line_number":78,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"To allow Secure Boot (and for it to be _actually_ secure) for KVM and"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_20095d30","line":77,"range":{"start_line":77,"start_character":0,"end_line":77,"end_character":15},"updated":"2019-04-16 09:57:53.000000000","message":"please state clearly that secure boot will be enable/disabled using the existing \n\nimage metadata key \"os_secure_boot\" and flavor extra spec\n\"os:secure_boot\" key to ensure there is no divergence between the hyperv driver and libvirt.\n\nthe allowd values are\n\n\"required\", \"disabled\" or \"optional\"\n\nhttps://github.com/openstack/nova/blob/7ed4b024582331e3fce45d7bede06d51e13a2c45/nova/objects/fields.py#L492-L498\n\naddtionally can we define a COMPUTE_UEFI_SECURE_BOOT\ntrait to indicate the hypervior support booting gues with secure boot.  this spec should also cover extending the hyperv and libvirt virt dirvers to report that trait on the compute node RP.\n\ngiven the libvirt/qemu requirements later i think this will be needed to not result in lot of rescdules.\n\nsetting os:secure_boot\u003drequired should ideally result in the trait being added automatically","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":77,"context_line":"Proposed change"},{"line_number":78,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"To allow Secure Boot (and for it to be _actually_ secure) for KVM and"},{"line_number":81,"context_line":"QEMU guests, we need the following three main things in place:"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"- Allow Nova to configure Secure Management Mode (SMM) feature for"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_40ea6975","line":80,"range":{"start_line":80,"start_character":21,"end_line":80,"end_character":57},"updated":"2019-04-16 09:57:53.000000000","message":"again this is implying that nova and sepcifcally the nova libvirt dirver supported an insecure form of secure boot.\n\nthat is incorrect so please remove this or rephase to remove that implication","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":128,"context_line":"About different OVMF binary and variable store pathnames"},{"line_number":129,"context_line":"--------------------------------------------------------"},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"This is one of the tricky parts; but good news: the libvirt release 5.2"},{"line_number":132,"context_line":"fixes this for good — by providing an interface to auto-select firmware"},{"line_number":133,"context_line":"(which in turn, takes advantage of the firmware description files from"},{"line_number":134,"context_line":"QEMU)."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_73289d85","line":131,"range":{"start_line":131,"start_character":48,"end_line":131,"end_character":71},"updated":"2019-04-16 09:57:53.000000000","message":"we will not be able to depend on that for several release it will be after U and proably the V release before we can rely on 5.2 so we might want to  implement a fallback in nova otherwise most disto will not be able to use this feature.\n\nthe upcomming ubuntu 19.04 libvirt package will only be 5.0\nhttps://launchpad.net/ubuntu/disco/+source/libvirt\n\nso on the ubute/debian side it will likely be 19.10 or later before there is a relased version that will work.\n\non the centos/rhel side  fedora 30 also seams to be shiping 5.1 so you would need either fedora rawhide or the virt preview repo to get a new enough libvirt.\nhttps://rpmfind.net/linux/rpm2html/search.php?query\u003dlibvirt\n\n\nby the time train is relwase we should have bleeding edge distro support but unless we want to just use a version check and fail to boot the vm a fallback would be best.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c250e1efdf1cc85046efbfd96b8b9935f9a583a3","unresolved":false,"context_lines":[{"line_number":162,"context_line":"     Boot enabled (double-check this)."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"- Ubuntu:"},{"line_number":165,"context_line":"   - FIXME: Go through Ubuntu\u0027s OVMF package."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"Alternatives"},{"line_number":168,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5fc1f717_825c717d","line":165,"range":{"start_line":165,"start_character":3,"end_line":165,"end_character":45},"updated":"2019-04-09 15:10:12.000000000","message":"Presumably this is whatever Debian is doing","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":162,"context_line":"     Boot enabled (double-check this)."},{"line_number":163,"context_line":""},{"line_number":164,"context_line":"- Ubuntu:"},{"line_number":165,"context_line":"   - FIXME: Go through Ubuntu\u0027s OVMF package."},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"Alternatives"},{"line_number":168,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_3384550c","line":165,"range":{"start_line":165,"start_character":3,"end_line":165,"end_character":45},"in_reply_to":"5fc1f717_825c717d","updated":"2019-04-16 09:57:53.000000000","message":"its good to check but yes they tend not to diverge much","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6b3a602a502361a70da7e2bd803b0fb4b0b29e60","unresolved":false,"context_lines":[{"line_number":178,"context_line":"---------------"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Consider if we should allow via Nova API to specify *which* signing keys"},{"line_number":181,"context_line":"will be acceptable (and allow one of them to enable Secure Boot)."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Also consider if we should take into accout Glance\u0027s \"protected"},{"line_number":184,"context_line":"properties\"."}],"source_content_type":"text/x-rst","patch_set":8,"id":"5fc1f717_a2616d3b","line":181,"updated":"2019-04-09 15:16:35.000000000","message":"Would it be an image metadata?","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"d0e453f26a9e11e14f4175f9c0fa5315bcb11aa8","unresolved":false,"context_lines":[{"line_number":178,"context_line":"---------------"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Consider if we should allow via Nova API to specify *which* signing keys"},{"line_number":181,"context_line":"will be acceptable (and allow one of them to enable Secure Boot)."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Also consider if we should take into accout Glance\u0027s \"protected"},{"line_number":184,"context_line":"properties\"."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_f0efdc84","line":181,"in_reply_to":"5fc1f717_a2616d3b","updated":"2019-04-12 09:27:04.000000000","message":"Yeah, that\u0027s the current thinking.  But probably this is more a \"nice to have\" in my view.  I\u0027ll double-check with Secure Boot experts on it.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":177,"context_line":"REST API impact"},{"line_number":178,"context_line":"---------------"},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Consider if we should allow via Nova API to specify *which* signing keys"},{"line_number":181,"context_line":"will be acceptable (and allow one of them to enable Secure Boot)."},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"Also consider if we should take into accout Glance\u0027s \"protected"},{"line_number":184,"context_line":"properties\"."},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"Security impact"},{"line_number":187,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_33b215e8","line":184,"range":{"start_line":180,"start_character":0,"end_line":184,"end_character":12},"updated":"2019-04-16 09:57:53.000000000","message":"so i dont think we shoudl do either.\n\nthere for interoperablity we should reuse teh existing image metadata and flavor extra specs used by the hyperv driver.\n\nexposeing signing key via the api feels like a leaky abstration.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":187,"context_line":"---------------"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"With this feature, KVM- and QEMU-based Nova instances can get Secure"},{"line_number":190,"context_line":"Boot support.  Thus protecting the guests from boot-time malware."},{"line_number":191,"context_line":"(There are various web pages that describe the advantages of Secure"},{"line_number":192,"context_line":"Boot.  Not repeating them here.)"},{"line_number":193,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_3300d567","line":190,"range":{"start_line":190,"start_character":15,"end_line":190,"end_character":64},"updated":"2019-04-16 09:57:53.000000000","message":"this is only true if the uefi fireware can be trusted.\nif the uefi firmware binary on the host is compromised,\nfor any reason uefi secure boot provides no protection.\n\nmeaning without combining secure boot with trusted boot and mesuring the boot process via an attestation server this provide no addtional security if you do not trust the host.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"54db09ff9e8553c2306b0e38cfe9f677d494be6b","unresolved":false,"context_lines":[{"line_number":187,"context_line":"---------------"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"With this feature, KVM- and QEMU-based Nova instances can get Secure"},{"line_number":190,"context_line":"Boot support.  Thus protecting the guests from boot-time malware."},{"line_number":191,"context_line":"(There are various web pages that describe the advantages of Secure"},{"line_number":192,"context_line":"Boot.  Not repeating them here.)"},{"line_number":193,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_6d688a86","line":190,"range":{"start_line":190,"start_character":15,"end_line":190,"end_character":64},"in_reply_to":"3fce034c_3300d567","updated":"2019-04-18 13:14:00.000000000","message":"\u003e this is only true if the uefi fireware can be trusted.\n \u003e if the uefi firmware binary on the host is compromised,\n \u003e for any reason uefi secure boot provides no protection.\n \u003e \n \u003e meaning without combining secure boot with trusted boot and\n \u003e mesuring the boot process via an attestation server this provide no\n \u003e addtional security if you do not trust the host.\n\nYou\u0027re talking about something that is besides the point of the spec.\n\n\"Not trusting the host\" (an entirely separate problem, and is out-of-scope here) is _not_ what are talking about here.  The problem we\u0027re dealing with is: \"when you don’t trust what runs inside the _guest_\".\n\nSo indeed, Secure Boot in a VM doesn’t protect you from the host; nobody said it would.  But it protects you from malicious code in the *guest*—which is what the spec says on its tin.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":230,"context_line":"Primary assignee:"},{"line_number":231,"context_line":"    Kashyap Chamarthy \u003ckchamart@redhat.com\u003e"},{"line_number":232,"context_line":""},{"line_number":233,"context_line":"Work Items"},{"line_number":234,"context_line":"----------"},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Taking x86_64 architecture as an example, to enable guests to boot with"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_732bbdea","line":233,"range":{"start_line":233,"start_character":0,"end_line":233,"end_character":10},"updated":"2019-04-16 09:57:53.000000000","message":"im not sure why people have started to put large amount of text in the work items section in train but this really should be short bullet list sumarising the step previously\ndetailed in the sepc.\n\nthis content shoudl be coverd in the proposed changes section so it can be evaluated before gettign to the alternitves secation. can you move it there.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6b3a602a502361a70da7e2bd803b0fb4b0b29e60","unresolved":false,"context_lines":[{"line_number":274,"context_line":"            FS0:\\\u003e EnrollDefaultKeys.efi"},{"line_number":275,"context_line":"            FS0:\\\u003e reset"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"   (3.c) Reboot the guest. At which point, you will *actually* see"},{"line_number":278,"context_line":"   Secure Boot enabled. Which can be verified via `dmesg`::"},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"            (fedora-vm)$ dmesg | grep -i secure"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5fc1f717_a2940de9","line":277,"updated":"2019-04-09 15:16:35.000000000","message":"Do we need to change the boot order (or other way manipulate the domain xml) between 3.b and 3.c?","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":274,"context_line":"            FS0:\\\u003e EnrollDefaultKeys.efi"},{"line_number":275,"context_line":"            FS0:\\\u003e reset"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"   (3.c) Reboot the guest. At which point, you will *actually* see"},{"line_number":278,"context_line":"   Secure Boot enabled. Which can be verified via `dmesg`::"},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"            (fedora-vm)$ dmesg | grep -i secure"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_3383f5ce","line":277,"in_reply_to":"3fce034c_f0191c88","updated":"2019-04-16 09:57:53.000000000","message":"so this will all be done by nova as part of build before we report back to the user the vm reaches the active state correct.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"d0e453f26a9e11e14f4175f9c0fa5315bcb11aa8","unresolved":false,"context_lines":[{"line_number":274,"context_line":"            FS0:\\\u003e EnrollDefaultKeys.efi"},{"line_number":275,"context_line":"            FS0:\\\u003e reset"},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"   (3.c) Reboot the guest. At which point, you will *actually* see"},{"line_number":278,"context_line":"   Secure Boot enabled. Which can be verified via `dmesg`::"},{"line_number":279,"context_line":""},{"line_number":280,"context_line":"            (fedora-vm)$ dmesg | grep -i secure"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_f0191c88","line":277,"in_reply_to":"5fc1f717_a2940de9","updated":"2019-04-12 09:27:04.000000000","message":"No, we don\u0027t need to.  (But I will re-test and triple-confirm.)","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"9498c35b176aa67109620ffb8d800e2ae747e0ef","unresolved":false,"context_lines":[{"line_number":281,"context_line":"                  [    0.000000] Secure boot enabled and kernel locked down"},{"line_number":282,"context_line":"                  [    3.261277] EFI: Loaded cert \u0027Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42\u0027 linked to \u0027.builtin_trusted_keys\u0027"},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"   Here\u0027s [8]_ a little Python tool, written in collaboration with"},{"line_number":285,"context_line":"   Patrick Uiterwijk from the Fedora Project, that will automate the"},{"line_number":286,"context_line":"   above three steps by generating an OVMF variable store file with"},{"line_number":287,"context_line":"   default (Microsoft) keys enrolled."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"   TODO:"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"5fc1f717_387a8d87","line":287,"range":{"start_line":284,"start_character":0,"end_line":287,"end_character":37},"updated":"2019-04-09 16:33:19.000000000","message":"That\u0027s running a raw QEMU command and then executing the above commands directly in the attached console, is that the only way of automating this or would we use Libvirt or Libguestfs APIs here? Additionally wouldn\u0027t this be something we could document as an image prep step outside of Nova?","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"c187a6888131927c625f5a91de29fe4e46587fe9","unresolved":false,"context_lines":[{"line_number":281,"context_line":"                  [    0.000000] Secure boot enabled and kernel locked down"},{"line_number":282,"context_line":"                  [    3.261277] EFI: Loaded cert \u0027Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42\u0027 linked to \u0027.builtin_trusted_keys\u0027"},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"   Here\u0027s [8]_ a little Python tool, written in collaboration with"},{"line_number":285,"context_line":"   Patrick Uiterwijk from the Fedora Project, that will automate the"},{"line_number":286,"context_line":"   above three steps by generating an OVMF variable store file with"},{"line_number":287,"context_line":"   default (Microsoft) keys enrolled."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"   TODO:"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_1e25b5c2","line":287,"range":{"start_line":284,"start_character":0,"end_line":287,"end_character":37},"in_reply_to":"3fce034c_0d2831e0","updated":"2019-04-15 14:26:06.000000000","message":"It seems like you\u0027re misunderstanding what\u0027s happening here. The key enrollment stuff happens in the (virtual) BIOS, but not in the guest itself (which is realm of libguestfs).  And notice that the tiny external tool[1] is _not_ launching any guest OS.\n\nSo having this in libguestfs itself doesn\u0027t make sense—FWIW, I\u0027ve it past the libguestfs folks on IRC, and they also ask: \"why not use the existing external tool\"[1].\n\nAs noted earlier, for now we\u0027ll make the \"enrolling default UEFI keys\" an external step in Nova, with documentation.\n\n\n[1] https://github.com/puiterwijk/qemu-ovmf-secureboot","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"08c9a937db3889ddfaedbcae961d15b7e9276f45","unresolved":false,"context_lines":[{"line_number":281,"context_line":"                  [    0.000000] Secure boot enabled and kernel locked down"},{"line_number":282,"context_line":"                  [    3.261277] EFI: Loaded cert \u0027Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42\u0027 linked to \u0027.builtin_trusted_keys\u0027"},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"   Here\u0027s [8]_ a little Python tool, written in collaboration with"},{"line_number":285,"context_line":"   Patrick Uiterwijk from the Fedora Project, that will automate the"},{"line_number":286,"context_line":"   above three steps by generating an OVMF variable store file with"},{"line_number":287,"context_line":"   default (Microsoft) keys enrolled."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"   TODO:"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_3598c7be","line":287,"range":{"start_line":284,"start_character":0,"end_line":287,"end_character":37},"in_reply_to":"3fce034c_1e25b5c2","updated":"2019-04-15 18:57:13.000000000","message":"My misunderstanding was around where the enrolment state was actually being stored. I incorrectly thought this was in the instance image but I after reading back over this can see it\u0027s in an additional OVMF variable file, apologies for missing this.\n\nIf we are going to start with the generation of that file being external to Nova you might want to cover how it\u0027s going to be pulled in for each instance. Are we just going to have a configurable point to a local location in nova.conf or will we be pulling an image/file from another service?","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"441e1e3d1508e11a7585bd2e05a1b68d4625522a","unresolved":false,"context_lines":[{"line_number":281,"context_line":"                  [    0.000000] Secure boot enabled and kernel locked down"},{"line_number":282,"context_line":"                  [    3.261277] EFI: Loaded cert \u0027Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42\u0027 linked to \u0027.builtin_trusted_keys\u0027"},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"   Here\u0027s [8]_ a little Python tool, written in collaboration with"},{"line_number":285,"context_line":"   Patrick Uiterwijk from the Fedora Project, that will automate the"},{"line_number":286,"context_line":"   above three steps by generating an OVMF variable store file with"},{"line_number":287,"context_line":"   default (Microsoft) keys enrolled."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"   TODO:"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_b63593dc","line":287,"range":{"start_line":284,"start_character":0,"end_line":287,"end_character":37},"in_reply_to":"3fce034c_20687d1f","updated":"2019-04-16 10:22:11.000000000","message":"Yes, we should be just able to generate a template VARS file, and use a per-guest copy—libvirt already allows this today, via a config attribute:\n\nI totally missed to mention in the spec (will be in the upcoming iteration): There is also a config attribute in /etc/libvirt/qemu.conf that shows a mapping of *which* OVMF firmware binary maps to which variable store file.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"004de645be08cde9fc3561915f645776bc8a127d","unresolved":false,"context_lines":[{"line_number":281,"context_line":"                  [    0.000000] Secure boot enabled and kernel locked down"},{"line_number":282,"context_line":"                  [    3.261277] EFI: Loaded cert \u0027Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42\u0027 linked to \u0027.builtin_trusted_keys\u0027"},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"   Here\u0027s [8]_ a little Python tool, written in collaboration with"},{"line_number":285,"context_line":"   Patrick Uiterwijk from the Fedora Project, that will automate the"},{"line_number":286,"context_line":"   above three steps by generating an OVMF variable store file with"},{"line_number":287,"context_line":"   default (Microsoft) keys enrolled."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"   TODO:"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_ddee42b3","line":287,"range":{"start_line":284,"start_character":0,"end_line":287,"end_character":37},"in_reply_to":"3fce034c_3598c7be","updated":"2019-04-16 08:41:53.000000000","message":"\u003e My misunderstanding was around where the enrolment state was\n \u003e actually being stored. I incorrectly thought this was in the\n \u003e instance image but I after reading back over this can see it\u0027s in\n \u003e an additional OVMF variable file, apologies for missing this.\n\nNo problem.\n\n \u003e If we are going to start with the generation of that file being\n \u003e external to Nova you might want to cover how it\u0027s going to be\n \u003e pulled in for each instance. \n\nYep, refer below.\n\n \u003e Are we just going to have a\n \u003e configurable point to a local location in nova.conf or will we be\n \u003e pulling an image/file from another service?\n\nNo, it cannot be a config attribute—each Nova guest that needs Secure Boot should generate its _own_, separate OVMF variable store (\"VARS\") file.  Re-using the same file across VMs \"will lead to bad things\", because the VM will store other things in the VARS file (or guests like Fedora, CentOS and RHEL will modify it.)\n\nThere is a libvirt guest XML interface to specify the VARS file—the \u0027nvram\u0027 XML attribute.  Here is the relevant libvirt guest XML snippet:\n\n  \u003cos\u003e\n    \u003ctype arch\u003d\u0027x86_64\u0027 machine\u003d\u0027pc-q35-3.0\u0027\u003ehvm\u003c/type\u003e\n    \u003cloader readonly\u003d\u0027yes\u0027 secure\u003d\u0027yes\u0027 type\u003d\u0027pflash\u0027\u003e/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd\u003c/loader\u003e\n    \u003cnvram template\u003d\u0027/export/vmimages/rawhide-1-VARS.fd\u0027\u003e/var/lib/libvirt/qemu/nvram/f30-vm_VARS.fd\u003c/nvram\u003e\n    \u003cboot dev\u003d\u0027hd\u0027/\u003e\n  \u003c/os\u003e","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9c7d742d307576d34c5f32d5093725cfe12667a1","unresolved":false,"context_lines":[{"line_number":281,"context_line":"                  [    0.000000] Secure boot enabled and kernel locked down"},{"line_number":282,"context_line":"                  [    3.261277] EFI: Loaded cert \u0027Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42\u0027 linked to \u0027.builtin_trusted_keys\u0027"},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"   Here\u0027s [8]_ a little Python tool, written in collaboration with"},{"line_number":285,"context_line":"   Patrick Uiterwijk from the Fedora Project, that will automate the"},{"line_number":286,"context_line":"   above three steps by generating an OVMF variable store file with"},{"line_number":287,"context_line":"   default (Microsoft) keys enrolled."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"   TODO:"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_7640c436","line":287,"range":{"start_line":284,"start_character":0,"end_line":287,"end_character":37},"in_reply_to":"3fce034c_506a7080","updated":"2019-04-12 10:26:27.000000000","message":"This external image preparation steps looks good to me as a first step with a documentation helping with such perparation.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"52b600528526f57f21e9a81278e0837c07ae9f25","unresolved":false,"context_lines":[{"line_number":281,"context_line":"                  [    0.000000] Secure boot enabled and kernel locked down"},{"line_number":282,"context_line":"                  [    3.261277] EFI: Loaded cert \u0027Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42\u0027 linked to \u0027.builtin_trusted_keys\u0027"},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"   Here\u0027s [8]_ a little Python tool, written in collaboration with"},{"line_number":285,"context_line":"   Patrick Uiterwijk from the Fedora Project, that will automate the"},{"line_number":286,"context_line":"   above three steps by generating an OVMF variable store file with"},{"line_number":287,"context_line":"   default (Microsoft) keys enrolled."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"   TODO:"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_0d2831e0","line":287,"range":{"start_line":284,"start_character":0,"end_line":287,"end_character":37},"in_reply_to":"3fce034c_506a7080","updated":"2019-04-15 11:51:27.000000000","message":"Understood, this is fine as a standalone script but I\u0027d rather libguestfs provide a way of automating this before we think of integrating enrolment into Nova itself tbh.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"93940056416aa5c6a8d1ddf673f69212360eeb5a","unresolved":false,"context_lines":[{"line_number":281,"context_line":"                  [    0.000000] Secure boot enabled and kernel locked down"},{"line_number":282,"context_line":"                  [    3.261277] EFI: Loaded cert \u0027Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42\u0027 linked to \u0027.builtin_trusted_keys\u0027"},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"   Here\u0027s [8]_ a little Python tool, written in collaboration with"},{"line_number":285,"context_line":"   Patrick Uiterwijk from the Fedora Project, that will automate the"},{"line_number":286,"context_line":"   above three steps by generating an OVMF variable store file with"},{"line_number":287,"context_line":"   default (Microsoft) keys enrolled."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"   TODO:"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_20687d1f","line":287,"range":{"start_line":284,"start_character":0,"end_line":287,"end_character":37},"in_reply_to":"3fce034c_ddee42b3","updated":"2019-04-16 08:54:15.000000000","message":"I\u0027m not suggesting that we use the same file for each running instance but we should be able to generate once and use a copy of this VARS file for each instance right?","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":281,"context_line":"                  [    0.000000] Secure boot enabled and kernel locked down"},{"line_number":282,"context_line":"                  [    3.261277] EFI: Loaded cert \u0027Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42\u0027 linked to \u0027.builtin_trusted_keys\u0027"},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"   Here\u0027s [8]_ a little Python tool, written in collaboration with"},{"line_number":285,"context_line":"   Patrick Uiterwijk from the Fedora Project, that will automate the"},{"line_number":286,"context_line":"   above three steps by generating an OVMF variable store file with"},{"line_number":287,"context_line":"   default (Microsoft) keys enrolled."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"   TODO:"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_d34ab1aa","line":287,"range":{"start_line":284,"start_character":0,"end_line":287,"end_character":37},"in_reply_to":"3fce034c_ddee42b3","updated":"2019-04-16 09:57:53.000000000","message":"so are we goint to prospone this feature until there is a libvirt api to do this or is the proposal to port the script into the nova libvirt driver a a python module.\n\ni dont think we shoudl just shell out and run it.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"d0e453f26a9e11e14f4175f9c0fa5315bcb11aa8","unresolved":false,"context_lines":[{"line_number":281,"context_line":"                  [    0.000000] Secure boot enabled and kernel locked down"},{"line_number":282,"context_line":"                  [    3.261277] EFI: Loaded cert \u0027Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42\u0027 linked to \u0027.builtin_trusted_keys\u0027"},{"line_number":283,"context_line":""},{"line_number":284,"context_line":"   Here\u0027s [8]_ a little Python tool, written in collaboration with"},{"line_number":285,"context_line":"   Patrick Uiterwijk from the Fedora Project, that will automate the"},{"line_number":286,"context_line":"   above three steps by generating an OVMF variable store file with"},{"line_number":287,"context_line":"   default (Microsoft) keys enrolled."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"   TODO:"},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_506a7080","line":287,"range":{"start_line":284,"start_character":0,"end_line":287,"end_character":37},"in_reply_to":"5fc1f717_387a8d87","updated":"2019-04-12 09:27:04.000000000","message":"\u003e That\u0027s running a raw QEMU command and then executing the above\n \u003e commands directly in the attached console, is that the only way of\n \u003e automating this or would we use Libvirt or Libguestfs APIs here?\n\nThere are no formal libvirt / libguestfs APIs to do the UEFI key enrollment here.  That\u0027s why we wrote that tool.  (Even with libvirt, you still have to launch a QEMU process and then attach the `UefiShell.iso` file as a CD-ROM.  And run the commands.  Which is a more roundabout, slower way of doing what the tool already does.)\n\n(Aside: By the way, launching an external QEMU process is not \"bad\", if you are using formally supported command-line interface.  And libguestfs itself launches a raw QEMU command-line under the hood for most operations :-))\n\n \u003e Additionally wouldn\u0027t this be something we could document as an\n \u003e image prep step outside of Nova?\n\nYes, that is something that I\u0027m still mulling over.  Making it an external prep step could be the starting point.  And then later on integrate into Nova, perhaps.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":288,"context_line":""},{"line_number":289,"context_line":"   TODO:"},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"   - When using UEFI / OVMF, it may be fine to unconditionally enable"},{"line_number":292,"context_line":"     SMM and Secure Boot. But we should explore how to expose in the"},{"line_number":293,"context_line":"     Nova API _which_ keys are going to be acceptable (and enable SB)."},{"line_number":294,"context_line":"     But *should* we do it?"},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"   - Work out a way to integrate the external Python tool,"},{"line_number":297,"context_line":"     `ovmf-vars-generator` into Nova."}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_9398a91b","line":294,"range":{"start_line":291,"start_character":4,"end_line":294,"end_character":27},"updated":"2019-04-16 09:57:53.000000000","message":"no we should not. we should mirror the behavor of the hyperv driver and use the os:secure_boot extraspec and imamage property.\n\ni also dont think we shoudl expose the keys via the api.\n\nlikely the best approvch woudl be a seperate image metadata key to either state the type of key or reference another glance image which will contain the keys to use.\n\nwe shoudl not expose what keys are present or supproted by a host via the nova api.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"9498c35b176aa67109620ffb8d800e2ae747e0ef","unresolved":false,"context_lines":[{"line_number":293,"context_line":"     Nova API _which_ keys are going to be acceptable (and enable SB)."},{"line_number":294,"context_line":"     But *should* we do it?"},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"   - Work out a way to integrate the external Python tool,"},{"line_number":297,"context_line":"     `ovmf-vars-generator` into Nova."},{"line_number":298,"context_line":""},{"line_number":299,"context_line":"#. Make Nova use libvirt firmware auto-selection feature."},{"line_number":300,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"5fc1f717_5860b9cf","line":297,"range":{"start_line":296,"start_character":0,"end_line":297,"end_character":37},"updated":"2019-04-09 16:33:19.000000000","message":"As above, I\u0027d rather we didn\u0027t use the approach taken in the script and used Libvirt and/or libguestfs to build this into the instance in a more structured way, maybe even outside of Nova if we don\u0027t need any internal data/keys etc.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":293,"context_line":"     Nova API _which_ keys are going to be acceptable (and enable SB)."},{"line_number":294,"context_line":"     But *should* we do it?"},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"   - Work out a way to integrate the external Python tool,"},{"line_number":297,"context_line":"     `ovmf-vars-generator` into Nova."},{"line_number":298,"context_line":""},{"line_number":299,"context_line":"#. Make Nova use libvirt firmware auto-selection feature."},{"line_number":300,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_5349e188","line":297,"range":{"start_line":296,"start_character":0,"end_line":297,"end_character":37},"in_reply_to":"3fce034c_90f6988f","updated":"2019-04-16 09:57:53.000000000","message":"i think the key enrolment  shoudl be handeled via glance similar to how we haned signed images.\n\nas for the script this really does feal like we shoudl file a libvirt feature reuqset for this.\n\ni would similarly not want to ship or exectue the external tool but i could live with a nova python module that achived teh same effect but it really feels like we are missign a qemu or libvirt freature that would be a depency for this.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"d0e453f26a9e11e14f4175f9c0fa5315bcb11aa8","unresolved":false,"context_lines":[{"line_number":293,"context_line":"     Nova API _which_ keys are going to be acceptable (and enable SB)."},{"line_number":294,"context_line":"     But *should* we do it?"},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"   - Work out a way to integrate the external Python tool,"},{"line_number":297,"context_line":"     `ovmf-vars-generator` into Nova."},{"line_number":298,"context_line":""},{"line_number":299,"context_line":"#. Make Nova use libvirt firmware auto-selection feature."},{"line_number":300,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_90f6988f","line":297,"range":{"start_line":296,"start_character":0,"end_line":297,"end_character":37},"in_reply_to":"5fc1f717_5860b9cf","updated":"2019-04-12 09:27:04.000000000","message":"\u003e As above, I\u0027d rather we didn\u0027t use the approach taken in the script\n \u003e and used Libvirt and/or libguestfs to build this into the instance\n \u003e in a more structured way,\n\nAs noted earlier, there are no formal libvirt / libguestfs APIs to do the UEFI key enrollment.  It is an explicit step one must perform, if you want your \"Secure Boot\" to be *actually* secure.\n\n \u003e maybe even outside of Nova if we don\u0027t need any internal data/keys etc.\n\nAs noted above, the UEFI key enrollment is a prerequisite for the Secure Boot to be *actually* secure.\n\nAnd that step strictly does not \"need\" to be done in Nova, however, making Nova do it certainly makes it for a better user experience.  But, since we wrote an external tool, we (Nova) _could_ probably write a documentation step to use it.\n\nI\u0027m still debating this aspect with myself.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6b3a602a502361a70da7e2bd803b0fb4b0b29e60","unresolved":false,"context_lines":[{"line_number":342,"context_line":"     version: 1.2.9 (via libvirt commit: f05b6a918e -- \"domaincaps:"},{"line_number":343,"context_line":"     Expose UEFI binary path, if it exists\")"},{"line_number":344,"context_line":""},{"line_number":345,"context_line":"   Both the above are satisfied by Nova\u0027s current: MIN_LIBVIRT_VERSION."},{"line_number":346,"context_line":""},{"line_number":347,"context_line":"#. Work out a way to re-use the Nova metadata property,"},{"line_number":348,"context_line":"   ``os_secure_boot``.  And depending on the hypervisor being used, set"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5fc1f717_e2545524","line":345,"updated":"2019-04-09 15:16:35.000000000","message":"Did you suggest to make secure boot works with MIN_LIBVIRT_VERSION  by using the above workaround to select the binary path? And if there is new enough libvirt is detected then use the libvirt based solution from the previous point.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9c7d742d307576d34c5f32d5093725cfe12667a1","unresolved":false,"context_lines":[{"line_number":342,"context_line":"     version: 1.2.9 (via libvirt commit: f05b6a918e -- \"domaincaps:"},{"line_number":343,"context_line":"     Expose UEFI binary path, if it exists\")"},{"line_number":344,"context_line":""},{"line_number":345,"context_line":"   Both the above are satisfied by Nova\u0027s current: MIN_LIBVIRT_VERSION."},{"line_number":346,"context_line":""},{"line_number":347,"context_line":"#. Work out a way to re-use the Nova metadata property,"},{"line_number":348,"context_line":"   ``os_secure_boot``.  And depending on the hypervisor being used, set"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_76ae84e8","line":345,"in_reply_to":"3fce034c_3076c408","updated":"2019-04-12 10:26:27.000000000","message":"Your approach works for me.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":342,"context_line":"     version: 1.2.9 (via libvirt commit: f05b6a918e -- \"domaincaps:"},{"line_number":343,"context_line":"     Expose UEFI binary path, if it exists\")"},{"line_number":344,"context_line":""},{"line_number":345,"context_line":"   Both the above are satisfied by Nova\u0027s current: MIN_LIBVIRT_VERSION."},{"line_number":346,"context_line":""},{"line_number":347,"context_line":"#. Work out a way to re-use the Nova metadata property,"},{"line_number":348,"context_line":"   ``os_secure_boot``.  And depending on the hypervisor being used, set"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_731add7d","line":345,"in_reply_to":"3fce034c_76ae84e8","updated":"2019-04-16 09:57:53.000000000","message":"im not sure we should give that this will need libvit 5.2 and posibly later and given fedora rawhide will be the only thing avaiable when train ship will have that (fedra 30 which is currenlty in beta will have 5.1)  i think a fallback is resonable.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"d0e453f26a9e11e14f4175f9c0fa5315bcb11aa8","unresolved":false,"context_lines":[{"line_number":342,"context_line":"     version: 1.2.9 (via libvirt commit: f05b6a918e -- \"domaincaps:"},{"line_number":343,"context_line":"     Expose UEFI binary path, if it exists\")"},{"line_number":344,"context_line":""},{"line_number":345,"context_line":"   Both the above are satisfied by Nova\u0027s current: MIN_LIBVIRT_VERSION."},{"line_number":346,"context_line":""},{"line_number":347,"context_line":"#. Work out a way to re-use the Nova metadata property,"},{"line_number":348,"context_line":"   ``os_secure_boot``.  And depending on the hypervisor being used, set"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_3076c408","line":345,"in_reply_to":"5fc1f717_e2545524","updated":"2019-04-12 09:27:04.000000000","message":"I wrote the the above workaround to select the binary path many months ago when libvirt didn\u0027t add a formal interface.  I mentioned it there only for posterity, and past context.\n\nWe should skip the above approach and just stick with libvirt\u0027s formal interface that allows auto-selecting firmware binaries—it is also far less code for Nova.  And we will document that Nova will only support Secure Boot with the specified MIN_LIBVIRT_SECURE_BOOT_VERSION and MIN_QEMU_SECURE_BOOT_VERSION constants.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6b3a602a502361a70da7e2bd803b0fb4b0b29e60","unresolved":false,"context_lines":[{"line_number":360,"context_line":"* Mininum libvirt version of 2.1.0 for the \u0027loader\u0027 [10]_ / \u0027secure\u0027"},{"line_number":361,"context_line":"  attribute."},{"line_number":362,"context_line":""},{"line_number":363,"context_line":"* libvirt \u003e\u003d5.2 for the firmware auto-selection feature"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"Testing"},{"line_number":366,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5fc1f717_420a0926","line":363,"range":{"start_line":363,"start_character":2,"end_line":363,"end_character":55},"updated":"2019-04-09 15:16:35.000000000","message":"Does any distro package this version already?","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"9c7d742d307576d34c5f32d5093725cfe12667a1","unresolved":false,"context_lines":[{"line_number":360,"context_line":"* Mininum libvirt version of 2.1.0 for the \u0027loader\u0027 [10]_ / \u0027secure\u0027"},{"line_number":361,"context_line":"  attribute."},{"line_number":362,"context_line":""},{"line_number":363,"context_line":"* libvirt \u003e\u003d5.2 for the firmware auto-selection feature"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"Testing"},{"line_number":366,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_b67dcc6f","line":363,"range":{"start_line":363,"start_character":2,"end_line":363,"end_character":55},"in_reply_to":"3fce034c_2a973693","updated":"2019-04-12 10:26:27.000000000","message":"cool","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":360,"context_line":"* Mininum libvirt version of 2.1.0 for the \u0027loader\u0027 [10]_ / \u0027secure\u0027"},{"line_number":361,"context_line":"  attribute."},{"line_number":362,"context_line":""},{"line_number":363,"context_line":"* libvirt \u003e\u003d5.2 for the firmware auto-selection feature"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"Testing"},{"line_number":366,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_9602d708","line":363,"range":{"start_line":363,"start_character":2,"end_line":363,"end_character":55},"in_reply_to":"3fce034c_b67dcc6f","updated":"2019-04-16 09:57:53.000000000","message":"fedro rawhide pacages it. but as i mentioned previously it will be ubuntu 19.10 at the earlist before they ship 5.2.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"d0e453f26a9e11e14f4175f9c0fa5315bcb11aa8","unresolved":false,"context_lines":[{"line_number":360,"context_line":"* Mininum libvirt version of 2.1.0 for the \u0027loader\u0027 [10]_ / \u0027secure\u0027"},{"line_number":361,"context_line":"  attribute."},{"line_number":362,"context_line":""},{"line_number":363,"context_line":"* libvirt \u003e\u003d5.2 for the firmware auto-selection feature"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"Testing"},{"line_number":366,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_2a973693","line":363,"range":{"start_line":363,"start_character":2,"end_line":363,"end_character":55},"in_reply_to":"5fc1f717_420a0926","updated":"2019-04-12 09:27:04.000000000","message":"Yes, Fedora already packages it:\n\nhttps://koji.fedoraproject.org/koji/buildinfo?buildID\u003d1241464\n\nIn a week or so Debian and Ubuntu should catch up.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6b3a602a502361a70da7e2bd803b0fb4b0b29e60","unresolved":false,"context_lines":[{"line_number":368,"context_line":"This feature should be possible to test in the upstream Gate"},{"line_number":369,"context_line":"environment, where the Nova instance should be able to boot an OVMF"},{"line_number":370,"context_line":"(built with SB + SMM) enabled guest.  And also verify in `dmesg` that"},{"line_number":371,"context_line":"Secure Boot is *actually* enabled."},{"line_number":372,"context_line":""},{"line_number":373,"context_line":""},{"line_number":374,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":8,"id":"5fc1f717_bd03d00c","line":371,"updated":"2019-04-09 15:16:35.000000000","message":"That is a good thing!","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2b27be2a291208db18f48ed56f256c0ee5b651f2","unresolved":false,"context_lines":[{"line_number":368,"context_line":"This feature should be possible to test in the upstream Gate"},{"line_number":369,"context_line":"environment, where the Nova instance should be able to boot an OVMF"},{"line_number":370,"context_line":"(built with SB + SMM) enabled guest.  And also verify in `dmesg` that"},{"line_number":371,"context_line":"Secure Boot is *actually* enabled."},{"line_number":372,"context_line":""},{"line_number":373,"context_line":""},{"line_number":374,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_d617ff44","line":371,"in_reply_to":"3fce034c_aa9a46c2","updated":"2019-04-16 09:57:53.000000000","message":"well worst case you just write a tempest test that boots a cirrors image, sshs in and change the kernel command line then reboots it and checks.\n\nbut you might be able to see the require info in the console log.\nearlay boot which is whay i captured in dmesg shoudl be logged to the console.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"d0e453f26a9e11e14f4175f9c0fa5315bcb11aa8","unresolved":false,"context_lines":[{"line_number":368,"context_line":"This feature should be possible to test in the upstream Gate"},{"line_number":369,"context_line":"environment, where the Nova instance should be able to boot an OVMF"},{"line_number":370,"context_line":"(built with SB + SMM) enabled guest.  And also verify in `dmesg` that"},{"line_number":371,"context_line":"Secure Boot is *actually* enabled."},{"line_number":372,"context_line":""},{"line_number":373,"context_line":""},{"line_number":374,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_aa9a46c2","line":371,"in_reply_to":"5fc1f717_bd03d00c","updated":"2019-04-12 09:27:04.000000000","message":"I think we have to tweak the guest boot so that it includes the Secure Boot parameter.  So _some_ tweaking is required. :-)","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"d129c2557cd9ff3d00b560d86b6ad6cb006eb992","unresolved":false,"context_lines":[{"line_number":413,"context_line":"       libvirt\u0027s getDomainCapabilities() API as part of the AMD \"SEV\""},{"line_number":414,"context_line":"       work: https://review.openstack.org/#/c/633855/"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":".. [10] The BIOS-relate dlibvirt guest XML attributes:"},{"line_number":417,"context_line":"        https://libvirt.org/formatdomain.html#elementsOSBIOS"},{"line_number":418,"context_line":""},{"line_number":419,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_38831e07","line":416,"range":{"start_line":416,"start_character":17,"end_line":416,"end_character":25},"updated":"2019-04-16 14:00:53.000000000","message":"related libvirt","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"2e7194d98b37c549ea200f7f014fd1c9171eef34","unresolved":false,"context_lines":[{"line_number":413,"context_line":"       libvirt\u0027s getDomainCapabilities() API as part of the AMD \"SEV\""},{"line_number":414,"context_line":"       work: https://review.openstack.org/#/c/633855/"},{"line_number":415,"context_line":""},{"line_number":416,"context_line":".. [10] The BIOS-relate dlibvirt guest XML attributes:"},{"line_number":417,"context_line":"        https://libvirt.org/formatdomain.html#elementsOSBIOS"},{"line_number":418,"context_line":""},{"line_number":419,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"3fce034c_a33c5ebf","line":416,"range":{"start_line":416,"start_character":17,"end_line":416,"end_character":25},"in_reply_to":"3fce034c_38831e07","updated":"2019-04-17 08:01:13.000000000","message":"Fixed in next iteration.","commit_id":"bef59b9d2c28ddd5932676735deb4fde2d11d701"},{"author":{"_account_id":21813,"name":"Andrey Volkov","email":"m@amadev.ru","username":"avolkov"},"change_message_id":"3615dc2df10bbd6eec8855c4efac7746524b9434","unresolved":false,"context_lines":[{"line_number":260,"context_line":"   NB-2: Q35 machine type is *mandatory* for Secure Boot with OVMF."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"#. Merely exposing the above two does not give us Secure Boot.  We also"},{"line_number":263,"context_line":"   need to enroll the default security keys using the ``UefiShell.iso``"},{"line_number":264,"context_line":"   file the upstream OVMF package ships, and store them in an OVMF"},{"line_number":265,"context_line":"   \"VARS\" (variables store) file.  The steps for that is:"},{"line_number":266,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3fce034c_6ed1a8cd","line":263,"range":{"start_line":263,"start_character":56,"end_line":263,"end_character":69},"updated":"2019-04-15 16:09:49.000000000","message":"should that image be specified by an operator somehow?","commit_id":"4f44b1e5bf2c5280d68a1e9d1b60857ae6e9eacc"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"441e1e3d1508e11a7585bd2e05a1b68d4625522a","unresolved":false,"context_lines":[{"line_number":260,"context_line":"   NB-2: Q35 machine type is *mandatory* for Secure Boot with OVMF."},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"#. Merely exposing the above two does not give us Secure Boot.  We also"},{"line_number":263,"context_line":"   need to enroll the default security keys using the ``UefiShell.iso``"},{"line_number":264,"context_line":"   file the upstream OVMF package ships, and store them in an OVMF"},{"line_number":265,"context_line":"   \"VARS\" (variables store) file.  The steps for that is:"},{"line_number":266,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"3fce034c_20515d63","line":263,"range":{"start_line":263,"start_character":56,"end_line":263,"end_character":69},"in_reply_to":"3fce034c_6ed1a8cd","updated":"2019-04-16 10:22:11.000000000","message":"The `UefiShell.iso` file is shipped as part of the OVMF package for your distribution (e.g. on Fedora: /usr/share/OVMF/UefiShell.iso).  And the operator (or some installer or such tool) should take a step to run an external tool like `ovmf-vars-generator`[1] to generate the file.\n\nE.g.\n\n\n  $\u003e ./ovmf-vars-generator \\\n  \u003e         --ovmf-binary /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd \\\n  \u003e         --uefi-shell-iso /usr/share/edk2/ovmf/UefiShell.iso \\\n  \u003e         --ovmf-template-vars /usr/share/edk2/ovmf/OVMF_VARS.fd \\\n  \u003e         --fedora-version 27 \\\n  \u003e         --kernel-path /tmp/qosb.kernel \\\n  \u003e         --kernel-url https://download.fedoraproject.org/pub/fedora/linux/releases/29/Everything/x86_64/os/images/pxeboot/vmlinuz \\\n  \u003e         rawhide-1-VARS.fd\n  INFO:root:Starting enrollment\n  INFO:root:Performing enrollment\n  INFO:root:Finished enrollment\n  INFO:root:Grabbing test kernel\n  INFO:root:Starting verification\n  INFO:root:Performing verification\n  INFO:root:Confirmed: Secure Boot is enabled\n  INFO:root:Finished verification\n  INFO:root:Created and verified rawhide-1-VARS.fd\n\nAnd then, Nova will take care to add the VARS file (in this example: \u0027rawhide-1-VARS.fd\u0027) file to guest XML attribute, \u0027nvram\u0027, as shown here:\n\nhttps://review.openstack.org/#/c/506720/8/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.rst@287\n\n[1] https://github.com/puiterwijk/qemu-ovmf-secureboot.git","commit_id":"4f44b1e5bf2c5280d68a1e9d1b60857ae6e9eacc"},{"author":{"_account_id":21813,"name":"Andrey Volkov","email":"m@amadev.ru","username":"avolkov"},"change_message_id":"3615dc2df10bbd6eec8855c4efac7746524b9434","unresolved":false,"context_lines":[{"line_number":305,"context_line":"   is non-trivial to tell whether that binary supports Secure Boot or"},{"line_number":306,"context_line":"   not."},{"line_number":307,"context_line":""},{"line_number":308,"context_line":"   Solution: Here is where libvirt\u0027s firmware auto-selection comes into"},{"line_number":309,"context_line":"   picture.  It takes advantage of a lot of work done in QEMU and OVMF,"},{"line_number":310,"context_line":"   and fixes the above mentioned problem by providing a robust"},{"line_number":311,"context_line":"   interface.  As in, libvirt can now pick up the *correct* OVMF binary,"}],"source_content_type":"text/x-rst","patch_set":10,"id":"3fce034c_e135a9db","line":308,"range":{"start_line":308,"start_character":26,"end_line":308,"end_character":60},"updated":"2019-04-15 16:09:49.000000000","message":"So theoretically, libvirt can pick up a binary without SMM or SB support and we understand that only at VM boot time (assume an operator requested both), right?\nProbably, libvirt capabilities allow us to find out that earlier.","commit_id":"4f44b1e5bf2c5280d68a1e9d1b60857ae6e9eacc"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"b880dc15c182985ad2df084a6b8f4a162ff806cd","unresolved":false,"context_lines":[{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Today, Nova\u0027s libvirt driver only has support for generic UEFI boot, but"},{"line_number":17,"context_line":"not Secure Boot (the goal of which is to: \"make sure no unsigned"},{"line_number":18,"context_line":"(kernel) code runs on the machine\") for QEMU and KVM guests.  Secure"},{"line_number":19,"context_line":"Boot protects guests from boot-time malware, and validates that the code"},{"line_number":20,"context_line":"executed by the guest firmware is trusted."},{"line_number":21,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_f71f6058","line":18,"range":{"start_line":18,"start_character":1,"end_line":18,"end_character":7},"updated":"2019-04-18 15:08:48.000000000","message":"nit: nested parenthesis","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"c65a472af2fb0ec5c0a1fd8d64c3749026330f3f","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"NB: Nova\u0027s Hyper-V driver already has support for Secure Boot; it was"},{"line_number":43,"context_line":"added in commit: 29dab99 -- \"Hyper-V: Adds Hyper-V UEFI Secure Boot\""},{"line_number":44,"context_line":"[2]_."},{"line_number":45,"context_line":""},{"line_number":46,"context_line":"Use Cases"},{"line_number":47,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_a2eeef85","line":44,"updated":"2019-06-04 10:02:43.000000000","message":"I like this problem description.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":49,"context_line":"A non-exhaustive list:"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"* Protect the Nova instances being launched from boot-time malware from"},{"line_number":52,"context_line":"  the guest side, or other kernel code, like modules."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"* Secure Boot will prevent the Nova instance from running untrusted code"},{"line_number":55,"context_line":"  by requiring a trusted signature on UEFI binaries.  More detail on it,"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_ef2cd09a","line":52,"range":{"start_line":52,"start_character":17,"end_line":52,"end_character":52},"updated":"2019-06-04 09:20:58.000000000","message":"Nit: finding this bit hard to read. I assume we are basically saying \"provides Nova instances some protection from a bunch of guest side malware attacks\".","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"cb0fe74df23482fe87a681aed931da40cd2f10d9","unresolved":false,"context_lines":[{"line_number":49,"context_line":"A non-exhaustive list:"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"* Protect the Nova instances being launched from boot-time malware from"},{"line_number":52,"context_line":"  the guest side, or other kernel code, like modules."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"* Secure Boot will prevent the Nova instance from running untrusted code"},{"line_number":55,"context_line":"  by requiring a trusted signature on UEFI binaries.  More detail on it,"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_e2c2a7e9","line":52,"range":{"start_line":52,"start_character":17,"end_line":52,"end_character":52},"in_reply_to":"9fb8cfa7_ef2cd09a","updated":"2019-06-04 10:04:54.000000000","message":"ah, oops, what I mean is lets just clarify you mean hypervisor kernel modules.\n\nAlthough... I am actually not convinced about that bit... surely a bad hypervisor could pretend it is secure, if it were really bad. But I clearly don\u0027t fully understand the details there.\n\nI would be tempted to just talk about the guest protection here.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":51,"context_line":"* Protect the Nova instances being launched from boot-time malware from"},{"line_number":52,"context_line":"  the guest side, or other kernel code, like modules."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"* Secure Boot will prevent the Nova instance from running untrusted code"},{"line_number":55,"context_line":"  by requiring a trusted signature on UEFI binaries.  More detail on it,"},{"line_number":56,"context_line":"  refer to the \"Testing Secure Boot\" guide here [3]_."},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"* Secure Boot will allow trustworthy code in Nova instances to: (a)"},{"line_number":59,"context_line":"  enable the Secure Boot operational mode (for protecting itself), and;"},{"line_number":60,"context_line":"  (b) prevent malicious code in the guests from circumventing the actual"},{"line_number":61,"context_line":"  security of the Secure Boot operational mode."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"* SMM (System Management Mode) [4]_ [5]_: This will allow parts of the"},{"line_number":64,"context_line":"  system firmware (OVMF) to protect itself from malicious software."},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"* Advantage of using UEFI BIOS with OVMF: A PCI Express graphics card"},{"line_number":67,"context_line":"  with a UEFI driver has no legacy baggage (i.e. no central IO ports)"},{"line_number":68,"context_line":"  that would result in conflicts if you had multiple such devices in"},{"line_number":69,"context_line":"  your system.  This means several emulated and assigned UEFI graphics"},{"line_number":70,"context_line":"  cards can peacefully co-exist."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"* As a refresher, benefits of using OVMF are listed in the \"Motivation\""},{"line_number":73,"context_line":"  section of the OVMF white paper (URL in the \u0027References\u0027 section)"},{"line_number":74,"context_line":"  [6]_.  And for a more detailed treatment of Secure Boot, refer to this"},{"line_number":75,"context_line":"  [7]_"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":""},{"line_number":78,"context_line":".. _`Proposed change`:"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_0f35a4da","line":75,"range":{"start_line":54,"start_character":0,"end_line":75,"end_character":6},"updated":"2019-06-04 09:20:58.000000000","message":"Nit: I would jump straight to referencing the white paper for this second half of things. Saves us getting this wrong, or being out of date.\n\nNot against keeping it, just I don\u0027t feel qualified reviewing it.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"2d565c487ab44ec9a10f8457ac3dbc609c2f6c56","unresolved":false,"context_lines":[{"line_number":79,"context_line":""},{"line_number":80,"context_line":"Proposed change"},{"line_number":81,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"To allow Secure Boot for KVM and QEMU guests, we need the following main"},{"line_number":84,"context_line":"things to be in place:"},{"line_number":85,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_02f33ba0","line":82,"updated":"2019-06-04 09:53:41.000000000","message":"So here I expected to see:\n\n* User requests os_secure_boot via either image or flavor, as per hyper-v: https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/hyper-v-uefi-secureboot.html\n* note we don\u0027t support the signature for this version, we only work with the default keys, which works for most current distros anyways\n* XML is extended in two places when we decide we need to do secure boot\n* note the first version includes no scheduler support to isolate non-capable hosts, similar to current UEFI support\n\nIn the alternatives, note we could have added a request filter that is able to select hosts based on some new capability linked train, such as secure_boot_capable. We would add this for both libvirt hand hyper-v, following the pattern we have for disk type here: https://github.com/openstack/nova/blob/0c9c422c878719bae5b97fd07cafe7cd933bf103/nova/scheduler/request_filter.py#L124\n\nNow we can have a background section, in the proposed change section, that gives a summary of what is needed for this to work, and how with some distros operators have a bit more work to do in order to enroll the default keys, etc. That covers the paths, the need for VARS, etc. Describes what the above XML flags do.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":8768,"name":"Chris Friesen","email":"chris.friesen@windriver.com","username":"cbf123"},"change_message_id":"45b53bf67d3d52224fa127f864d19564588447ad","unresolved":false,"context_lines":[{"line_number":95,"context_line":"- Allow Nova to provide the NVRAM file (\"VARS\", the OVMF variables file)"},{"line_number":96,"context_line":"  for the guest, with default UEFI keys enrolled.  The key enrollment"},{"line_number":97,"context_line":"  process is discussed further below."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"On \"how are we going to do it\" and related design discussion, refer to"},{"line_number":100,"context_line":"the :ref:`Work Items \u003cWork Items\u003e` section below."},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_185578fa","line":98,"updated":"2019-04-18 19:46:13.000000000","message":"How will the flavor/image request that the guest be booted using secure boot?  (Would we re-use the existing flavor/image properties used for Hyper-v?)\n\nAlso, if the image/flavor requests secure boot, how will the scheduler know which compute nodes support secure boot?  (For vTPM we\u0027re using placement traits to indicate both compute node support and to request it in the flavor/image.)\n\nIf a guest is on a compute node that doesn\u0027t support secure boot and tries to rebuild to an image that requires secure boot, will that rebuild fail?  Will the end user get a useful error message?","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"c3804bab69cb3478841ce0ebf461bcf3d0c1064d","unresolved":false,"context_lines":[{"line_number":95,"context_line":"- Allow Nova to provide the NVRAM file (\"VARS\", the OVMF variables file)"},{"line_number":96,"context_line":"  for the guest, with default UEFI keys enrolled.  The key enrollment"},{"line_number":97,"context_line":"  process is discussed further below."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"On \"how are we going to do it\" and related design discussion, refer to"},{"line_number":100,"context_line":"the :ref:`Work Items \u003cWork Items\u003e` section below."},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ffb9cba7_f0511110","line":98,"in_reply_to":"3fce034c_185578fa","updated":"2019-04-23 10:32:48.000000000","message":"\u003e How will the flavor/image request that the guest be booted using\n \u003e secure boot?  (Would we re-use the existing flavor/image properties\n \u003e used for Hyper-v?)\n\nYes.  I noted it as much in the Work Items section (the last two items) that we will work towards re-using the existing image property `os_secure_boot` (and flavor extra spec: `os:secure_boot`) and even probably: `os_secure_boot_signature`.\n\n \u003e \n \u003e Also, if the image/flavor requests secure boot, how will the\n \u003e scheduler know which compute nodes support secure boot?  (For vTPM\n \u003e we\u0027re using placement traits to indicate both compute node support\n \u003e and to request it in the flavor/image.)\n\nFor this, yes, \u0027traits\u0027 is what I was suggested to use.  I will add that point after some more research.\n\n \u003e If a guest is on a compute node that doesn\u0027t support secure boot\n \u003e and tries to rebuild to an image that requires secure boot, will\n \u003e that rebuild fail?  Will the end user get a useful error message?\n\nI didn\u0027t think about this while writing, but yes: the rebuild should fail in that scenario, and we should throw a useful error message.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"9bb4e83325c13a1c453a3afde34edf0b6e694d18","unresolved":false,"context_lines":[{"line_number":95,"context_line":"- Allow Nova to provide the NVRAM file (\"VARS\", the OVMF variables file)"},{"line_number":96,"context_line":"  for the guest, with default UEFI keys enrolled.  The key enrollment"},{"line_number":97,"context_line":"  process is discussed further below."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"On \"how are we going to do it\" and related design discussion, refer to"},{"line_number":100,"context_line":"the :ref:`Work Items \u003cWork Items\u003e` section below."},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_c5d1ad59","line":98,"in_reply_to":"9fb8cfa7_cfe8ec17","updated":"2019-06-04 10:21:39.000000000","message":"oops, sorry, I mean\u0027t Chris.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":95,"context_line":"- Allow Nova to provide the NVRAM file (\"VARS\", the OVMF variables file)"},{"line_number":96,"context_line":"  for the guest, with default UEFI keys enrolled.  The key enrollment"},{"line_number":97,"context_line":"  process is discussed further below."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"On \"how are we going to do it\" and related design discussion, refer to"},{"line_number":100,"context_line":"the :ref:`Work Items \u003cWork Items\u003e` section below."},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_cfe8ec17","line":98,"in_reply_to":"dfbec78f_c3feaaad","updated":"2019-06-04 09:20:58.000000000","message":"I like Eric\u0027s point here.\n\nCould we please add a note here saying we are keeping the same interface as hyper-v, and maybe add a link to the current docs (or the spec if it is correct).\n\nI know it\u0027s covered later, but its a key design tenant here, keep the same interface.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":8768,"name":"Chris Friesen","email":"chris.friesen@windriver.com","username":"cbf123"},"change_message_id":"1be3fa6ff460c570487c774707d61f53fc3cc7ed","unresolved":false,"context_lines":[{"line_number":95,"context_line":"- Allow Nova to provide the NVRAM file (\"VARS\", the OVMF variables file)"},{"line_number":96,"context_line":"  for the guest, with default UEFI keys enrolled.  The key enrollment"},{"line_number":97,"context_line":"  process is discussed further below."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"On \"how are we going to do it\" and related design discussion, refer to"},{"line_number":100,"context_line":"the :ref:`Work Items \u003cWork Items\u003e` section below."},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"dfbec78f_c3feaaad","line":98,"in_reply_to":"ffb9cba7_a776e0a3","updated":"2019-05-02 20:47:56.000000000","message":"If we use traits for reporting support for secure boot *and* to request secure boot, then would we have some code that would translate \"os_secure_boot\" to a placement trait?  (The alternative would be to specify the placement trait directly in the image/flavor instead of re-using the existing image property.)","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"70691724fdca008ff12a11a273382a3d837ed8c1","unresolved":false,"context_lines":[{"line_number":95,"context_line":"- Allow Nova to provide the NVRAM file (\"VARS\", the OVMF variables file)"},{"line_number":96,"context_line":"  for the guest, with default UEFI keys enrolled.  The key enrollment"},{"line_number":97,"context_line":"  process is discussed further below."},{"line_number":98,"context_line":""},{"line_number":99,"context_line":"On \"how are we going to do it\" and related design discussion, refer to"},{"line_number":100,"context_line":"the :ref:`Work Items \u003cWork Items\u003e` section below."},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"ffb9cba7_a776e0a3","line":98,"in_reply_to":"ffb9cba7_f0511110","updated":"2019-04-24 10:28:29.000000000","message":"\u003e I didn\u0027t think about this while writing, but yes: the rebuild\n \u003e should fail in that scenario, and we should throw a useful error\n \u003e message.\n\nIf we use traits the scheduler will take of this for us and we should never hit that scenario.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"b880dc15c182985ad2df084a6b8f4a162ff806cd","unresolved":false,"context_lines":[{"line_number":115,"context_line":"Management Mode). This means a driver stack that consists of a set of"},{"line_number":116,"context_line":"privileged drivers that run in SMM, and another, interfacing set of"},{"line_number":117,"context_line":"unprivileged drivers that only format requests for the privileged half,"},{"line_number":118,"context_line":"and parse responses from it. Once the SMM feature is built into OVMF,"},{"line_number":119,"context_line":"then SMM emulation by the QEMU platform is *non-optional*, it is"},{"line_number":120,"context_line":"required."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"The Secure Boot Feature and the SMM feature stack are orthogonal. You"},{"line_number":123,"context_line":"can build OVMF in all four configurations. However, if you want to allow"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_97993c7a","line":120,"range":{"start_line":118,"start_character":29,"end_line":120,"end_character":9},"updated":"2019-04-18 15:08:48.000000000","message":"It\u0027s still opt-in though, right? As in, if we don\u0027t put work item 2 in the XML, we don\u0027t need to put work item 1. I\u0027m mainly thinking of upgrade impact - I don\u0027t want to end up in a situation where a compute to the new QEMU but instances already present on it don\u0027t have the new bits of XML required.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"c3804bab69cb3478841ce0ebf461bcf3d0c1064d","unresolved":false,"context_lines":[{"line_number":115,"context_line":"Management Mode). This means a driver stack that consists of a set of"},{"line_number":116,"context_line":"privileged drivers that run in SMM, and another, interfacing set of"},{"line_number":117,"context_line":"unprivileged drivers that only format requests for the privileged half,"},{"line_number":118,"context_line":"and parse responses from it. Once the SMM feature is built into OVMF,"},{"line_number":119,"context_line":"then SMM emulation by the QEMU platform is *non-optional*, it is"},{"line_number":120,"context_line":"required."},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"The Secure Boot Feature and the SMM feature stack are orthogonal. You"},{"line_number":123,"context_line":"can build OVMF in all four configurations. However, if you want to allow"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_1dbecdd4","line":120,"range":{"start_line":118,"start_character":29,"end_line":120,"end_character":9},"in_reply_to":"3fce034c_97993c7a","updated":"2019-04-23 10:32:48.000000000","message":"That text you quoted is talking about the interaction between QEMU and OVMF.  We satisfy the min QEMU version for SMM by a great margin.\n\nAnd there is no upgrade impact with the SMM bit, because Nova satisfies the QEMU/libvirt requirements for it by a great measure.  Refer to my longer response in the \"Upgrade impact\" section further below.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"b880dc15c182985ad2df084a6b8f4a162ff806cd","unresolved":false,"context_lines":[{"line_number":133,"context_line":"ship an SB+SMM OVMF build, the path name for the firmware binary may be"},{"line_number":134,"context_line":"different."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"OVMF binary files and variable store (\"VARS\") file paths"},{"line_number":137,"context_line":"--------------------------------------------------------"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"Each distribution has its *own* (but slightly different) path name of"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_37d40848","line":136,"range":{"start_line":136,"start_character":22,"end_line":136,"end_character":36},"updated":"2019-04-18 15:08:48.000000000","message":"So what\u0027s a variable store in this context?","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"c3804bab69cb3478841ce0ebf461bcf3d0c1064d","unresolved":false,"context_lines":[{"line_number":133,"context_line":"ship an SB+SMM OVMF build, the path name for the firmware binary may be"},{"line_number":134,"context_line":"different."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"OVMF binary files and variable store (\"VARS\") file paths"},{"line_number":137,"context_line":"--------------------------------------------------------"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"Each distribution has its *own* (but slightly different) path name of"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_bd20d949","line":136,"range":{"start_line":136,"start_character":22,"end_line":136,"end_character":36},"in_reply_to":"3fce034c_37d40848","updated":"2019-04-23 10:32:48.000000000","message":"An OVMF \"variable store\" (or \"VARS\") is a unique-per-guest, read-write file which can contain several data: \n\n* The UEFI keys and certificates that provides the whole firmware trust mechanism.\n* Just like traditional BIOS, UEFI has menus (just more of them), and needs to store the user\u0027s config somewhere.  If a user customizes something, then that goes into \"VARS\" file.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":8768,"name":"Chris Friesen","email":"chris.friesen@windriver.com","username":"cbf123"},"change_message_id":"45b53bf67d3d52224fa127f864d19564588447ad","unresolved":false,"context_lines":[{"line_number":133,"context_line":"ship an SB+SMM OVMF build, the path name for the firmware binary may be"},{"line_number":134,"context_line":"different."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"OVMF binary files and variable store (\"VARS\") file paths"},{"line_number":137,"context_line":"--------------------------------------------------------"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"Each distribution has its *own* (but slightly different) path name of"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_fda7410a","line":136,"range":{"start_line":136,"start_character":22,"end_line":136,"end_character":36},"in_reply_to":"3fce034c_37d40848","updated":"2019-04-18 19:46:13.000000000","message":"I think this is the equivalent of the hardware NVRAM.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":133,"context_line":"ship an SB+SMM OVMF build, the path name for the firmware binary may be"},{"line_number":134,"context_line":"different."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"OVMF binary files and variable store (\"VARS\") file paths"},{"line_number":137,"context_line":"--------------------------------------------------------"},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"Each distribution has its *own* (but slightly different) path name of"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_4f4abc27","line":136,"range":{"start_line":136,"start_character":22,"end_line":136,"end_character":36},"in_reply_to":"3fce034c_bd20d949","updated":"2019-06-04 09:20:58.000000000","message":"I hate making specs longer, but that text would be a great opening paragraph for this section.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"b880dc15c182985ad2df084a6b8f4a162ff806cd","unresolved":false,"context_lines":[{"line_number":139,"context_line":"Each distribution has its *own* (but slightly different) path name of"},{"line_number":140,"context_line":"OVMF:"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"- SUSE:"},{"line_number":143,"context_line":"   - package name: \"qemu-ovmf-x86_64\";"},{"line_number":144,"context_line":"   - ``/usr/share/qemu/ovmf-x86_64-opensuse-code.bin`` is the firmware"},{"line_number":145,"context_line":"     binary built with SB and SMM"},{"line_number":146,"context_line":"   - ``/usr/share/qemu/ovmf-x86_64-opensuse-vars.bin`` is the variable"},{"line_number":147,"context_line":"     store template that matches the above binary"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"- Fedora:"},{"line_number":150,"context_line":"   - package name: \"edk2-ovmf\" (x86_64)"},{"line_number":151,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_CODE.fd`` is a firmware binary built"},{"line_number":152,"context_line":"     without either SB or SMM"},{"line_number":153,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd`` is a firmware"},{"line_number":154,"context_line":"     binary built with both SB and SMM"},{"line_number":155,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_VARS.fd`` is the variable store"},{"line_number":156,"context_line":"     template that matches both of the above binaries"},{"line_number":157,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd`` is the variable store"},{"line_number":158,"context_line":"     template *with* the default UEFI keys enrolled"},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"- RHEL-7.6:"},{"line_number":161,"context_line":"   - package name: \"ovmf\" (x86_64)"},{"line_number":162,"context_line":"   - ``/usr/share/OVMF/OVMF_CODE.secboot.fd`` is the firmware binary,"},{"line_number":163,"context_line":"     built with SB plus SMM"},{"line_number":164,"context_line":"   - ``/usr/share/OVMF/OVMF_VARS.secboot.fd`` is the matching variable"},{"line_number":165,"context_line":"     store template"},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"- Debian:"},{"line_number":168,"context_line":"   - package name: \"ovmf\" (x86_64)"},{"line_number":169,"context_line":"   - ``/usr/share/OVMF/OVMF_CODE.fd`` is the firmware binary built with"},{"line_number":170,"context_line":"     SB plus SMM."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"- Ubuntu:"},{"line_number":173,"context_line":"   - same as Debian"},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"This is one of the tricky parts, but thankfully, the libvirt release 5.2"},{"line_number":176,"context_line":"vastly simplifies the OVMF file name handling — by providing an"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_b7755866","line":173,"range":{"start_line":142,"start_character":0,"end_line":173,"end_character":19},"updated":"2019-04-18 15:08:48.000000000","message":"nit: could we make this into a table? The first column is the distro+path, the second is a checkmark for whether that binary supports SB, the third is an SMM checkmark. Not sure what do to with the variable store template...","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"c3804bab69cb3478841ce0ebf461bcf3d0c1064d","unresolved":false,"context_lines":[{"line_number":139,"context_line":"Each distribution has its *own* (but slightly different) path name of"},{"line_number":140,"context_line":"OVMF:"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"- SUSE:"},{"line_number":143,"context_line":"   - package name: \"qemu-ovmf-x86_64\";"},{"line_number":144,"context_line":"   - ``/usr/share/qemu/ovmf-x86_64-opensuse-code.bin`` is the firmware"},{"line_number":145,"context_line":"     binary built with SB and SMM"},{"line_number":146,"context_line":"   - ``/usr/share/qemu/ovmf-x86_64-opensuse-vars.bin`` is the variable"},{"line_number":147,"context_line":"     store template that matches the above binary"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"- Fedora:"},{"line_number":150,"context_line":"   - package name: \"edk2-ovmf\" (x86_64)"},{"line_number":151,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_CODE.fd`` is a firmware binary built"},{"line_number":152,"context_line":"     without either SB or SMM"},{"line_number":153,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd`` is a firmware"},{"line_number":154,"context_line":"     binary built with both SB and SMM"},{"line_number":155,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_VARS.fd`` is the variable store"},{"line_number":156,"context_line":"     template that matches both of the above binaries"},{"line_number":157,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd`` is the variable store"},{"line_number":158,"context_line":"     template *with* the default UEFI keys enrolled"},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"- RHEL-7.6:"},{"line_number":161,"context_line":"   - package name: \"ovmf\" (x86_64)"},{"line_number":162,"context_line":"   - ``/usr/share/OVMF/OVMF_CODE.secboot.fd`` is the firmware binary,"},{"line_number":163,"context_line":"     built with SB plus SMM"},{"line_number":164,"context_line":"   - ``/usr/share/OVMF/OVMF_VARS.secboot.fd`` is the matching variable"},{"line_number":165,"context_line":"     store template"},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"- Debian:"},{"line_number":168,"context_line":"   - package name: \"ovmf\" (x86_64)"},{"line_number":169,"context_line":"   - ``/usr/share/OVMF/OVMF_CODE.fd`` is the firmware binary built with"},{"line_number":170,"context_line":"     SB plus SMM."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"- Ubuntu:"},{"line_number":173,"context_line":"   - same as Debian"},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"This is one of the tricky parts, but thankfully, the libvirt release 5.2"},{"line_number":176,"context_line":"vastly simplifies the OVMF file name handling — by providing an"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_fd866113","line":173,"range":{"start_line":142,"start_character":0,"end_line":173,"end_character":19},"in_reply_to":"3fce034c_b7755866","updated":"2019-04-23 10:32:48.000000000","message":"I don\u0027t think turning it into a table is worth it.  I mentioned them just to show how the file names differ across distributions.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":139,"context_line":"Each distribution has its *own* (but slightly different) path name of"},{"line_number":140,"context_line":"OVMF:"},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"- SUSE:"},{"line_number":143,"context_line":"   - package name: \"qemu-ovmf-x86_64\";"},{"line_number":144,"context_line":"   - ``/usr/share/qemu/ovmf-x86_64-opensuse-code.bin`` is the firmware"},{"line_number":145,"context_line":"     binary built with SB and SMM"},{"line_number":146,"context_line":"   - ``/usr/share/qemu/ovmf-x86_64-opensuse-vars.bin`` is the variable"},{"line_number":147,"context_line":"     store template that matches the above binary"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"- Fedora:"},{"line_number":150,"context_line":"   - package name: \"edk2-ovmf\" (x86_64)"},{"line_number":151,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_CODE.fd`` is a firmware binary built"},{"line_number":152,"context_line":"     without either SB or SMM"},{"line_number":153,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd`` is a firmware"},{"line_number":154,"context_line":"     binary built with both SB and SMM"},{"line_number":155,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_VARS.fd`` is the variable store"},{"line_number":156,"context_line":"     template that matches both of the above binaries"},{"line_number":157,"context_line":"   - ``/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd`` is the variable store"},{"line_number":158,"context_line":"     template *with* the default UEFI keys enrolled"},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"- RHEL-7.6:"},{"line_number":161,"context_line":"   - package name: \"ovmf\" (x86_64)"},{"line_number":162,"context_line":"   - ``/usr/share/OVMF/OVMF_CODE.secboot.fd`` is the firmware binary,"},{"line_number":163,"context_line":"     built with SB plus SMM"},{"line_number":164,"context_line":"   - ``/usr/share/OVMF/OVMF_VARS.secboot.fd`` is the matching variable"},{"line_number":165,"context_line":"     store template"},{"line_number":166,"context_line":""},{"line_number":167,"context_line":"- Debian:"},{"line_number":168,"context_line":"   - package name: \"ovmf\" (x86_64)"},{"line_number":169,"context_line":"   - ``/usr/share/OVMF/OVMF_CODE.fd`` is the firmware binary built with"},{"line_number":170,"context_line":"     SB plus SMM."},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"- Ubuntu:"},{"line_number":173,"context_line":"   - same as Debian"},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"This is one of the tricky parts, but thankfully, the libvirt release 5.2"},{"line_number":176,"context_line":"vastly simplifies the OVMF file name handling — by providing an"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_ef3290a7","line":173,"range":{"start_line":142,"start_character":0,"end_line":173,"end_character":19},"in_reply_to":"3fce034c_fd866113","updated":"2019-06-04 09:20:58.000000000","message":"I would add versions we are talking about here, so this doesn\u0027t look wrong in the future.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"b880dc15c182985ad2df084a6b8f4a162ff806cd","unresolved":false,"context_lines":[{"line_number":172,"context_line":"- Ubuntu:"},{"line_number":173,"context_line":"   - same as Debian"},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"This is one of the tricky parts, but thankfully, the libvirt release 5.2"},{"line_number":176,"context_line":"vastly simplifies the OVMF file name handling — by providing an"},{"line_number":177,"context_line":"interface to auto-select firmware (which in turn, takes advantage of the"},{"line_number":178,"context_line":"firmware description files from QEMU (provided by QEMU 2.9 and above)"},{"line_number":179,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_b7fa38ba","line":176,"range":{"start_line":175,"start_character":53,"end_line":176,"end_character":45},"updated":"2019-04-18 15:08:48.000000000","message":"... making the previous list/table pointless? ;)","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"c3804bab69cb3478841ce0ebf461bcf3d0c1064d","unresolved":false,"context_lines":[{"line_number":172,"context_line":"- Ubuntu:"},{"line_number":173,"context_line":"   - same as Debian"},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"This is one of the tricky parts, but thankfully, the libvirt release 5.2"},{"line_number":176,"context_line":"vastly simplifies the OVMF file name handling — by providing an"},{"line_number":177,"context_line":"interface to auto-select firmware (which in turn, takes advantage of the"},{"line_number":178,"context_line":"firmware description files from QEMU (provided by QEMU 2.9 and above)"},{"line_number":179,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_fd9bc162","line":176,"range":{"start_line":175,"start_character":53,"end_line":176,"end_character":45},"in_reply_to":"3fce034c_b7fa38ba","updated":"2019-04-23 10:32:48.000000000","message":"Not pointless; it is still useful to get a quick sense of how things differ across Linux distributions.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":172,"context_line":"- Ubuntu:"},{"line_number":173,"context_line":"   - same as Debian"},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"This is one of the tricky parts, but thankfully, the libvirt release 5.2"},{"line_number":176,"context_line":"vastly simplifies the OVMF file name handling — by providing an"},{"line_number":177,"context_line":"interface to auto-select firmware (which in turn, takes advantage of the"},{"line_number":178,"context_line":"firmware description files from QEMU (provided by QEMU 2.9 and above)"},{"line_number":179,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_efd7f022","line":176,"range":{"start_line":175,"start_character":53,"end_line":176,"end_character":45},"in_reply_to":"3fce034c_fd9bc162","updated":"2019-06-04 09:20:58.000000000","message":"Nit: Artom makes a good point here.\n\nCan we turn this upside down? Something like\n\nPicking the correct fireware and matching variable store is tricky, but thankfully libvirt 5.2 handles this complexity for us. Just to illustrate why we don\u0027t want to replicate this logic in Nova, here is a rough summary of some current locations we need to consider:\n\n* ... list of locations ...\n\nAlthough I would be tempted by just doing fedora and debian as an illustration.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"b880dc15c182985ad2df084a6b8f4a162ff806cd","unresolved":false,"context_lines":[{"line_number":227,"context_line":"Upgrade impact"},{"line_number":228,"context_line":"--------------"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"None."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Implementation"},{"line_number":233,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_7775b031","line":230,"updated":"2019-04-18 15:08:48.000000000","message":"I think I\u0027d like more details on how/why there\u0027s no upgrade impact, see my comment on L120.\n\nAlso, N -\u003e N-1 live migration? How do we handle live migrating an instance with SMM to an older compute that doesn\u0027t support it?","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"c3804bab69cb3478841ce0ebf461bcf3d0c1064d","unresolved":false,"context_lines":[{"line_number":227,"context_line":"Upgrade impact"},{"line_number":228,"context_line":"--------------"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"None."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Implementation"},{"line_number":233,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"ffb9cba7_d0896d26","line":230,"in_reply_to":"3fce034c_7775b031","updated":"2019-04-23 10:32:48.000000000","message":"\u003e I think I\u0027d like more details on how/why there\u0027s no upgrade impact,\n \u003e see my comment on L120.\n\nI don\u0027t think there is any \"real\" upgrade impact.   The only thing I can think of is:\n\nWhen you\u0027re migrating an instance with Secure Boot, we should ensure that the target Compute node has the correct versions (of libvirt, QEMU and OVMF/EDK2).  So this is where \u0027traits\u0027 can help us, when scheduling?\n\n \u003e Also, N -\u003e N-1 live migration? How do we handle live migrating an\n \u003e instance with SMM to an older compute that doesn\u0027t support it?\n\nThe above is a non-problem, because:\n\n* Firstly, libvirt takes care of the \"ABI stability\" check during migration. As in, libvirt ensures that SMM is not changed (on -\u003e off or otherwise) in the migration XML; if it is, libvirt denies migration.\n\n* Secondly, Nova is *not* enabling SMM on its own—Nova will enable it only when enabling Secure Boot.  And if you have Secure Boot-related pieces, then QEMU is new enough.  And all Compute nodes will have SMM capability, because, as noted earlier Nova satisfies the version constraints by a great margin.\n\n* Just to be ultra precise on versions: SMM in libvirt was introduced in libvirt 2.1.0, and the minimum QEMU version required for SMM is 1.5.0 (although SMM support in QEMU dates back to 2006!).  And *today* in Git master, we have: MIN_LIBVIRT_VERSION \u003d (3, 0, 0) and MIN_QEMU_VERSION \u003d (2, 8, 0).  So Nova is _well_ ahead of what\u0027s required.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":8768,"name":"Chris Friesen","email":"chris.friesen@windriver.com","username":"cbf123"},"change_message_id":"45b53bf67d3d52224fa127f864d19564588447ad","unresolved":false,"context_lines":[{"line_number":227,"context_line":"Upgrade impact"},{"line_number":228,"context_line":"--------------"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"None."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Implementation"},{"line_number":233,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_186ed8c8","line":230,"in_reply_to":"3fce034c_7775b031","updated":"2019-04-18 19:46:13.000000000","message":"This is a subset of a larger question...see my comment up at line 98.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":227,"context_line":"Upgrade impact"},{"line_number":228,"context_line":"--------------"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"None."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Implementation"},{"line_number":233,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_8fe674e8","line":230,"in_reply_to":"dfbec78f_03ab62d6","updated":"2019-06-04 09:20:58.000000000","message":"I think we should summarize this in the spec text. Something like:\n\nNo upgrade impact, mostly as hypervisors will report if they can support secure boot. Existing Live migration checks will ensure only capable hosts will pass the live-migration checks.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":8768,"name":"Chris Friesen","email":"chris.friesen@windriver.com","username":"cbf123"},"change_message_id":"1be3fa6ff460c570487c774707d61f53fc3cc7ed","unresolved":false,"context_lines":[{"line_number":227,"context_line":"Upgrade impact"},{"line_number":228,"context_line":"--------------"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"None."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"Implementation"},{"line_number":233,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"dfbec78f_03ab62d6","line":230,"in_reply_to":"ffb9cba7_d0896d26","updated":"2019-05-02 20:47:56.000000000","message":"If we use traits for a compute node to report support for secure boot, then this issue will largely be solved as the scheduler will not try to migrate an instance with secure boot to a node that doesn\u0027t support it.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":256,"context_line":"        \u003csmm state\u003d\u0027on\u0027/\u003e"},{"line_number":257,"context_line":"      \u003c/features\u003e"},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"#. The OVMF ``loader`` and ``nvram`` related guest XML snippet looks as"},{"line_number":260,"context_line":"   follows (for a Fedora guest with Q35 machine type using an OVMF build"},{"line_number":261,"context_line":"   with SMM + SB enabled)::"},{"line_number":262,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_8f0d1492","line":259,"updated":"2019-06-04 09:20:58.000000000","message":"let\u0027s be clear new libvirt does this for us now... yeah, lets drop it.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":267,"context_line":"        \u003cboot dev\u003d\u0027hd\u0027/\u003e"},{"line_number":268,"context_line":"      \u003c/os\u003e"},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"   NB-1: The paths for the UEFI binary will be different for different"},{"line_number":271,"context_line":"   distributions."},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"   NB-2: Q35 machine type is *mandatory* for Secure Boot with OVMF."},{"line_number":274,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_af39f841","line":271,"range":{"start_line":270,"start_character":0,"end_line":271,"end_character":17},"updated":"2019-06-04 09:20:58.000000000","message":"So we should be clear, this is different hypervisor distos? It is not guest disto dependent right?","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"cef0a9df3fdec34426e37603fcba2f632f91a4fe","unresolved":false,"context_lines":[{"line_number":267,"context_line":"        \u003cboot dev\u003d\u0027hd\u0027/\u003e"},{"line_number":268,"context_line":"      \u003c/os\u003e"},{"line_number":269,"context_line":""},{"line_number":270,"context_line":"   NB-1: The paths for the UEFI binary will be different for different"},{"line_number":271,"context_line":"   distributions."},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"   NB-2: Q35 machine type is *mandatory* for Secure Boot with OVMF."},{"line_number":274,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_dac1fb55","line":271,"range":{"start_line":270,"start_character":0,"end_line":271,"end_character":17},"in_reply_to":"9fb8cfa7_af39f841","updated":"2019-06-27 08:32:24.000000000","message":"Correct; it is the host distribution where the hypervisor is running on.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":272,"context_line":""},{"line_number":273,"context_line":"   NB-2: Q35 machine type is *mandatory* for Secure Boot with OVMF."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"#. For guests to truly get Secure Boot, we need to ensure that the"},{"line_number":276,"context_line":"   non-variable store (\"VARS\") file (in the above example,"},{"line_number":277,"context_line":"   `fedora_VARS.secboot.fd`) has the default UEFI keys enrolled."},{"line_number":278,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_2f4c28c6","line":275,"updated":"2019-06-04 09:20:58.000000000","message":"Please move this to \"Other deployer impact\". With text something like:\n\nNote most distros now ship the VARS file for you, but there are manual steps needed to enrole the keys for distro X,Y,Z. Ideally just link to the external docs that describe those steps.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"30ee9b1ed4c273fc18b6eb7ac2ccb6e9df451c0f","unresolved":false,"context_lines":[{"line_number":273,"context_line":"   NB-2: Q35 machine type is *mandatory* for Secure Boot with OVMF."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"#. For guests to truly get Secure Boot, we need to ensure that the"},{"line_number":276,"context_line":"   non-variable store (\"VARS\") file (in the above example,"},{"line_number":277,"context_line":"   `fedora_VARS.secboot.fd`) has the default UEFI keys enrolled."},{"line_number":278,"context_line":""},{"line_number":279,"context_line":"   There are two ways to achieve that.  The first, use the \"VARS\" file"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_945b9652","line":276,"range":{"start_line":276,"start_character":3,"end_line":276,"end_character":15},"updated":"2019-04-17 11:37:20.000000000","message":"s/non-variable/non-volatile/.  (Or \u0027persistent\u0027)\n\nWill fix it after I get some more review feedback that needs addressing.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":310,"context_line":"   keys enrolled, here [11]_ is a little Python tool,"},{"line_number":311,"context_line":"   ``ovmf-vars-generator`` that will automate the above three steps."},{"line_number":312,"context_line":"   This is packaged in Fedora as a sub-RPM of EDK2/OVMF, called"},{"line_number":313,"context_line":"   \u0027edk2-qosb\u0027.  And work is under way to get Debian ship this script."},{"line_number":314,"context_line":""},{"line_number":315,"context_line":"#. Document the way to generate the above-mentioned \"VARS\" file using"},{"line_number":316,"context_line":"   the tool ``ovmf-vars-generator``.  This tool is already shipped as a"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_0f760408","line":313,"updated":"2019-06-04 09:20:58.000000000","message":"w","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":316,"context_line":"   the tool ``ovmf-vars-generator``.  This tool is already shipped as a"},{"line_number":317,"context_line":"   sub-package (called: \u0027edk2-qosb\u0027) of the main \u0027edk2\u0027 / OVMF in"},{"line_number":318,"context_line":"   different distributions.  And Ubunutu and Debian are working to also"},{"line_number":319,"context_line":"   ship this script."},{"line_number":320,"context_line":""},{"line_number":321,"context_line":"#. Make Nova use libvirt firmware auto-selection feature."},{"line_number":322,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_cfc6ac17","line":319,"updated":"2019-06-04 09:20:58.000000000","message":"This doesn\u0027t sound like our job, it\u0027s our job to highlight you need to talk to you distro about getting those things enroles, and libvirt docs have more info, etc, etc.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":337,"context_line":"          \u003cloader secure\u003d\u0027yes\u0027/\u003e"},{"line_number":338,"context_line":"        \u003c/os\u003e"},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"#. Work out a way to detect the correct firmware OVMF binaries.  This"},{"line_number":341,"context_line":"   problem of is now solved by libvirt\u0027s feature that allows"},{"line_number":342,"context_line":"   auto-selection of different firmware binaries that OVMF ships."},{"line_number":343,"context_line":""},{"line_number":344,"context_line":"   Before the libvirt\u0027s firmware auto-selection was merged (which is"},{"line_number":345,"context_line":"   available as part of the libvirt 5.2 release that came out on 03"},{"line_number":346,"context_line":"   April 2019), an approach that we considered was to use libvirt\u0027s"},{"line_number":347,"context_line":"   getDomainCapabilities() API.  Then, we can make an `xpath`"},{"line_number":348,"context_line":"   query as following to detect the binary path names::"},{"line_number":349,"context_line":""},{"line_number":350,"context_line":"      $\u003e virsh domcapabilities |"},{"line_number":351,"context_line":"      \u003e xpath -n -q -e"},{"line_number":352,"context_line":"       \"/domainCapabilities/os[@supported\u003d\u0027yes\u0027]/loader[@supported\u003d\u0027yes\u0027]/value/text()\""},{"line_number":353,"context_line":"       /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd"},{"line_number":354,"context_line":"       /usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw"},{"line_number":355,"context_line":"       /usr/share/edk2/ovmf/OVMF_CODE.fd"},{"line_number":356,"context_line":""},{"line_number":357,"context_line":"   Related points:"},{"line_number":358,"context_line":""},{"line_number":359,"context_line":"   - The getDomainCapabilities() API was introduced in version 1.2.7."},{"line_number":360,"context_line":""},{"line_number":361,"context_line":"   - However, the query-ability of UEFI binary path names via"},{"line_number":362,"context_line":"     getDomainCapabilities() was introduced by libvirt in a later"},{"line_number":363,"context_line":"     version: 1.2.9 (via libvirt commit: f05b6a918e -- \"domaincaps:"},{"line_number":364,"context_line":"     Expose UEFI binary path, if it exists\")"},{"line_number":365,"context_line":""},{"line_number":366,"context_line":"   However, we should skip the above ``xpath`` query approach and just"},{"line_number":367,"context_line":"   stick with libvirt\u0027s formal interface that allows auto-selecting"},{"line_number":368,"context_line":"   firmware binaries—it is also far less code for Nova.  And we will"},{"line_number":369,"context_line":"   document that Nova will only support Secure Boot given they have"},{"line_number":370,"context_line":"   ``MIN_LIBVIRT_SECURE_BOOT_VERSION`` and"},{"line_number":371,"context_line":"   ``MIN_QEMU_SECURE_BOOT_VERSION`` constants."},{"line_number":372,"context_line":""},{"line_number":373,"context_line":"#. Work out a way to re-use the Nova metadata property,"},{"line_number":374,"context_line":"   ``os_secure_boot``.  And depending on the hypervisor being used, set"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_efcb701b","line":371,"range":{"start_line":340,"start_character":0,"end_line":371,"end_character":46},"updated":"2019-06-04 09:20:58.000000000","message":"This all goes I presume? Lets kill it?","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"cef0a9df3fdec34426e37603fcba2f632f91a4fe","unresolved":false,"context_lines":[{"line_number":337,"context_line":"          \u003cloader secure\u003d\u0027yes\u0027/\u003e"},{"line_number":338,"context_line":"        \u003c/os\u003e"},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"#. Work out a way to detect the correct firmware OVMF binaries.  This"},{"line_number":341,"context_line":"   problem of is now solved by libvirt\u0027s feature that allows"},{"line_number":342,"context_line":"   auto-selection of different firmware binaries that OVMF ships."},{"line_number":343,"context_line":""},{"line_number":344,"context_line":"   Before the libvirt\u0027s firmware auto-selection was merged (which is"},{"line_number":345,"context_line":"   available as part of the libvirt 5.2 release that came out on 03"},{"line_number":346,"context_line":"   April 2019), an approach that we considered was to use libvirt\u0027s"},{"line_number":347,"context_line":"   getDomainCapabilities() API.  Then, we can make an `xpath`"},{"line_number":348,"context_line":"   query as following to detect the binary path names::"},{"line_number":349,"context_line":""},{"line_number":350,"context_line":"      $\u003e virsh domcapabilities |"},{"line_number":351,"context_line":"      \u003e xpath -n -q -e"},{"line_number":352,"context_line":"       \"/domainCapabilities/os[@supported\u003d\u0027yes\u0027]/loader[@supported\u003d\u0027yes\u0027]/value/text()\""},{"line_number":353,"context_line":"       /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd"},{"line_number":354,"context_line":"       /usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw"},{"line_number":355,"context_line":"       /usr/share/edk2/ovmf/OVMF_CODE.fd"},{"line_number":356,"context_line":""},{"line_number":357,"context_line":"   Related points:"},{"line_number":358,"context_line":""},{"line_number":359,"context_line":"   - The getDomainCapabilities() API was introduced in version 1.2.7."},{"line_number":360,"context_line":""},{"line_number":361,"context_line":"   - However, the query-ability of UEFI binary path names via"},{"line_number":362,"context_line":"     getDomainCapabilities() was introduced by libvirt in a later"},{"line_number":363,"context_line":"     version: 1.2.9 (via libvirt commit: f05b6a918e -- \"domaincaps:"},{"line_number":364,"context_line":"     Expose UEFI binary path, if it exists\")"},{"line_number":365,"context_line":""},{"line_number":366,"context_line":"   However, we should skip the above ``xpath`` query approach and just"},{"line_number":367,"context_line":"   stick with libvirt\u0027s formal interface that allows auto-selecting"},{"line_number":368,"context_line":"   firmware binaries—it is also far less code for Nova.  And we will"},{"line_number":369,"context_line":"   document that Nova will only support Secure Boot given they have"},{"line_number":370,"context_line":"   ``MIN_LIBVIRT_SECURE_BOOT_VERSION`` and"},{"line_number":371,"context_line":"   ``MIN_QEMU_SECURE_BOOT_VERSION`` constants."},{"line_number":372,"context_line":""},{"line_number":373,"context_line":"#. Work out a way to re-use the Nova metadata property,"},{"line_number":374,"context_line":"   ``os_secure_boot``.  And depending on the hypervisor being used, set"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_7aa7afbd","line":371,"range":{"start_line":340,"start_character":0,"end_line":371,"end_character":46},"in_reply_to":"9fb8cfa7_efcb701b","updated":"2019-06-27 08:32:24.000000000","message":"Yes, will kill it.  When I began drafting the spec, it was useful; now that all that work is handled by libvirt, it can be elided.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":370,"context_line":"   ``MIN_LIBVIRT_SECURE_BOOT_VERSION`` and"},{"line_number":371,"context_line":"   ``MIN_QEMU_SECURE_BOOT_VERSION`` constants."},{"line_number":372,"context_line":""},{"line_number":373,"context_line":"#. Work out a way to re-use the Nova metadata property,"},{"line_number":374,"context_line":"   ``os_secure_boot``.  And depending on the hypervisor being used, set"},{"line_number":375,"context_line":"   the value appropriately.  It was introduced as part of enabling"},{"line_number":376,"context_line":"   Secure Boot for Hyper-V driver (29dab99 -- Hyper-V: Adds Hyper-V UEFI"},{"line_number":377,"context_line":"   Secure Boot)."},{"line_number":378,"context_line":""},{"line_number":379,"context_line":"#. Work out a way to re-use the existing image metadat propoerty,"},{"line_number":380,"context_line":"   ``os_secure_boot_signature`` that lets you specify bootloader\u0027s"},{"line_number":381,"context_line":"   signature."},{"line_number":382,"context_line":""},{"line_number":383,"context_line":"Dependencies"},{"line_number":384,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_2fe1889b","line":381,"range":{"start_line":373,"start_character":0,"end_line":381,"end_character":13},"updated":"2019-06-04 09:20:58.000000000","message":"This is honestly what the whole spec needs to focus on.\n\nWith a small note on the additional required libvirt XML.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"c3804bab69cb3478841ce0ebf461bcf3d0c1064d","unresolved":false,"context_lines":[{"line_number":394,"context_line":"* libvirt \u003e\u003d5.2 for the firmware auto-selection feature."},{"line_number":395,"context_line":""},{"line_number":396,"context_line":"* libvirt \u003e\u003d5.3 (releases in May 2019) for the ability to query the"},{"line_number":397,"context_line":"  feature via"},{"line_number":398,"context_line":""},{"line_number":399,"context_line":"Testing"},{"line_number":400,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fce034c_5dd8d51c","line":397,"range":{"start_line":397,"start_character":2,"end_line":397,"end_character":13},"updated":"2019-04-23 10:32:48.000000000","message":"This broken sentence is fixed in next iteration.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":782,"name":"John Garbutt","email":"john@johngarbutt.com","username":"johngarbutt"},"change_message_id":"31496c51b6f90f33d9cf3baa28da4c5d15a87f6c","unresolved":false,"context_lines":[{"line_number":395,"context_line":""},{"line_number":396,"context_line":"* libvirt \u003e\u003d5.3 (releases in May 2019) for the ability to query the"},{"line_number":397,"context_line":"  feature via"},{"line_number":398,"context_line":""},{"line_number":399,"context_line":"Testing"},{"line_number":400,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":401,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_2ffae841","line":398,"updated":"2019-06-04 09:20:58.000000000","message":"I would say we depend on the disto shipping a good VARS file, or the deployer ensuring libvirt knows where the good VARS file lives?","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"cef0a9df3fdec34426e37603fcba2f632f91a4fe","unresolved":false,"context_lines":[{"line_number":395,"context_line":""},{"line_number":396,"context_line":"* libvirt \u003e\u003d5.3 (releases in May 2019) for the ability to query the"},{"line_number":397,"context_line":"  feature via"},{"line_number":398,"context_line":""},{"line_number":399,"context_line":"Testing"},{"line_number":400,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":401,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"9fb8cfa7_3ad0571f","line":398,"in_reply_to":"9fb8cfa7_2ffae841","updated":"2019-06-27 08:32:24.000000000","message":"\u003e I would say we depend on the disto shipping a good VARS file, or\n \u003e the deployer ensuring libvirt knows where the good VARS file lives?\n\nYeah, that\u0027s my thought too—we rely on the distribution shipping a VARS file with default SB keys enrolled.","commit_id":"333be63c64df7dd12b0c5098500336da4427c854"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ab5c46f18137d18fd12796dd1be81a431d06f7ab","unresolved":false,"context_lines":[{"line_number":88,"context_line":""},{"line_number":89,"context_line":"- Make Nova use libvirt\u0027s interface for auto-selecting firmware"},{"line_number":90,"context_line":"  binaries, this was added in libvirt 5.2 [6]_.  This also takes"},{"line_number":91,"context_line":"  advantage of the QEMU\u0027s firmware description schema [7]_.  We will"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"- Make Nova programatically query the getDomainCapabilities() API to"},{"line_number":94,"context_line":"  check if libvirt supports the relevant Secure Boot-related features."}],"source_content_type":"text/x-rst","patch_set":12,"id":"9fb8cfa7_e0cc0d6b","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"updated":"2019-07-02 13:26:56.000000000","message":"?","commit_id":"184930122e5c723b2b8a655c7961bc6a102a0fcd"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"1e40a3991494c44b6c68cf3940b31a1e0f10b638","unresolved":false,"context_lines":[{"line_number":88,"context_line":""},{"line_number":89,"context_line":"- Make Nova use libvirt\u0027s interface for auto-selecting firmware"},{"line_number":90,"context_line":"  binaries, this was added in libvirt 5.2 [6]_.  This also takes"},{"line_number":91,"context_line":"  advantage of the QEMU\u0027s firmware description schema [7]_.  We will"},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"- Make Nova programatically query the getDomainCapabilities() API to"},{"line_number":94,"context_line":"  check if libvirt supports the relevant Secure Boot-related features."}],"source_content_type":"text/x-rst","patch_set":12,"id":"9fb8cfa7_1b1f505b","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"9fb8cfa7_e0cc0d6b","updated":"2019-07-02 13:37:13.000000000","message":"Broken formatting; will fix.  I massively re-adjusted the spec and didn\u0027t re-re-read every point.","commit_id":"184930122e5c723b2b8a655c7961bc6a102a0fcd"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ab5c46f18137d18fd12796dd1be81a431d06f7ab","unresolved":false,"context_lines":[{"line_number":261,"context_line":"      \u003c/features\u003e"},{"line_number":262,"context_line":""},{"line_number":263,"context_line":"   Note that when using libvirt\u0027s firmware auto-selection feature,"},{"line_number":264,"context_line":"   libvirt will auto-addthe SMM feature when starting the guest when SB"},{"line_number":265,"context_line":"   is requested, because SMM and SB go hand-in-hand."},{"line_number":266,"context_line":""},{"line_number":267,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"9fb8cfa7_6007bd83","line":264,"range":{"start_line":264,"start_character":16,"end_line":264,"end_character":27},"updated":"2019-07-02 13:26:56.000000000","message":"auto-add the","commit_id":"184930122e5c723b2b8a655c7961bc6a102a0fcd"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ab5c46f18137d18fd12796dd1be81a431d06f7ab","unresolved":false,"context_lines":[{"line_number":302,"context_line":""},{"line_number":303,"context_line":"   (3.a) Run the ``ovmf-vars-generator`` tool (adjust the parameters"},{"line_number":304,"context_line":"         based on distibution) once::"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"        $\u003e ./ovmf-vars-generator \\"},{"line_number":307,"context_line":"              --ovmf-binary /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd \\"},{"line_number":308,"context_line":"              --uefi-shell-iso /usr/share/edk2/ovmf/UefiShell.iso \\"}],"source_content_type":"text/x-rst","patch_set":12,"id":"9fb8cfa7_4035d943","line":305,"updated":"2019-07-02 13:26:56.000000000","message":"doc generator fails here, I guess because of indent","commit_id":"184930122e5c723b2b8a655c7961bc6a102a0fcd"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"1e40a3991494c44b6c68cf3940b31a1e0f10b638","unresolved":false,"context_lines":[{"line_number":302,"context_line":""},{"line_number":303,"context_line":"   (3.a) Run the ``ovmf-vars-generator`` tool (adjust the parameters"},{"line_number":304,"context_line":"         based on distibution) once::"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"        $\u003e ./ovmf-vars-generator \\"},{"line_number":307,"context_line":"              --ovmf-binary /usr/share/edk2/ovmf/OVMF_CODE.secboot.fd \\"},{"line_number":308,"context_line":"              --uefi-shell-iso /usr/share/edk2/ovmf/UefiShell.iso \\"}],"source_content_type":"text/x-rst","patch_set":12,"id":"9fb8cfa7_9b19007b","line":305,"in_reply_to":"9fb8cfa7_4035d943","updated":"2019-07-02 13:37:13.000000000","message":"Yeah, fixed it in PS-13","commit_id":"184930122e5c723b2b8a655c7961bc6a102a0fcd"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ab5c46f18137d18fd12796dd1be81a431d06f7ab","unresolved":false,"context_lines":[{"line_number":325,"context_line":"   However, as noted earlier, no need to run the above steps manually."},{"line_number":326,"context_line":"   Most common Linux distributions (SUSE, Fedora, RHEL) already ship a"},{"line_number":327,"context_line":"   \"VARS\" file with default UEFI keys enrolled.  Debian and Ubuntu are"},{"line_number":328,"context_line":"   actively working on it [8]_.  And more importantly, when using the"},{"line_number":329,"context_line":"   firmware auto-detection"},{"line_number":330,"context_line":""},{"line_number":331,"context_line":"   If your distribution doesn\u0027t ship a \"VARS\" file with default UEFI"},{"line_number":332,"context_line":"   keys enrolled, here [9]_ is a little Python tool,"}],"source_content_type":"text/x-rst","patch_set":12,"id":"9fb8cfa7_60f1fd6a","line":329,"range":{"start_line":328,"start_character":33,"end_line":329,"end_character":26},"updated":"2019-07-02 13:26:56.000000000","message":"the end of the sentence seems to be missing","commit_id":"184930122e5c723b2b8a655c7961bc6a102a0fcd"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"1e40a3991494c44b6c68cf3940b31a1e0f10b638","unresolved":false,"context_lines":[{"line_number":325,"context_line":"   However, as noted earlier, no need to run the above steps manually."},{"line_number":326,"context_line":"   Most common Linux distributions (SUSE, Fedora, RHEL) already ship a"},{"line_number":327,"context_line":"   \"VARS\" file with default UEFI keys enrolled.  Debian and Ubuntu are"},{"line_number":328,"context_line":"   actively working on it [8]_.  And more importantly, when using the"},{"line_number":329,"context_line":"   firmware auto-detection"},{"line_number":330,"context_line":""},{"line_number":331,"context_line":"   If your distribution doesn\u0027t ship a \"VARS\" file with default UEFI"},{"line_number":332,"context_line":"   keys enrolled, here [9]_ is a little Python tool,"}],"source_content_type":"text/x-rst","patch_set":12,"id":"9fb8cfa7_bb140442","line":329,"range":{"start_line":328,"start_character":33,"end_line":329,"end_character":26},"in_reply_to":"9fb8cfa7_60f1fd6a","updated":"2019-07-02 13:37:13.000000000","message":"Whoops, will fix.","commit_id":"184930122e5c723b2b8a655c7961bc6a102a0fcd"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"ab5c46f18137d18fd12796dd1be81a431d06f7ab","unresolved":false,"context_lines":[{"line_number":374,"context_line":""},{"line_number":375,"context_line":"* QEMU \u003e\u003d2.4 to get Secure Boot support."},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"* QEMU \u003e\u003d4.1.0 (releases in July/August 2019) to get the firmware"},{"line_number":378,"context_line":"  descriptor documents that conform to QEMU\u0027s ``firmware.json``"},{"line_number":379,"context_line":"  specification.  Here [10]_ are some examples of the said \"firmware"},{"line_number":380,"context_line":"  descriptor documents\"."}],"source_content_type":"text/x-rst","patch_set":12,"id":"9fb8cfa7_e0b2cd93","line":377,"updated":"2019-07-02 13:26:56.000000000","message":"This also means that we are not really in a hurry approving it as the QEMU support is not released yet.","commit_id":"184930122e5c723b2b8a655c7961bc6a102a0fcd"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"1e40a3991494c44b6c68cf3940b31a1e0f10b638","unresolved":false,"context_lines":[{"line_number":374,"context_line":""},{"line_number":375,"context_line":"* QEMU \u003e\u003d2.4 to get Secure Boot support."},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"* QEMU \u003e\u003d4.1.0 (releases in July/August 2019) to get the firmware"},{"line_number":378,"context_line":"  descriptor documents that conform to QEMU\u0027s ``firmware.json``"},{"line_number":379,"context_line":"  specification.  Here [10]_ are some examples of the said \"firmware"},{"line_number":380,"context_line":"  descriptor documents\"."}],"source_content_type":"text/x-rst","patch_set":12,"id":"9fb8cfa7_000a8124","line":377,"in_reply_to":"9fb8cfa7_e0b2cd93","updated":"2019-07-02 13:37:13.000000000","message":"This is a \"nice to have\", and it does not block this spec for Train.  Can add that again here.","commit_id":"184930122e5c723b2b8a655c7961bc6a102a0fcd"}]}