On Fri, Aug 13, 2021 at 14:14:27 +0200, Alexander Graf wrote:
There are a few reasons you may want to use eBPF:
- Security
- Cross-arch compatibility
I don't think you can get either in UEFI's current module model, because you exchange direct flat memory model objects between entities. So while struct layouts, function call ABI, etc still matter you still don't get any additional security because you need to have full access to all memory at all times.
So let me ask this the other way around: What are you trying to achieve?
Portable option ROMs with a supportable toolchain.
As long as your host ABI is compatible to eBPF, it will also be compatible to x86_64, no? That means, you can just as well use x86_64 instead.
But require an x86_64 toolchain I would have no other use for.
What I'm much more interested in is a path where we move out of the 1980
(An interesting sentence to follow onto why x86_64 is the ideal solution for a portable instruction set.)
misery of flat address spaces and no privilege separation between entities. How hard would it be to create wasm bindings for the 99% of use cases that Option ROMs have these days?
That is an interesting idea. I'm certainly not wedded to the idea of eBPF, only to the idea of not needing to keep arbitrary legacy toolchains around.
Certainly if we're adding a whole new binary format, and a new virtual machine, to the specification, we can add restrictions on what operations can be performed within that virtual machine.
Could we create a shim layer between the big UEFI blob and Option ROMs that would make it impossible to access stray pointers for example?
That could be addressed at the same point, yes.
/ Leif