| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-04 | |||
| 09:09:19 | johnthetubaguy | yeah, that is the bit | |
| 09:09:35 | kashyap | I have a TODO to trim that second point to reflect that. | |
| 09:19:06 | johnthetubaguy | kashyap: so this sounds harsh... but I think you need to turn your spec upside down, given the new libvirt version, and I guess that is what you are thinking too | |
| 09:19:35 | kashyap | johnthetubaguy: Sorry, what do you mean upside down? | |
| 09:19:49 | kashyap | johnthetubaguy: You mean, push the content from Work Items a bit above? | |
| 09:20:12 | kashyap | Noting clearly that the new libvirt (and QEMU, OVMF / EDK2) version handles most of the work for us? | |
| 09:20:46 | kashyap | (All harsh feedback is welcome :-) After spending so much time on my text, I need other eyes to help edit it.) | |
| 09:20:56 | kashyap | s/other/others'/ | |
| 09:21:32 | johnthetubaguy | kashyap: trying to work out how to describe what I am thinking :) | |
| 09:22:09 | kashyap | johnthetubaguy: Sure. Whatever brings clarity. | |
| 09:22:12 | johnthetubaguy | so overall I think we are largely there, libvirt does all the work, it clearly is something useful | |
| 09:22:43 | kashyap | "No mind is ever willingly deprived of the truth" — Plato | |
| 09:22:51 | kashyap | johnthetubaguy: Yeah, indeed. | |
| 09:23:18 | johnthetubaguy | so I think this spec was needed before libvirt did all the hard work | |
| 09:23:37 | johnthetubaguy | and we still need a bunch of the detail for sure | |
| 09:23:46 | johnthetubaguy | just wondering first about what is missing | |
| 09:23:51 | johnthetubaguy | ... so the last two work items | |
| 09:24:37 | johnthetubaguy | actually, that is back to front, maybe I just say what I think I was expecting... which doesn't make it the right or only way, its just a data point | |
| 09:25:01 | kashyap | Yeah, noted. | |
| 09:25:10 | kashyap | Also, it's not just the last two points, surely? | |
| 09:25:48 | kashyap | Also the point on making Nova use the firmware auto-selection feature? | |
| 09:25:49 | kashyap | <os firmware='efi'> | |
| 09:25:49 | kashyap | <loader secure='yes'/> | |
| 09:25:49 | kashyap | </os> | |
| 09:25:56 | johnthetubaguy | yeah, totally | |
| 09:26:14 | johnthetubaguy | lets go through each bit of the spec quickly, I think its close | |
| 09:26:22 | kashyap | Certainly. | |
| 09:26:54 | johnthetubaguy | so problem and use cases, I think you could simplify it a little bit, line 51-52 and line 42-44 are good | |
| 09:27:47 | kashyap | Right, I'll reword the "or other kernel code ..." thing, if you prefer. | |
| 09:28:05 | johnthetubaguy | well, I mean those lines are vital... i.e. you need this for guests to protect against certain kinds of maleware, and by the way we already added this for hyper-v | |
| 09:28:08 | kashyap | (It's just saying: either guest side malware or malware from kernel modules) | |
| 09:28:25 | johnthetubaguy | the hypervisor kernel modules? | |
| 09:28:28 | kashyap | johnthetubaguy: Added what? (The SecureBoot feature? Sure) | |
| 09:28:31 | kashyap | Yes | |
| 09:28:58 | johnthetubaguy | hmm, OK, I guess it does... :/ not sure | |
| 09:29:21 | johnthetubaguy | anyways, the guest malware seems the key thing for the user | |
| 09:29:29 | johnthetubaguy | sweet | |
| 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 | |