Re: Adding ESRT and EFI vars support for fwupd

[Paweł Cichowski <pawel.cichowski%3mdeb.com@localhost>]

First of all, thank you for your detailed response to my previous message.

I have conducted some more research on how to extend EFI support and 
general kernel hacking. I would like to ask you some more questions, 
mainly concerning modifying the kernel, since this is my first time 
trying it.

I've built the kernel and release for evbarm aarch64 from the latest 
sources and ran it on QEMU. Unfortunately, /dev/efi wasn't present on 
the system. Is it linked to the issue you talked about (no conversion 
between EFI device paths and disks)? How should I approach implementing 
it? Or is making a device node manually using mknod the case (I thought 
MAKEDEV.tmpl should've added it automatically)?

Additionally, what ways to debug kernel drivers would you recommend? 
`printk` or `aprint_debug`?

I would also like to know your opinion on the following implementation. 
My general plan is to extend on the work you've done on EFI rt and 
/dev/efi and use the existing code as a guideline, while implementing 
features from FreeBSD 
(https://reviews.freebsd.org/rGd12d651f8692cfcaf6fd0a6e8264c29547f644c9)

- get table - returns table address by uuid (efi_ops)
- copy table - copies the table from memory to a variable passed by 
reference (efi_ops)
- get table size - helper function, returns size of table in bytes
- other operations on efi vars are a second priority, since the main 
task is to support ESRT

I reckon these not only need to be added to /dev/efi, but efi_runtime 
too (so they become machine dependent). If you have a different view or 
any other ideas to extend the implementation please let me know.

Apologies for an exhaustive list of questions and have a great day,
Paweł


On 17.08.2022 18:17, Jared McNeill wrote:
> Hi Paweł --
>
> After introducing /dev/efi I ported libefi and efivar from FreeBSD, at 
> least enough to work with EFI vars, but there were some things left to 
> do -- notably, all of the logic to convert between EFI device paths and 
> disks needs to be sorted out. No geom on NetBSD, and the current state 
> of things is a bit of a mess IMHO, so I didn't get around to tackling it.
>
> I think extending /dev/efi to support this feature is reasonable, and it 
> makes sense to keep compatibility with the FreeBSD APIs here.
>
> We have other platforms that use EFI today (armv7 and aarch64), with 
> more in the pipeline (riscv) so whatever solution you come up with 
> should be MI. So sys/dev/efi.c makes sense, probably with a new MD hook 
> added to struct efi_ops.
>
> I realize that this doesn't cover x86 today -- as far as I'm aware, the 
> x86 based NetBSD ports don't support UEFI runtime services at all. But 
> when they do, this is how support will be added.
>
> Hope this helps, and feel free to reach out if you have any follow up 
> questions.
>
> Take care,
> Jared