| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-04 | |||
| 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. | |
| 10:22:01 | kashyap | Thx. | |
| 10:22:35 | johnthetubaguy | gmann: yeah, the steps bit is a bit out of date now I think | |
| 10:24:10 | johnthetubaguy | gmann: I just added comments on the first 100 lines, going to keep going now | |
| 10:24:30 | gmann | johnthetubaguy: thanks, checking.. | |
| 10:32:16 | yaawang | johnthetubaguy: Hi, could you please taking a look at the auto-converge/post-copy spec? I have replied your commets. https://review.opendev.org/#/c/651681/ | |
| 10:33:37 | johnthetubaguy | yaawang: ah, I meant to follow up with your spec, will have a look | |
| 10:34:44 | yaawang | johnthetubaguy: Great | |
| 10:36:59 | johnthetubaguy | yaawang: sorry, I think I miss-understood your use case | |
| 10:37:29 | johnthetubaguy | yaawang: could you describe to me why a workload prefers auto converge vs post copy? | |
| 10:37:42 | johnthetubaguy | is it the slowing down of the guest it wants to avoid? | |
| 10:37:59 | johnthetubaguy | or the pausing of the guest it want's to avoid | |
| 10:38:19 | gmann | johnthetubaguy: to be clear on DB check change. currently we check hard coded is_admin for few place which is going to be change to check if requested token is scoped to system. | |
| 10:38:35 | johnthetubaguy | gmann: but... is_admin is set via policy | |
| 10:38:56 | gmann | johnthetubaguy: yes, by checking is_context_admin which internally check admin role | |
| 10:39:47 | johnthetubaguy | gmann: I think thinking we can hardcode to context.system_scope == "all" for the DB check, probably needs a new name though | |
| 10:39:49 | yaawang | johnthetubaguy: Ok, please wait... | |
| 10:40:02 | johnthetubaguy | yaawang: no problem | |
| 10:40:58 | gmann | johnthetubaguy: yeah. something like that and then set is_system or something on context like ^^ | |
| 10:41:34 | gmann | johnthetubaguy: updated my local copy of spec with your comments till L100. waiting for next | |
| 10:44:20 | johnthetubaguy | gmann: yeah, I think so... the key bit in the ordering is to allow us to implement the System Reader role, without breaking the project_id protection. i.e. the role:admin no longer works for list servers in all projects | |
| 10:44:32 | johnthetubaguy | really just talking out loud to check my thinking there | |
| 10:46:34 | yaawang | johnthetubaguy: If the compute node enable auto-converge, it will slow down CPU and memory I/O to make it easy to live-migrate to other compute node. | |
| 10:46:39 | yaawang | johnthetubaguy: But it means all vms on the compute node will use auto-converge during live-migration even the vm can live-migrate to other compute node without auto-converge/post-copy. | |
| 10:46:57 | yaawang | johnthetubaguy: For some applications(such as scientific computing applications) is sensitive to performance reduce or memory I/O error, these vms do not want to use auto-converge/post-copy during live-migration. | |
| 10:47:56 | openstackgerrit | Merged openstack/os-traits master: Create trait for NUMA subtree affinity https://review.opendev.org/657898 | |