| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-29 | |||
| 12:47:19 | kashyap | sean-k-mooney: The JSON files don't exist yet on Debian | |
| 12:47:20 | sean-k-mooney | /usr/share/OVMF/OVMF_CODE.fs | |
| 12:47:23 | sean-k-mooney | /usr/share/OVMF/OVMF_CODE.fd | |
| 12:47:36 | aspiers | sean-k-mooney: that's not the json files | |
| 12:47:42 | aspiers | that's the blobs | |
| 12:47:43 | kashyap | sean-k-mooney: We're talking about .json files | |
| 12:47:43 | sean-k-mooney | oh the json file is seperate form the firmware image | |
| 12:48:03 | kashyap | Here are the RFEs I filed for Debian/Ubuntu: | |
| 12:48:11 | kashyap | (1) Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932269 | |
| 12:48:11 | openstack | Debian bug 932269 in ovmf "Ship the firmware "descriptor files" as part of the 'ovmf' package" [Normal,Open] | |
| 12:48:12 | sean-k-mooney | no its fine | |
| 12:48:18 | kashyap | (2) Ubuntu: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1836859 | |
| 12:48:18 | openstack | Launchpad bug 1836859 in edk2 (Ubuntu) "RFE: Ship the firmware "descriptor files" as part of the 'ovmf' package" [Undecided,New] | |
| 12:49:10 | kashyap | coreycb: Hi, any update on the above from 'dannf'? --^ | |
| 12:49:32 | kashyap | coreycb: Sorr for pestering; I'll be off from 06-Aug to 23-Aug, trying to get it into Ubuntu by then | |
| 12:49:53 | kashyap | coreycb: It's a simple change, just requires one to go through the motions and get a package build out. | |
| 12:49:57 | sean-k-mooney | they may still decide to package tehm in a different location but you know more about it then i | |
| 12:50:33 | kashyap | sean-k-mooney: They can package it in whatever location - it doesn't matter, so long as they're shipping the JSON file with their custom path. | |
| 12:50:37 | sean-k-mooney | i think its somewhat confusing that they are in the qemu directory and not in OVMF | |
| 12:51:09 | kashyap | sean-k-mooney: That is what the QEMU firmware specifcation looks for. | |
| 12:51:17 | kashyap | https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json#l312 | |
| 12:51:31 | kashyap | 312 # - /usr/share/qemu/firmware -- populated by distro-provided firmware | |
| 12:51:34 | kashyap | 313 # packages (XDG_DATA_DIRS covers | |
| 12:51:37 | kashyap | 314 # /usr/share by default), | |
| 12:51:44 | sean-k-mooney | i guess it depends on if its in the qemu package or ovmf package | |
| 12:51:53 | sean-k-mooney | its edk2 | |
| 12:52:20 | kashyap | For distributions shipping EDK2/OVMF, they should ship these files as part of that package. | |
| 12:53:19 | sean-k-mooney | right so it seam weird that that package would add somthing to the qemu firmware folder unless that package has a hard depency on qemu e.g. it cant be instlled without it | |
| 12:54:06 | aspiers | kashyap: weirdly, changing the commit message only invalidated the V+1 of that commit, not all the others rebased above it | |
| 12:54:20 | sean-k-mooney | yep | |
| 12:54:40 | sean-k-mooney | if gerrit can tell that the rest of the content did not change it wont drop the +/- 1 | |
| 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 | sean-k-mooney | efried: the question is can we enable them by default | |
| 12:58:53 | coreycb | kashyap: this is for qemu 4.1 right? | |
| 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 | 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: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: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 | efried | aspiers: I don't know what any of that means, but it sounds like you've got a couple of choices: | |
| 13:08:47 | efried | 1) make hw_firmware_type=uefi automatic when hw:mem_encryption=True (or... vice versa?) | |
| 13:08:47 | efried | 2) make the operation fail if hw:mem_encryption=True but hw_firmware_type!=uefi | |
| 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: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 :-( | |