| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-05 | |||
| 09:04:11 | aspiers | kashyap: I'm confused by that commit, because even without it I *already* see the vars files persisting in /var/lib/libvirt/qemu/nvram | |
| 09:04:26 | kashyap | aspiers: The VARS file contains anything a user configures. | |
| 09:04:28 | aspiers | Oh, that's the bug | |
| 09:04:54 | kashyap | aspiers: The context is: just like traditional BIOS, UEFI has menus (just more of them), and needs to store them somewher | |
| 09:04:55 | aspiers | "Anything" meaning what though? BIOS settings? anything else? | |
| 09:05:10 | kashyap | So, if a user customizes something, it goes into the "VARS" file | |
| 09:06:00 | kashyap | aspiers: One of the things it stores is the UEFI keys | |
| 09:07:45 | kashyap | aspiers: Yeah, the bug is reinitializing a VARS from the default template, which is is undesirable. | |
| 09:08:51 | aspiers | right | |
| 09:09:00 | aspiers | so e.g. SB would have to be disabled every boot | |
| 09:09:19 | aspiers | there should really also be some way to change the default template | |
| 09:09:23 | aspiers | even per image | |
| 09:10:10 | kashyap | aspiers: In what else way do you want to "change the default (VARS) template"? | |
| 09:10:34 | aspiers | e.g. disabling SB | |
| 09:10:45 | aspiers | or any other BIOS tweak you can imagine | |
| 09:11:46 | kashyap | You don't want to mess with the default template itself, but rather do what libvirt does -- copy it per guest, in the "domain private path", and _then_ do what you want | |
| 09:12:06 | kashyap | aspiers: If you _don't_ want SB, then simply use the un-enrolled VARS file. | |
| 09:12:14 | aspiers | How? | |
| 09:12:28 | aspiers | I guess I didn't explain the use case clearly enough | |
| 09:12:38 | aspiers | Let's say I want to boot 100 VMs with SB, and another 100 without SB | |
| 09:12:41 | aspiers | How do I do that? | |
| 09:12:59 | kashyap | This way: | |
| 09:13:48 | kashyap | - For the 100 VMs with SB: When booting the guest, use the OVMF the binary that is built with SB/SMM (i.e. suse-code.bin) | |
| 09:14:24 | kashyap | - For the 100 VMs with SB: When booting the guest, use the OVMF the binary that is *not* with SB/SMM (i.e. suse.bin -- or whatever it's called) | |
| 09:14:30 | aspiers | But as an unprivileged non-admin how do I choose which OVMF binary gets used? | |
| 09:15:07 | kashyap | (Both the above is for UEFI boot, though.) | |
| 09:15:12 | kashyap | aspiers: So for a non-admin uesr: | |
| 09:15:36 | kashyap | You simply _don't_ set the 'uefi' image property | |
| 09:15:52 | aspiers | No, because then SEV breaks | |
| 09:16:13 | kashyap | Ah! We're talking in SEV context | |
| 09:16:17 | aspiers | Of course :) | |
| 09:16:24 | aspiers | Well, just as an example | |
| 09:16:28 | kashyap | Forgot the world spins around SEV for a sec :D | |
| 09:16:39 | aspiers | It's one example of a more general issue | |
| 09:16:58 | aspiers | What if I want to boot 100 VMs with some UEFI option tweaked and 100 with it not tweaked? It's not always going to be the case that there's a binary offering exactly what I want; there should be an option to create custom VARS templates, and to choose which VARS template to start from | |
| 09:17:04 | kashyap | aspiers: Now the question is: why would you want SEV *without* SB? | |
| 09:17:24 | aspiers | Well I already gave yesterday's example: testing new unsigned kernels | |
| 09:17:48 | aspiers | but please don't get hung up on the SEV part, that's just one example | |
| 09:18:00 | kashyap | Sure, sure. | |
| 09:18:17 | aspiers | It seems entirely reasonable to assume that at some point hardly anyone will want to boot non-UEFI | |
| 09:18:35 | kashyap | aspiers: For enrolling your own VARS files, the process is not "simple" :-( | |
| 09:18:48 | aspiers | and even though maybe most people will want SB and other default UEFI options most of the time, I'm sure they will want non-defaults at other times | |
| 09:19:09 | kashyap | E.g. to enroll _default_ UEFI (MS) keys (which most distros ship now), we wrote this tool: https://github.com/puiterwijk/qemu-ovmf-secureboot | |
| 09:19:13 | aspiers | and at those other times, it will *not* be acceptable to manually go into the console of every single VM at boot-time and press Escape and manually customise things | |
| 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 | |