| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-05 | |||
| 09:19:41 | aspiers | This is entirely analogous to the need for datacentre operators to tweak legacy BIOS settings over 1000s of machines | |
| 09:20:08 | aspiers | At some point around 2002, people got really tired and fed up of having to do that | |
| 09:20:20 | aspiers | so the h/w vendors gradually introduced ways of programmatically tweaking the BIOS settings | |
| 09:20:34 | aspiers | What we are talking about here is just the 2019 equivalent of that problem | |
| 09:20:35 | kashyap | aspiers: Yeah, I completely agree that manually tweaking BIOS settings at boot-time is fugly | |
| 09:20:42 | kashyap | (And undesirable) | |
| 09:20:58 | aspiers | OK, so do you now see why customisable VARS templates are useful? | |
| 09:21:13 | aspiers | or am I missing another way to achieve the same? | |
| 09:21:53 | kashyap | aspiers: I see the rationale for customizable VARS templates -- | |
| 09:22:37 | kashyap | but for most majority use cases won't need it | |
| 09:22:51 | kashyap | aspiers: On any other way -- we can ask Laszlo (OVMF maint) on email | |
| 09:23:16 | aspiers | Why would most use cases need it any less than people needed to tweak BIOS settings in 2002? | |
| 09:23:31 | aspiers | I would expect more need if anything, since surely UEFI is way more tweakable | |
| 09:23:47 | aspiers | although granted I know very little about UEFI | |
| 09:24:28 | kashyap | Yeah, I don't claim to be an expert either. | |
| 09:26:15 | aspiers | Anyway, that's thinking ahead. So for now it sounds like there is no way to cater for use case #1 - i.e. choosing per SEV image whether to use SB or not | |
| 09:26:29 | kashyap | aspiers: Talking to a BIOS dev: | |
| 09:26:31 | aspiers | so that makes my life a little harder | |
| 09:26:46 | kashyap | 11:24 <kashyap> Do you know of any other way to create customizable VARS files? | |
| 09:26:49 | kashyap | 11:24 <puiterwijk> There's no way, just boot and enter the tianocore bios setup | |
| 09:27:12 | aspiers | kashyap: Sure, *creation* is the easy part. It's the *reuse* which I'm talking about. | |
| 09:27:26 | aspiers | Creation of a VARS template only has to be done once, so manual is fine | |
| 09:27:41 | aspiers | Reuse across 500 VMs is different, however | |
| 09:28:44 | aspiers | Eventually I could imagine uploading VARS template files to (say) glance, and choosing which to use at boot-time via the nova API | |
| 09:29:20 | aspiers | Maybe my use case (testing SEV+SB with stable *and* bleeding edge kernels) is the only use case the world will ever encounter, but that seems unlikely to me. | |
| 09:30:07 | aspiers | Well, the "SEV" component can be dropped from that immediately and the use case is still clearly relevant for kernel devs who care about UEFI and SB | |
| 09:30:57 | kashyap | aspiers: 1 sec | |
| 09:31:28 | kashyap | aspiers: I invited the expert to this channel, Patrick (puiterwijk) -- thanks for joining | |
| 09:31:36 | aspiers | Hi puiterwijk :) | |
| 09:31:43 | puiterwijk | aspiers: hi | |
| 09:32:16 | puiterwijk | the problem is that the VARS file format is internal to TianoCore itself, and there's (to my knowledge) no API guarantee on it, nor an external library to manipulate them. That is also why the enroll script I hacked together just boots an EFI binary that enrolls the keys. And the other one I wrote literally just automates stepping through the BIOS menus | |
| 09:32:19 | aspiers | puiterwijk: If you want you can quickly catch up via the bottom of http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-09-05.log.html | |
| 09:33:11 | aspiers | puiterwijk: Creation of template VARS files is not the hard part here, since that only needs to be done once per template, so doing it manually is fine. | |
| 09:33:33 | aspiers | Reuse across 500 VMs is different, however. | |
| 09:33:53 | puiterwijk | Ah, so what you want is a way to tell nova to use a different vars file template? | |
| 09:33:55 | aspiers | Yes | |
| 09:34:33 | aspiers | Maybe I'm way off here (since I don't know much about UEFI in general) but I would expect that to be useful in the future as use of UEFI gets more sophisticated. What do you think? | |
| 09:34:34 | puiterwijk | Ahhh, I see. Okay, then I retract my comments on how that's hard to automate :). And I think that, based on the questions I got from kashyap, he might also have misunderstood that that was an option | |
| 09:35:21 | puiterwijk | So, the one question I'd have is which BIOS settings you want to tweak regularly? | |
| 09:35:36 | aspiers | In the legacy BIOS world, there are loads | |
| 09:35:40 | puiterwijk | Since based on the settings available in tianocore, I don't think there's that many that are interesting that you can't tweak from external. | |
| 09:35:45 | kashyap | (Hmm, in the scrollback I did mention that using different VARS files _should_ be possible...) | |
| 09:36:06 | puiterwijk | kashyap: ah, okay, sorry. I did not read the full backlog yet. | |
| 09:36:17 | aspiers | Let me look at tianocore settings quickly | |
| 09:36:19 | kashyap | No problem; don't expect you to read everything I ramble :D | |
| 09:36:27 | aspiers | I've never looked at them before | |
| 09:36:45 | puiterwijk | aspiers: so, the ones I'd think are most often changed would be the secureboot settings, and the boot order. And the latter you can tweak directly from qemu | |
| 09:37:05 | puiterwijk | (but sure, there's a bunch of other settings, and there's probably ones I'm just not thinking of right now) | |
| 09:40:02 | kashyap | aspiers: puiterwijk: Oh, something interesting here: https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json | |
| 09:40:12 | puiterwijk | So, I do wnat to make one clarification though that I do see from skimming the backlog: I think we'd always want to use the OVMF *binarY* that has secureboot capabilities compiled in, but that we'd want to change the OVMF *template* (i.e. settings) | |
| 09:40:29 | aspiers | makes sense | |
| 09:40:32 | kashyap | aspiers: So in the firmware descriptor files, there's also an "amd-sev" feature represented: | |
| 09:41:21 | kashyap | 112 # @amd-sev: The firmware supports running under AMD Secure Encrypted | |
| 09:41:24 | kashyap | 113 # Virtualization, as specified in the AMD64 Architecture | |
| 09:41:27 | kashyap | 114 # Programmer's Manual. QEMU command line options related to | |
| 09:41:30 | kashyap | 115 # this feature are documented in | |
| 09:41:32 | kashyap | 116 # "docs/amd-memory-encryption.txt". | |
| 09:41:57 | kashyap | (And libvirt parses this, IIRC) | |
| 09:45:27 | puiterwijk | So, on the multiple vars files: yes, I agree that it would probably be useful to be able to ask nova for a specific vars file to be used. But maybe do require that vars file to be put in place and registered by an admin. | |
| 09:45:38 | aspiers | right | |
| 09:45:46 | puiterwijk | Because even if you only have the secureboot settings, you might want a vars file that has your own custom keys enrolled | |
| 09:45:54 | aspiers | exactly | |
| 09:45:59 | aspiers | it could be an extra spec on the flavor | |
| 09:46:10 | aspiers | hw_uefi_vars or something | |
| 09:46:26 | puiterwijk | Yeah, agreed that that sounds decent | |
| 09:47:07 | aspiers | kashyap: is it worth adding this to http://specs.openstack.org/openstack/nova-specs/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.html ? | |
| 09:47:14 | puiterwijk | (do note that I'm not too deeply integrated into how Openstack (Nova) do things, other than mostly operational and fixing my own bugs, so it might be that this is not in line iwth their design goals) | |
| 09:47:40 | aspiers | puiterwijk: Yeah I'm not sure about this either but I think it's worth suggesting at least | |
| 09:47:54 | puiterwijk | Yep, agreed. | |
| 09:49:21 | aspiers | OK I just managed to fix my broken devstack so maybe I can finally look inside tiano | |
| 09:49:22 | kashyap | puiterwijk: aspiers: Hmm, 'hw_uefi_vars' idea does sound reasonable -- but would need to tackle that _after_ adding initial SB support in the spec | |
| 09:49:30 | aspiers | kashyap: sure | |
| 09:49:48 | puiterwijk | Sure, that sounds fine | |
| 09:50:02 | kashyap | aspiers: And yeah, it does belong to that spec. Should we "extend" the spec later? Or have an additional BP for this? | |
| 09:51:32 | aspiers | kashyap: Very good questions... | |
| 09:52:09 | kashyap | Probably something additional on top will be simpler process-wise. | |
| 09:52:30 | puiterwijk | The problem with adding it on top is: how do the two work together then? | |
| 09:52:49 | puiterwijk | i.e. if I request secureboot per the current blueprint, and then in the later one I ask for another firmware that doesn't have secureboot? | |
| 09:53:00 | kashyap | Heh | |
| 09:53:37 | puiterwijk | (My suggestion would be "if the requested vars isn't secureboot, and secureboot is asked, return error due to invalid config") | |
| 09:53:42 | puiterwijk | or invalid request* | |
| 09:53:44 | kashyap | puiterwijk: I mean, they're _related_ topics, and will be designed to work together | |
| 09:54:06 | aspiers | kashyap: I think it might work as a flavor extra spec | |
| 09:54:15 | aspiers | so the admin controls exactly which templates are available | |
| 09:54:19 | puiterwijk | kashyap: sure. I'm just thinking of what would need to be thought about if talking about a new BP :) | |
| 09:54:51 | kashyap | puiterwijk: Ah, nod. | |
| 09:54:55 | aspiers | How do I get into the TianoCore settings? Escape doesn't work, goes straight to asking for the encrypted disk password | |
| 09:55:06 | puiterwijk | aspiers: boot without working boot options | |
| 09:55:17 | puiterwijk | i.e. detach the disk | |
| 09:55:36 | aspiers | Erm, not sure I can do that in nova | |
| 09:55:42 | puiterwijk | Oh, inside nova... | |
| 09:55:43 | aspiers | It's not a volume | |
| 09:55:49 | puiterwijk | Yeah, I'm not sure either. | |
| 09:55:53 | aspiers | I guess maybe boot from volume | |
| 09:55:55 | aspiers | kashyap: ideas? | |
| 09:56:14 | puiterwijk | aspiers: so... I know that in the Fedora grub, we have an option to "go to system setup" | |
| 09:56:28 | puiterwijk | (because "go to setup" is available as an UEFI call) | |
| 09:56:29 | aspiers | I can get to the grub commandline | |
| 09:56:42 | aspiers | and I can do chainloader (hd0,gpt2)/efi/... | |
| 09:56:43 | puiterwijk | I don't know the grub cmdline for that option right now, let me see in my config | |