| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-04 | |||
| 09:30:38 | johnthetubaguy | the proposed change thing: (1) copy hyper-v interface, (2) libvirt does all the work when we add the above XML, (3) scheduling to make sure we get on a capable host | |
| 09:30:56 | johnthetubaguy | is there anything else from the "changes to nova" sense? | |
| 09:31:23 | kashyap | johnthetubaguy: For the (2) part, we need to expand that: introduce libvirt config classes, etc? | |
| 09:32:20 | kashyap | johnthetubaguy: No, from the list of three, I don't think there's any further, from "changes to Nova" sense. | |
| 09:32:29 | johnthetubaguy | I would do the reverse, this is the magic we put in the XML... PS this is what that really means | |
| 09:33:18 | johnthetubaguy | from the scheduling, I think in the comments it noted that the libvirt driver would add a secure_boot capability style trait if its capable | |
| 09:33:19 | kashyap | Right, noted. | |
| 09:33:32 | johnthetubaguy | I guess we need to ask libvirt if we can do that, once libvirt is the correct version? | |
| 09:34:31 | kashyap | Yes, we need to query via `capabilities` | |
| 09:34:41 | kashyap | To look if it supports the "secure" flag for 'efi' | |
| 09:34:46 | johnthetubaguy | cool | |
| 09:34:54 | johnthetubaguy | so its "a little bit" like this: https://github.com/openstack/nova/blob/2ea6e6f8db9fc6cecf389cacdd0d82d8226b99fb/nova/virt/libvirt/driver.py#L334 | |
| 09:35:07 | kashyap | s/capabilities/getDomainCapabilities/ | |
| 09:35:09 | johnthetubaguy | in that its a conditional capability | |
| 09:36:00 | kashyap | johnthetubaguy: (Aside: While implementing, I could use some help on the scheduling bits, it's my weak area.) | |
| 09:36:22 | johnthetubaguy | so I fear the spec needs to cover the rough details of what is going to happen there | |
| 09:36:24 | johnthetubaguy | https://github.com/openstack/nova/blob/2ea6e6f8db9fc6cecf389cacdd0d82d8226b99fb/nova/virt/libvirt/driver.py#L4959 | |
| 09:36:33 | johnthetubaguy | I guess its an extension of that | |
| 09:37:07 | kashyap | johnthetubaguy: Yeah, indeed: Need to write: _has_uefi_secure_boot_support() | |
| 09:37:34 | johnthetubaguy | how to we schedule for uefi today... I don't rightly remember | |
| 09:37:55 | kashyap | We don't do any scheduling decisions for UEFI, IIRC | |
| 09:40:05 | kashyap | johnthetubaguy: Do you see anything contrary to what I say in the code? | |
| 09:41:18 | johnthetubaguy | kashyap: not so far... just re-reading the hyper-v spec | |
| 09:42:10 | johnthetubaguy | do we not need os_secure_boot_signature? | |
| 09:42:17 | johnthetubaguy | ref: https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/hyper-v-uefi-secureboot.html | |
| 09:42:37 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Policy Default Refresh spec https://review.opendev.org/547850 | |
| 09:44:50 | kashyap | johnthetubaguy: I _think_ for the first iteration, it should be optional. | |
| 09:45:03 | kashyap | `os_secure_boot_signature` allows specifying bootloader's signature | |
| 09:45:17 | kashyap | I need to play a bit more to see how strongly we need it | |
| 09:45:47 | kashyap | johnthetubaguy: Because, the OVMF maintainer says: if you don't trust the default UEFI keys, then it is almost the same as you're not trusting the filesystem where your Compute node is running | |
| 09:46:08 | johnthetubaguy | so you know... I think this was before the distros shipped trusted default keys | |
| 09:46:27 | kashyap | Yeah, very true. | |
| 09:46:29 | johnthetubaguy | lets just add in the spec that we only support using the default keys in the first implementation? | |
| 09:46:44 | kashyap | johnthetubaguy: Yes, very much worth it to spell it out | |
| 09:54:06 | johnthetubaguy | kashyap: so I just added an extra note to give a summary of what I was thinking for the proposed changes section | |
| 09:54:22 | johnthetubaguy | I am tempted to say this first version follows UEFI and simple errors out if not supported? | |
| 09:55:00 | johnthetubaguy | then in the alternatives but that in the future a request spec filter can be added similar to the existing image type filter | |
| 09:56:06 | johnthetubaguy | kashyap, the release note for hyper-v is quite nice: https://github.com/openstack/nova/blob/c6218428e9b29a2c52808ec7d27b4b21aadc0299/releasenotes/notes/hyperv-uefi-secure-boot-a2a617ac2c313afd.yaml | |
| 09:56:57 | kashyap | johnthetubaguy: Looking... | |
| 09:57:04 | kashyap | johnthetubaguy: Meanwhile, just typed this up: http://kashyapc.fedorapeople.org/Feedback-to-address-SecureBoot-spec.txt | |
| 09:57:38 | kashyap | johnthetubaguy: Yes, we should error-out simply if there's no support | |
| 09:57:50 | kashyap | johnthetubaguy: Can you explain a bit more on the request spec filter alternative? | |
| 09:58:03 | johnthetubaguy | yeah | |
| 09:58:32 | kashyap | johnthetubaguy: Yes, we'll write an equally good release note :-) | |
| 09:58:58 | johnthetubaguy | so the code for the image one is here: https://github.com/openstack/nova/blob/0c9c422c878719bae5b97fd07cafe7cd933bf103/nova/scheduler/request_filter.py#L124 | |
| 10:00:13 | johnthetubaguy | for secure boot, I think we look at the flavor and image to work out if secure_boot is required, and if it is we would request the trait the driver capabilties could advertise like SECURE_BOOT_CAPABLE or something like that | |
| 10:01:10 | kashyap | Ah-ha, noted. | |
| 10:01:15 | kashyap | johnthetubaguy: Thanks for the explanation. | |
| 10:01:19 | johnthetubaguy | no worries | |
| 10:01:40 | johnthetubaguy | so I attempted a summary comment here: https://review.opendev.org/#/c/506720/11/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.rst@82 | |
| 10:02:01 | kashyap | johnthetubaguy: Excellent, reading it already | |
| 10:03:06 | kashyap | johnthetubaguy: Can you also compare my notes here, the 2nd point: http://kashyapc.fedorapeople.org/Feedback-to-address-SecureBoot-spec.txt | |
| 10:03:31 | kashyap | This week, I'm going to address that, plus other items you noted in the review. | |
| 10:03:48 | kashyap | Will make it ready by end of this week, to keep the momentum, and not let it languish | |
| 10:04:50 | kashyap | Not least because ... "One who delays his work is always wrestling with ruin." | |
| 10:05:17 | johnthetubaguy | I may have changed my mind on some of the things in your notes... | |
| 10:05:35 | johnthetubaguy | problem description is good | |
| 10:05:43 | johnthetubaguy | use cases, I would just focus on the first one | |
| 10:05:52 | kashyap | Okay, will adjust | |
| 10:05:52 | johnthetubaguy | ... I am tempted to focus only on the guest level protection | |
| 10:06:03 | johnthetubaguy | then reference the other white paper for more details | |
| 10:06:14 | johnthetubaguy | that way its not our job to review it / keep it correct :) | |
| 10:06:25 | kashyap | Yes, indeed | |
| 10:07:00 | johnthetubaguy | that hypervisor kernel protection... surely a bad hypervisor could spoof things to the guest, claiming its really a good little hypervisor? | |
| 10:07:51 | johnthetubaguy | i.e. that is what folks want attestation and secure boot of the hypervisor... which is a different thing, and in some ways, an ironic level feature | |
| 10:07:58 | kashyap | johnthetubaguy: Hm, I'm not really sure, afraid. Can ask Laszlo (OVMF maintainer) to comment | |
| 10:08:12 | johnthetubaguy | so I think we should only claim the guest protection at this point | |
| 10:08:29 | kashyap | johnthetubaguy: BTW, we're only talking here about *guest*-level protection, indeed -- not baremetal, that's out of scope, as we know :-) | |
| 10:08:33 | johnthetubaguy | fairly sure you need hypervisor secure boot for the other thing, along with active atestation | |
| 10:08:43 | johnthetubaguy | cool | |
| 10:08:51 | johnthetubaguy | lets just make that clear | |
| 10:09:29 | johnthetubaguy | one extra comment, the enrolement of keys, and the context so you know what the means seems well worth explaining, probably under "other deployer impact", its kinda like a dependency of the system setup | |
| 10:09:43 | gmann | johnthetubaguy: this is ready for review, i have updated the mapping of new and old roles. - https://review.opendev.org/#/c/547850/ | |
| 10:09:44 | kashyap | We're only concerned about the case of: "If you don't trust what is inside the VM" -- that's what SB protects you from. | |
| 10:09:59 | gmann | also added fallback idea in Alternate section | |
| 10:10:15 | johnthetubaguy | so basically, we need all the details you have put together in the spec, just prehaps they need to move around a little bit. | |
| 10:10:16 | gmann | i will be here for another ~2 hours for updating it. | |
| 10:10:19 | kashyap | johnthetubaguy: Okay, will add a clarifying note that here, Secure Boot is only dealing with guest-level protection. | |
| 10:10:27 | johnthetubaguy | sweet, sounds good | |
| 10:10:31 | kashyap | johnthetubaguy: Yeah, I'll reorganize with a fresh mind early tommorrow. | |
| 10:10:41 | kashyap | I need time to process all of this :-) | |
| 10:11:08 | johnthetubaguy | kashyap: great work on this though, its a nasty can of worms, which thanks to your spec, I think I understand much better now, let's not loose that in the reworking! | |
| 10:11:56 | kashyap | johnthetubaguy: Yeah, won't lose. It's been more than a year ago, when I started this QEMU thread: | |
| 10:12:06 | kashyap | https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01978.html -- [RFC] Defining firmware (OVMF, et al) metadata format & file | |
| 10:12:29 | johnthetubaguy | I remember discussion it (and getting confused) when we were snowed in | |
| 10:12:30 | kashyap | johnthetubaguy: Thanks a _ton_ for this focussed review time. I find this approach very effective. | |
| 10:12:49 | johnthetubaguy | kashyap: me too, its much better than three weeks of back and forth | |
| 10:13:11 | johnthetubaguy | gmann: talking a look at yours now | |
| 10:13:24 | kashyap | Right, a lot of complexity is reduced. I'm glad there's someone like you, a "hypervisor person", who can see all the "can of worms" | |
| 10:13:59 | kashyap | Alrightie, I've got enough to chisel away | |
| 10:14:01 | kashyap | johnthetubaguy++ | |
| 10:14:25 | johnthetubaguy | kashyap: cool, looks really promising | |
| 10:14:46 | kashyap | Now only the "small matter of programming" remaining :D | |
| 10:17:51 | johnthetubaguy | gmann: line 90, I think we mean change the DB check from role:admin to scope:system? | |
| 10:18:52 | johnthetubaguy | or rather, change from "role:admin" to "scope:system" when enforce_scope = True ? | |
| 10:21:01 | kashyap | johnthetubaguy: A quick typo thing: did you mean Chris, instead of Eric here: https://review.opendev.org/#/c/506720/11/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.rst@98 | |
| 10:21:22 | kashyap | (Because there was no comment from Eric there :-)) | |
| 10:21:28 | gmann | johnthetubaguy: second one, when enforce_scope is true then we will start checking system scope | |
| 10:21:50 | johnthetubaguy | kashyap: oops yes, I was thinking about the previous one clearly | |
| 10:21:59 | kashyap | Yeah, figured as much. | |