Adding ESRT and EFI vars support for fwupd

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

Hello NetBSD devs,

Background
----------

As some might know, FreeBSD gained an interface for querying ESRT about 
a year ago ([1], [2]), which was done as part of [3].

[1]: https://reviews.freebsd.org/rGd12d651f8692cfcaf6fd0a6e8264c29547f644c9
[2]: https://reviews.freebsd.org/rG24f398e7a153a05a7e94ae8dd623e2b6d28d94eb
[3]: https://nlnet.nl/project/fwdup-BSD/

Adding it allowed to make UEFI capsule plugin of fwupd [4] work for 
FreeBSD [5] to perform firmware updates on EFI systems.
Now it's turn for NetBSD and we would like to ask about requirements and 
recommendations on the API and its implementation such that they would 
be accepted by the upstream.

[4]: https://fwupd.org/
[5]: 
https://github.com/fwupd/fwupd/blob/main/plugins/uefi-capsule/fu-uefi-backend-freebsd.c

The same project is being done for OpenBSD as well [6]

[6]: https://www.mail-archive.com/tech%openbsd.org@localhost/msg70825.html

ESRT
----

The initial idea for accessing ESRT from userland is to use sysctl() 
like so:
```
void *esrt;
size_t esrt_len;
int mib[] = { CTL_HW, HW_ESRT };
esrt_len = 0;
if (sysctl(mib, 2, NULL, &esrt_len, NULL, 0) == -1 && errno != ENOMEM)
err(1, "sysctl");esrt = malloc(esrt_len);
if (esrt == NULL)
err(1, "malloc");
if (sysctl(mib, 2, esrt, &esrt_len, NULL, 0) == -1)
err(1, "sysctl");
```

However, FreeBSD decided in favour of ioctl() on /dev/efi.

The main question is - where should the implementation of ESRT tables go 
into?
Should it be generic and span multiple architectures, or should it be 
limited to for example only x86?

I found out that EFI is already handled by the x86 architecture, in 
`src/sys/arch/x86/x86/efi.c`. So, the implementation would probably go 
there or a new file in the same location, if the decision was to reduce 
the scope of this feature to a single arch.

EFI variables
-------------

I don't see an implementation of `efivar` or `efiboot` or anything 
similar, so it needs to be added and provide at least this API subset to 
be usable with fwupd:
* efi_append_variable() appends data of size to the variable specified 
by guid and name
* efi_del_variable() deletes the variable specified by guid and name
* efi_get_variable() gets variable's data_size, and its attributes are 
stored in attributes
* efi_get_variable_attributes() gets attributes for the variable 
specified by guid and name
* efi_get_variable_size() gets the size of the data for the variable 
specified by guid and name
* efi_get_next_variable_name() iterates across the currently extant 
variables, passing back a guid and name
* efi_guid_to_name() translates from an efi_guid_t to a well known name
* efi_guid_to_symbol() translates from an efi_guid_t to a unique (within 
libefivar) C-style symbol name
* efi_guid_to_str() allocates a suitable string and populates it with 
string representation of a UEFI GUID
* efi_name_to_guid() translates from a well known name to an efi_guid_t
* efi_set_variable() sets the variable specified by guid and name
* efi_str_to_guid() parses a UEFI GUID from string form to an efi_guid_t
* efi_variables_supported() checks if EFI variables are accessible
* efi_generate_file_device_path() generates an EFI file device path for 
an EFI binary from a filesystem path

Probably should be implemented as a minimal port of efivar [7] with 
sufficient functionality rather than a separate project. Either way, 
this too needs new kernel API for accessing EFI variables. Will sysctl() 
do or a new pseudo-device or is something else needed? Usage of existing 
implementations can be seen in FreeBSD [8] and Linux [9] (Linux uses 
sysfs for this). I also saw an implementation of a pseudo-driver which 
allows operations on EFI variables [10], which would suffice as an API, 
but unfortunately it wasn't merged yet. Could it be used in our case?

[7]: https://github.com/rhboot/efivar
[8]: 
https://github.com/freebsd/freebsd-src/blob/release/12.2.0/lib/libefivar/efivar.c
[9]: https://github.com/rhboot/efivar/blob/main/src/efivarfs.c
[10]: 
https://github.com/NetBSD/src/commit/25ff60a647236a2f67fc08ecac96a14fecffd6f1

Expectations
------------

Please help us shape this API, so the community can be happy with it :)
The implementation is a separate topic, but please let me know if you 
have any specific ideas about it right away, so as to help avoid any 
unnecessary rounds of reviews.

Kind regards,
Pawel