| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-29 | |||
| 12:55:03 | sean-k-mooney | so if you are just fixing a commit message then it will generally keep everything else as long as you did not rebase | |
| 12:55:59 | kashyap | sean-k-mooney: The /usr/share/qemu is not weird -- why? Because QEMU (4.1 onwards) _itself_ ships bundled EDK2 + JSON firmware files | |
| 12:56:34 | kashyap | But those distributions building QEMU (and EDK2/OVMF) decouple that and ship separately | |
| 12:56:46 | kashyap | aspiers: I'm writing a "summer time update" to the SUSE folks; look out for an e-mail | |
| 12:57:00 | aspiers | kashyap: great | |
| 12:57:31 | sean-k-mooney | the relationship is inverted if edk2 does not depend on qemu it shouldnt modify qemu directories but anyway i dont really want to dicuss this now | |
| 12:58:09 | sean-k-mooney | if the json files were part of the qemu package the current state makes sense to me | |
| 12:58:21 | coreycb | kashyap: i think he's on pto | |
| 12:58:35 | efried | sean-k-mooney: what's the question? Whether service tokens are still experimental? | |
| 12:58:53 | coreycb | kashyap: this is for qemu 4.1 right? | |
| 12:58:53 | sean-k-mooney | efried: the question is can we enable them by default | |
| 12:59:02 | efried | aspiers: Re Element.getchildren() -- sure; I'm assuming there's a fairly straightforward replacement. | |
| 12:59:05 | sean-k-mooney | efried: or rather should we | |
| 12:59:17 | aspiers | efried: literally just dropping ".getchildren()" | |
| 12:59:25 | aspiers | efried: for child in parent: | |
| 12:59:37 | aspiers | or children = list(parent) | |
| 13:00:08 | sean-k-mooney | efried: they implemented the iterator protocol on the Element class so you can now just use list() itter() or pass it to a for loop and it will loop over the childeren | |
| 13:00:45 | kashyap | coreycb: Yes, it is for QEMU 4.1 (coming out in the 2nd week of August). But no need to wait for the release | |
| 13:01:17 | kashyap | aspiers: A quick one: what is the package called on SUSE? 'edk2' or 'edk2-ovmf' or 'ovmf'? | |
| 13:01:19 | efried | aspiers: neat. Then yeah, for sure, let's get a patch up. | |
| 13:01:43 | coreycb | kashyap: right so from what i understand 19.10 won't have qemu 4.1 so we have time. it's slated for 20.04. | |
| 13:03:32 | efried | sean-k-mooney: When you say enable by default, the operator would still have to put admin creds into the service_user section of the conf to make it work; you're just suggesting getting rid of the need for the extra [service_user]send_service_user_token granny switch? | |
| 13:04:09 | aspiers | kashyap: not sure but you can probably find out from these ... https://build.opensuse.org/package/view_file/SUSE:SLE-12-SP4:Update/ovmf/ovmf.spec?expand=1 | |
| 13:04:16 | aspiers | https://build.opensuse.org/package/view_file/SUSE:SLE-15:Update/ovmf/ovmf.spec?expand=1 | |
| 13:04:23 | kashyap | coreycb: When is 20.04 out? | |
| 13:04:36 | kashyap | coreycb: Note: this _doesn't_ require QEMU 4.1 per-se | |
| 13:04:48 | aspiers | https://build.opensuse.org/package/show/hardware:boot/edk2 | |
| 13:05:09 | coreycb | kashyap: april of 2020. right but i imagine that's how it will be prioritized. | |
| 13:05:23 | sean-k-mooney | efried: i may not fully understand this feature but i was fering to removing of chaning the defualt of https://github.com/openstack/nova/blob/master/nova/conf/service_token.py#L28-L43 | |
| 13:05:33 | kashyap | aspiers: Actually, I found it documented in my own spec :-) -- the pacakge in SLES is called: qemu-ovmf-x86_64 | |
| 13:05:41 | aspiers | efried, kashyap: so SEV needs UEFI and currently the only way to activate this is hw_firmware_type=uefi on the image. What if an image without this is booted with hw:mem_encryption='True' ? | |
| 13:06:06 | aspiers | Should nova throw an error, or impose uefi on the image? | |
| 13:06:15 | sean-k-mooney | i guess you also need to set up the service user | |
| 13:06:17 | aspiers | sean-k-mooney: interested in your opinion too | |
| 13:06:29 | kashyap | coreycb: Well, why can't the package be even available in the "latest" Git distro? (In Fedora's terms, "Rawhide") | |
| 13:06:44 | kashyap | coreycb: Fedora already ships these for a couple of weeks. There's no reason to delay this | |
| 13:06:56 | sean-k-mooney | aspiers: does sev only work with uefi guests | |
| 13:07:02 | aspiers | yes | |
| 13:07:09 | coreycb | kashyap: i'm not the maintainer i'm just assuming how it will work | |
| 13:07:29 | aspiers | it's mentioned in the spec | |
| 13:07:32 | sean-k-mooney | then you should have a check in the api and reject the spawn before we create a request spec or instance object | |
| 13:07:32 | kashyap | aspiers: Hmm, I'd say "impose UEFI on the image" -- if it's a prereq for SEV -- but ... I don't off-hand if any caveats need to be thought out | |
| 13:07:33 | aspiers | albeit briefly | |
| 13:08:02 | aspiers | kashyap: I'm more inclined to agree with sean-k-mooney's suggestion here | |
| 13:08:08 | aspiers | let's see what efried thinks | |
| 13:08:09 | kashyap | coreycb: Noted. I'd also assume any other Debian packager submitting the change / patch shold be accepted. I hope the process is not blocked on a single maintainer. | |
| 13:08:35 | sean-k-mooney | you can do it like this https://review.opendev.org/#/c/671338/4/nova/compute/api.py | |
| 13:08:47 | kashyap | aspiers: Yeah, nod. I was thinking in terms of how libvirt auto-adds 'smm' bit when requesting Secure Boot. But that's not an analogy at all | |
| 13:08:47 | efried | 2) make the operation fail if hw:mem_encryption=True but hw_firmware_type!=uefi | |
| 13:08:47 | efried | 1) make hw_firmware_type=uefi automatic when hw:mem_encryption=True (or... vice versa?) | |
| 13:08:47 | efried | aspiers: I don't know what any of that means, but it sounds like you've got a couple of choices: | |
| 13:08:53 | efried | oh | |
| 13:08:57 | efried | that's exactly what you just said. | |
| 13:09:13 | sean-k-mooney | just add a check to _validate_flavor_image_nostatus | |
| 13:10:12 | efried | I don't understand this uefi thing well enough to render an opinion (like, what could go wrong if you set it implicitly, what is the impact of doing this thing the user didn't ask for, etc.) | |
| 13:10:40 | aspiers | efried: I'm assuming that images need some UEFI support magic baked in | |
| 13:10:50 | sean-k-mooney | efried: the host would have to be configured with uefi firmware to be able to enable it. | |
| 13:10:51 | aspiers | but I don't actually know | |
| 13:11:16 | aspiers | does the scheduler know whether hosts support UEFI? | |
| 13:11:27 | kashyap | aspiers: At this point, no. | |
| 13:11:39 | sean-k-mooney | aspiers:for a uefi boot there would have to be a gpt partion on the image and it would need a efi boot partion to unpack the efi into | |
| 13:11:41 | efried | If the host needs uefi-ness, then that needs to be part of determining whether the host exposes the SEV capability and the MEM_ENC_CTX inventory. | |
| 13:11:47 | sean-k-mooney | i think | |
| 13:12:13 | aspiers | efried: every SEV host will support UEFI | |
| 13:12:34 | aspiers | efried: in fact I'm guessing also every host made in the last $NOT_SMALL years | |
| 13:12:51 | sean-k-mooney | basicaly uefi booth need (typically) a 1M partition for use by the uefi firmware. if that is not in the disk image then the firmeware suppoied by the host wont work | |
| 13:13:03 | aspiers | so it's not an issue for SEV, but it might be for hw_firmware_type in general | |
| 13:13:19 | aspiers | sean-k-mooney: thanks, that's extremely helpful | |
| 13:13:41 | aspiers | and also scary because it highlights that I might have no easy way of getting a UEFI-capable SLES image :-( | |
| 13:13:53 | sean-k-mooney | the only time i have used uefi with vms sofar i have installed from iso so it did the right thing | |
| 13:14:46 | sean-k-mooney | no idea if the cloud image are set up to work out of the box but i know disk image builder used to have issue with non msdos partion tables and i dont know if it can work wtih gpt partion tables yet so im guessing people milage will vary on this one | |
| 13:14:59 | efried | okay, so you can't just toggle that property on an image and expect it to work. | |
| 13:15:04 | efried | that answers the question, right? | |
| 13:15:19 | sean-k-mooney | you cant assuem it will work correct | |
| 13:15:24 | aspiers | right | |
| 13:15:30 | efried | then do the validation thingy | |
| 13:15:35 | aspiers | so yeah I'll follow sean-k-mooney's suggestion | |
| 13:15:38 | aspiers | thanks all | |
| 13:15:47 | efried | sean-k-mooney: re service auth... | |
| 13:16:49 | sean-k-mooney | efried: ya so looking at the config code i was not aware we had to expclitly set addtional credentials that were not alreday required | |
| 13:17:18 | efried | And we wrap your user token in what is effectively an admin token, which we then use if the user token expires. | |
| 13:17:18 | efried | So you set up [service_user] with ksa creds and that toggle you pointed out. | |
| 13:17:18 | efried | Some services do long-running operations, followed by other operations. Your user token may expire during the long-running operation, and then you would bounce on the subsequent operations. | |
| 13:17:18 | efried | the way it works is this: | |
| 13:17:30 | efried | Yeah, the stealth inclusion of ksa creds is easy to miss | |
| 13:17:50 | efried | so basically it looks like that conf only has one option, but it really has like a dozen -- all the ksa auth/session/adapter stuff. | |
| 13:18:14 | sean-k-mooney | ya i kind of glossed over the bottm of the file as i assume it was the normal boiler plate but looking at it now i see its not | |
| 13:18:25 | efried | So today you have to have that toggle switched on for us to even try loading up the ksa stuff. | |
| 13:18:43 | efried | if we turned off that toggle, we would try loading up the ksa stuff and if it fails just carry on with the user token as is | |
| 13:18:51 | efried | which is basically what we do today if you have the switch on anyway. | |
| 13:19:32 | efried | what's not clear is, if that toggle is gone, how should we behave if we can't load up the ksa bits? Just warn as we do today and carry on using the user token presumably | |
| 13:19:34 | sean-k-mooney | ya the context for this was there was a discussion downstream of if/when we will start supproting this in our product | |
| 13:19:56 | efried | but if the op doesn't *want* to use service auth, they're getting a warning for doing what they wanted. | |
| 13:20:21 | sean-k-mooney | efried: well i think the present of the service user in the config would be enough to singnel this no? | |
| 13:20:31 | sean-k-mooney | e.g. if you put it in the config we asssume you want to use it | |
| 13:20:37 | sean-k-mooney | if you didnt we assume you dont | |
| 13:20:55 | sean-k-mooney | is ther service_user section used for anythin else currently? | |
| 13:21:25 | sean-k-mooney | if so the toggle makes sense if not then its a needless extra step | |
| 13:21:55 | sean-k-mooney | but in anycase its not as simple as jsut enabling it by defualt. the operator need to add serveice_user creds | |
| 13:22:27 | efried | right, but it's a bit different than the other auth sections | |