| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-05 | |||
| 08:44:09 | kashyap | aspiers: But my educated guess is that, these two are the recommended ones for Secure Boot: | |
| 08:44:12 | kashyap | /usr/share/qemu/ovmf-x86_64-ms-4m-code.bin | |
| 08:44:14 | kashyap | /usr/share/qemu/ovmf-x86_64-ms-4m-vars.bin | |
| 08:44:27 | kashyap | (The above are from OpenSUSE. Hopefully they're similarly named on SLES.) | |
| 08:45:20 | kashyap | aspiers: In short, for SB, you want the 'ms'-variant '-code.bin' (and its corresponding '-vars.bin') | |
| 08:46:26 | aspiers | kashyap: it's not 35, you're counting text files and directories in that | |
| 08:46:38 | aspiers | kashyap: but still agree that it's way too many | |
| 08:46:51 | kashyap | aspiers: Yeah, sorry, exaggerated; do rake me on coals | |
| 08:46:54 | aspiers | XD | |
| 08:47:20 | aspiers | It's the same on SLES | |
| 08:52:45 | dr_gogeta86 | good morning | |
| 08:52:58 | dr_gogeta86 | any hitachi guys here ? | |
| 08:58:03 | kashyap | aspiers: Okay, then. Do you have the recorded notes from your previous successful Secure Boot? | |
| 08:58:21 | kashyap | aspiers: If so, I'd bet they are the ms-variant binaries. | |
| 08:58:50 | aspiers | kashyap: No it was -suse-code | |
| 08:59:55 | kashyap | aspiers: Ah, okay. So they are the MS-enrolled ones for SLES | |
| 09:00:11 | aspiers | kashyap: But the problem is I'm trying to boot an unreleased test kernel | |
| 09:00:18 | aspiers | so it doesn't have the official signature | |
| 09:01:00 | kashyap | Nod; for this unrelease kernel, either you just go into the Tianocore BIOS and disable SB | |
| 09:01:20 | aspiers | kashyap: https://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernel has been suggested | |
| 09:01:53 | kashyap | Yep, those are the steps the Secure Boot / BIOS dev I know recommended too | |
| 09:02:05 | kashyap | You have to do a lot of manual muckery, generate certs, run 'mokutil', etc | |
| 09:03:12 | aspiers | kashyap: do BIOS definitions get persisted to the VARS file? is that what https://review.opendev.org/#/c/621646/ is about? | |
| 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. | |