| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-29 | |||
| 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 :-( | |
| 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 | the way it works is this: | |
| 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 | So you set up [service_user] with ksa creds and that toggle you pointed out. | |
| 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: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 | |
| 13:22:29 | sean-k-mooney | i had asumeed we would reuse the admin creds that nova already has rather then accept a different set | |
| 13:22:46 | efried | The other ones, if you spell something wrong or mess up your creds, you can't do things. | |
| 13:22:52 | efried | With this one, we can still mostly operate. | |
| 13:23:04 | efried | so how should we behave if you put stuff in but f it up? | |
| 13:23:23 | sean-k-mooney | ya i get the concern about the silent failure | |
| 13:23:39 | efried | Really this is a question we should be addressing with what we have today anyway. | |
| 13:23:46 | sean-k-mooney | if you populated the filed and the password or whatever was wong i woudl expect an error | |
| 13:23:59 | efried | because IMO if you said "I want to do this thing" but we can't work with what you've entered, it should arguably be a failure. | |
| 13:24:03 | efried | right | |
| 13:24:08 | sean-k-mooney | but if you typo the section name that is tricker | |
| 13:24:09 | efried | but that's a separate discussion I think. | |
| 13:24:22 | sean-k-mooney | ok | |
| 13:24:30 | sean-k-mooney | you ansered my question anyway | |
| 13:24:47 | sean-k-mooney | its not as simple as just truning it on and it working | |
| 13:24:53 | sean-k-mooney | so the installer would have to configure it | |
| 13:24:53 | efried | sean-k-mooney: other quirks and details to be aware of: | |
| 13:25:07 | efried | it only applies to some services | |
| 13:25:19 | efried | like, ironic is always admin, so service auth is n/a | |
| 13:25:24 | efried | glance is always user, and it applies there | |
| 13:25:25 | sean-k-mooney | yes appreent glance can recive teh service token but not send it | |
| 13:25:30 | efried | neutron is *sometimes* admin | |
| 13:25:59 | efried | why would glance need to send a service token? | |