| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-05 | |||
| 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 | |
| 09:57:07 | aspiers | I managed to get into mokmanager that way | |
| 09:57:10 | aspiers | or whatever it's called | |
| 09:57:20 | puiterwijk | Oh | |
| 09:57:21 | puiterwijk | "fwsetup" | |
| 09:57:26 | puiterwijk | that's the grub command | |
| 09:57:37 | puiterwijk | } | |
| 09:57:37 | puiterwijk | fwsetup | |
| 09:57:37 | puiterwijk | menuentry 'System setup' $menuentry_id_option 'uefi-firmware' { | |
| 09:57:46 | stephenfin | melwitt: Heh, sorry. That auto-topic thing was killing me downstream and like mriedem I always do 'git checkout -b bug/NNN' (or 'bp/foo') manually first. Also, it was broken with storyboard | |
| 09:58:12 | aspiers | IRC is awesome for apparent non-sequiturs | |
| 09:58:13 | stephenfin | melwitt: mordred reviewed it though so if you _really_ want to blame someone, I suggest blaming him. Everyone else does it :P | |
| 09:58:24 | aspiers | morning stephenfin | |
| 09:58:26 | aspiers | ;-p | |
| 09:58:31 | stephenfin | yo | |
| 09:58:44 | aspiers | puiterwijk: fwsetup is accepted but does nothing | |
| 09:59:18 | kashyap | aspiers: So you got into Grub command-line... | |
| 09:59:41 | stephenfin | I can see four new towers going up just from our window | |
| 09:59:53 | aspiers | kashyap: yes | |
| 09:59:58 | aspiers | stephenfin: try London for a bit | |
| 10:00:21 | stephenfin | once that legislation is passed, sure :) | |
| 10:00:23 | aspiers | I get "error: you need to load the kernel first." | |
| 10:00:48 | stephenfin | til then, I'll stay where food supplies aren't a concern | |