On Fri, Aug 13, 2021 at 14:14:27 +0200, Alexander Graf wrote:
> > > There are a few reasons you may want to use eBPF:
> > >
> > > 1) Security
> > > 2) 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
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
