On Fri, 13 Aug 2021 at 15:12, Leif Lindholm <l...@nuviainc.com> wrote:
> 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. > > Isn't it the verifier's job to scan for bad code ? To some extent, I consider that eBPF code is running sand boxed because of this verifier thing. I believe this verifier was the technology which allowed eBPF to make its way in the Linux kernel, and now in Windows kernel. > / > Leif > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
