(+ Peter) On Fri, 10 Apr 2020 at 19:54, Ignat Korchagin <ignat@xxxxxxxxxxxxxx> wrote: > > On Fri, Apr 10, 2020 at 6:38 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > Hello Ignat, > > > > Thanks for the patch. > > > > On Fri, 10 Apr 2020 at 19:28, Ignat Korchagin <ignat@xxxxxxxxxxxxxx> wrote: > > > > > > Currently Linux exposes the physical address of the EFI configuration table via > > > sysfs, but not the number of entries. > > > > > > > It does so on x86 only, and the purpose is specifically defined as > > kexec. This is for a good reason: kexec on x86 EFI machines has > > accumulated some historical quirks dealing with issues that do not > > exist on other architectures. > > > > > The number of entries for the EFI configuration table is located in the EFI > > > system table and the EFI system table is not exposed, so there is no way for > > > a userspace application to reliably navigate the EFI configuration table. > > > > > > One potential use case for such a userspace program would be a monitoring agent, > > > which parses Image Execution Information Table from the EFI configuration table > > > and reports all the UEFI executables, which have been denied execution due to > > > the enforced Secure Boot policy thus providing intrusion detection capabilities. > > > > > > > Exposing a physical address via syfs and using /dev/mem to scoop up > > the data is not a robust, secure or portable interface, especially in > > the quoted context of a UEFI secure boot enabled system. > > TBH, it is not hard to find this number by scanning the same mapped region for > EFI system table (which is easily identifiable by its signature). So > security is not an > issue here, although robustness and portability indeed. > > > If you need to access this table from userland, I suggest we come up > > with a generic method that does not rely on /dev/mem. It would be even > > better if we could come up with some infrastructure that makes this > > easily extendable to other configuration tables. But simply exposing > > the address and size of the config table array in memory is not the > > right way. > > Would you prefer something closer to the efivars filesystem then? > The problem with EFI configuration tables is that there is no standard way to discover their size. Each GUID denotes a different type of table, each of which has its own structure and layout in memory. We already record and expose a substantial set of config tables, but perhaps it is time to add a generic layer as well. I have cc'ed Peter, which may have some observations of his own to share on this topic. A pseudo file system might work, as long as it only exposes tables that have been explicitly registered for this, along with the size of each individual table. But then it becomes complicated if you want to expose things like ACPI or SMBIOS, which are not flat tables, but sets of tables pointing to other tables etc etc.
