Hello Mark, Thanks for the patch. I've rebased my changes on top of it, then went ahead and implemented FreeBSD-like API for variables and ESRT [1]. Lack of kernel API was blocking user-space development and I'll rather just rebase later again than wait. Feel free to use the code to not duplicate the work.
[1]: https://github.com/3mdeb/openbsd-src/compare/esrt...3mdeb:openbsd-src:efivars-api There is also a port of rhboot/efivar [2], which can be used if kernel patch is applied. Might be helpful for testing EFI RT. [2]: https://github.com/3mdeb/ports/commit/522a394fb4acfe7c4f4cdbe6bd4f59d235fdcf68 Will submit patches and then port properly after initial support lands in the kernel. Cheers, Sergii Oe Wed, Sep 14, 2022 at 10:15:51AM +0200, Mark Kettenis wrote: > Hi Sergii, > > Sorry, not much. I've been a bit busy; some evil person put a lenovo > x13s on my desk ;). > > I dug out the patch I was working on. The goal of that patch was to > support rebooting machines using EFI runtime services, which makes the > Microsoft Surface Go 3 reboot correctly. Unfortunately this breaks > other machines, which is why I parked the diff. > > The diff is basically a port of the arm64 code, and I want to make an > effort to keep things in sync. My plan is to get this bit in soon > after OpenBSD 7.2 is released. That'll be a few weeks from now. I > may use some of the time in between to make this a bit more robust > such that if we crash during an EFI runtime services call, the kernel > can recover. This diff doesn't create dev/efi yet, but that will > follow soon after. > > I did discuss the approach with Theo and some other OpenBSD developers > really. I think this is very useful functionality, but there are some > concerns about making it too easy to set EFI variables from within > OpenBSD as this can have serious security implications. Traditionally > we only allow this kind of thing when securelevel is -1 or 0. See > https://man.openbsd.org/securelevel.7 for more information about > securelevel. That would mean you can only run fwupd from single-user > mode. > > Cheers, and thank you for your patience, > > Mark
