| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-04 | |||
| 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 | |
| 10:49:52 | gmann | johnthetubaguy: if deployment say scope enforcement and token is not scoped to system then yes role:admin will not be able to list all project's servers | |
| 10:50:44 | johnthetubaguy | yaawang: makes sense to me, but why do you want to use auto-converge for the other workloads? Maybe you just want to disable auto-converge in your cloud? | |
| 10:51:14 | johnthetubaguy | yaawang: also, have you seen this interesting look at live-migration, I am curious if you see the same things: https://www.berrange.com/posts/2016/05/12/analysis-of-techniques-for-ensuring-migration-completion-with-kvm/ | |
| 10:51:28 | gmann | with system reader (because of system_scope:all in check_str) it will keep checking the system scope even enforce_scope if false. so we would not break project_id protection there | |
| 10:54:47 | johnthetubaguy | gmann: true, I might be worrying too much, anyways the role:admin check will break System Reader | |
| 10:58:30 | yaawang | johnthetubaguy: Some vms do not want to use auto-converge/post-copy, but the other can use these feature. Auto-converge/post-copy can help vm live-migrate more faster, it's good to vm which can accept the performance reduce. Disable auto-converge/post-copy means all vms can't use them, it's not a good idea to users. | |
| 11:05:38 | johnthetubaguy | yaawang: for the VMs that don't want post copy or auto-converge, what do they want instead? are they OK being paused for longer, so the performance is more predicable during the live-migration? | |
| 11:19:43 | yaawang | johnthetubaguy: Just normal live-migration without any addition option, the main point is decrease the effort of source vm's performance. If the user call force-complete API, nova will pause the vm, it may not a good idea for now :(. But there are no more good idea. | |
| 11:27:50 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type https://review.opendev.org/662887 | |
| 11:27:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM/WIP blockinfo: Use SATA bus for cdrom devices when using q35 https://review.opendev.org/663011 | |
| 11:28:01 | lyarwood | mdbooth / kashyap ^ q35 hackaround as discussed, tempest is passing locally using q35 again, I'll sort the unit tests out now. | |
| 11:28:15 | sean-k-mooney | lyarwood: isnt that in a docs comment somewhere | |
| 11:28:21 | sean-k-mooney | lyarwood: e.g. you have to use sata | |
| 11:28:27 | sean-k-mooney | because ide is not supported | |
| 11:28:40 | sean-k-mooney | im pretty sure we discussed needing to do that months ago | |
| 11:28:51 | sean-k-mooney | im guessing your just adding it now :) | |
| 11:28:54 | lyarwood | not that I can see | |
| 11:29:08 | lyarwood | it likely came up | |
| 11:29:27 | sean-k-mooney | i remember talking to kasabp about it during the stien cycle | |
| 11:29:46 | sean-k-mooney | i was going to say before chritmas but i think it was early january | |
| 11:29:56 | lyarwood | right, I think the action just slipped through the cracks and we missed the impact on config drive users | |
| 11:30:13 | sean-k-mooney | ah ya makes sense | |
| 11:30:25 | sean-k-mooney | they could se hw_cdrom_bus | |
| 11:30:29 | sean-k-mooney | they could se hw_cdrom_bus=sata | |
| 11:30:33 | sean-k-mooney | as a workaourd | |
| 11:30:35 | sean-k-mooney | but ya | |
| 11:31:01 | kashyap | lyarwood: Yeah, will look | |
| 11:32:09 | johnthetubaguy | yaawang: so I want to support your use case, but I am really against "use post copy" and "use auto converge" as things we expose. I really want to have something that doesn't depend on how we implement it, I am adding some ideas / alternatives in the spec comments. | |
| 11:32:42 | kashyap | johnthetubaguy: Yeah, I see what you mean on that; me also needs to look at that spec | |
| 11:34:09 | yaawang | johnthetubaguy: I've replied your comment about why not only use post-copy. | |
| 11:34:16 | johnthetubaguy | kashyap: yeah, I found something in google's APIs that I think expresses the user intent better | |