Repository navigation
Allow adding custom certificates to the OVMF DB #2627
Description
Is there an existing issue for this?
- There is no existing issue for this feature
What are you currently unable to do
Importing certificates to the SecureBoot DB is a bit tedious, as one has to go through the OVMF UI and manually browse filesystems to find and import certificates.
What do you think would need to be added
It would be nice to have additional keys, security.secureboot.db and security.secureboot.dbx, that take a list of certificates to add to the DB and DBX.
The feature would need to rework the NVRAM initialization, although I’m not yet 100% sure of all the implications (and I’m not sure of the available Go tooling for that).
Activity
stgraber commentedon Nov 7, 2025
If you can somehow implement it, it'd definitely be nice to have it but last I checked, the NVRAM format wasn't exactly the most trivial thing to interact with from Go :)
bensmrs commentedon Nov 7, 2025
Well at least I can try, you can assign me to it; I may have some time for that in the coming weeks.
stgraber commentedon Nov 7, 2025
I seem to remember $someone having a rough implementation of the NVRAM structures in python. No idea how good those were and if they actually work in all situations given EDK2 has various version of the NVRAM (2MB and 4MB if my memory serves).
stgraber commentedon Nov 7, 2025
https://github.com/awslabs/python-uefivars is what I had in mind
bensmrs commentedon Nov 7, 2025
Ah, we’re allowing 2M images in Incus?
stgraber commentedon Nov 7, 2025
We're trying to avoid them like the plague but we don't always control what a distro may be shipping :)
bensmrs commentedon Nov 7, 2025
Rethinking about it, also adding keys to edit the NVRAM in order to set EFI variables would be great (admittedly, for very niche use cases). If I’m writing an EDK2 NVRAM parser, I might as well exploit it at its full potential. EFI vars have a hierarchical structure (owner GUID or familiar name that translates to its GUID, then variable name) and I’m not completely sure how it should be encoded in Incus configuration format. Would something along the lines of:
or its equivalent:
be good?
stgraber commentedon Nov 7, 2025
Given we should be in control of what key namespace is supported (as we're not on hardware with vendor specific extensions), the latter should be fine, though I'd probably want it to be EFI rather than Efi ;)
I also don't know what's best between individual
nvram.XYZconfig keys VS araw.efi_nvramtype approach. The individual keys would come with the expectation that individual key changes would be applied without messing up the rest whereas theraw.XYZapproach would be more compatible with us just applying the whole thing again.bensmrs commentedon Jul 2, 2026
So, planning to start on that one. Thinking again about it, setting UEFI vars in the config is a way to do it, but it can be quite costly at each boot to re-apply them all. I think some users (me included) may also be interested in one-shot commands to get (offline and I guess online could be doable) and set (offline) variables, and even dissect and edit ESL blocks. I was thinking about an
incus nvramorincus config nvramcommand, but am happy to change its name.Anyway, I’m currently having a look on the OVMF VARS format.
stgraber commentedon Jul 2, 2026
We have an instance action/debug API these days for one time actions, so that may be an option?
bensmrs commentedon Jul 2, 2026
Are you suggesting that people should not be encouraged to edit the NVRAM themselves, thus making us hide the goodies behind
incus debug? :)Fine by me, but semantically, I’d interpret a
debugcommand to give me an info/get some value somewhere, not set a value. That’s one thing for raw EFI vars, but importing a db key feels like a more common interaction to me. Putting it behindincus debug nvram import-xxxdoesn’t seem ok.Should I rather split
incus debug nvramfor pure efivars interaction, andincus config securebootfor signature list operations?bensmrs commentedon Jul 3, 2026
I’m a bit concerned by the fact that the VM config needs to be mounted; is there already a place (except for
incus init) where we do offline operations on VM config?stgraber commentedon Jul 3, 2026
We should have a bunch of cases that trigger a refresh of backup.yaml in that config drive. I'd expect all offline config changes as well as changes to profiles to do that.
stgraber commentedon Jul 3, 2026
To be honest I'm liking the name
incus debugless and less given the options we've got in there :)We currently have:
Both of those have dedicated API endpoints.
Then we have the
repairmultiplexer withrebuild-config-volumebeing the only supported action on that. That's not exposed to the CLI.For NVRAM, I'm not really sure what the best path forward is as I think we want:
The last one is the tricky one as if we want to also have it in profiles, then that gets pretty tricky on how to handle applying changes only where they need to and leaving the rest alone.
If we skip the profile stuff, then we'd likely be looking at a
/1.0/instances/NAME/nvramendpoint, analogous to what we've done recently fornbdandbitmaps.Thinking myself through this one, I think the way we could address all of the above (minus profiles) is:
incus debugtoincus advanced(keepdebugas an alias)bitmapssub-command toincus advanced(API coverage)repairsub-command toincus advanced(API coverage)nvramsub-comamnd toincus advancedI think that should fix a bunch of the weirdness around
incus debug, actually expose all those more advanced endpoints in the CLI and give us a good place to put the NVRAM mangling stuff.@bensmrs how does that sound?
bensmrs commentedon Jul 3, 2026
Sounds better indeed ;)
Although, I dunno about you but “advanced” feels a tad pedantic to me… I’d prefer “internal” or “internals”, which convey the meaning that we want, minus the “I’m a big brain advanced user”. But I may be overthinking it :)
stgraber commentedon Jul 3, 2026
incus i-know-what-i-am-doingorincus i-wont-complain-if-i-break-something;)I think I'd avoid
internalbecause we have an actual internal API (/internal/XYZ) and that could make things a bit confusing.stgraber commentedon Jul 3, 2026
incus low-levelcould work but I don't love the hyphen in a top-level command.irhndt commentedon Jul 3, 2026
Hi, coming out of the blue but what do you think of :
incus inspect?stgraber commentedon Jul 3, 2026
incus inspectdoesn't really fit withnbd,nvram,bitmapsorrepair, all of which cause changes to the instance.inspectsuggests more of a read-only type of thing which is part of the issue with the currentdebugname.bensmrs commentedon Jul 7, 2026
incus quirksbensmrs commentedon Jul 29, 2026
Deferring to 7.4 as 7.3 will only ship the NVRAM primitives which turned out to require way more care than I expected. 7.4 will ship helpers to manipulate ESLs and properly handle authenticated variables.