This:
https://linuxfoundation.org/press-release/facebook-google-isovalent-microsof...
Following earlier addition of eBPF in Windows kernel: https://github.com/microsoft/ebpf-for-windows
Makes me think that the crazy idea I talked about a couple of months ago (subject of the mail) may not be that crazy….
Cheers
FF
On Fri, Aug 13, 2021 at 08:18:14 +0200, François Ozog wrote:
This:
https://linuxfoundation.org/press-release/facebook-google-isovalent-microsof...
Following earlier addition of eBPF in Windows kernel: https://github.com/microsoft/ebpf-for-windows
Makes me think that the crazy idea I talked about a couple of months ago (subject of the mail) may not be that crazy….
Not crazy. I have discussed at least the EBC replacement bit with a few people in the past.
While admittedly the first time it was broached was in jest (I think credit goes to Peter Jones), it's the best option I can see out there today.
/ Leif
On 13.08.21 11:54, Leif Lindholm wrote:
On Fri, Aug 13, 2021 at 08:18:14 +0200, François Ozog wrote:
This:
https://linuxfoundation.org/press-release/facebook-google-isovalent-microsof...
Following earlier addition of eBPF in Windows kernel: https://github.com/microsoft/ebpf-for-windows
Makes me think that the crazy idea I talked about a couple of months ago (subject of the mail) may not be that crazy….
Not crazy. I have discussed at least the EBC replacement bit with a few people in the past.
While admittedly the first time it was broached was in jest (I think credit goes to Peter Jones), it's the best option I can see out there today.
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?
Alex
On Fri, Aug 13, 2021 at 12:58:26 +0200, Alexander Graf wrote:
On 13.08.21 11:54, Leif Lindholm wrote:
On Fri, Aug 13, 2021 at 08:18:14 +0200, François Ozog wrote:
This:
https://linuxfoundation.org/press-release/facebook-google-isovalent-microsof...
Following earlier addition of eBPF in Windows kernel: https://github.com/microsoft/ebpf-for-windows
Makes me think that the crazy idea I talked about a couple of months ago (subject of the mail) may not be that crazy….
Not crazy. I have discussed at least the EBC replacement bit with a few people in the past.
While admittedly the first time it was broached was in jest (I think credit goes to Peter Jones), it's the best option I can see out there today.
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.
/ Leif
On 13.08.21 13:23, Leif Lindholm wrote:
On Fri, Aug 13, 2021 at 12:58:26 +0200, Alexander Graf wrote:
On 13.08.21 11:54, Leif Lindholm wrote:
On Fri, Aug 13, 2021 at 08:18:14 +0200, François Ozog wrote:
This:
https://linuxfoundation.org/press-release/facebook-google-isovalent-microsof...
Following earlier addition of eBPF in Windows kernel: https://github.com/microsoft/ebpf-for-windows
Makes me think that the crazy idea I talked about a couple of months ago (subject of the mail) may not be that crazy….
Not crazy. I have discussed at least the EBC replacement bit with a few people in the past.
While admittedly the first time it was broached was in jest (I think credit goes to Peter Jones), it's the best option I can see out there today.
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.
What I'm much more interested in is a path where we move out of the 1980 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? 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?
Thanks,
Alex
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
On Fri, 13 Aug 2021 at 15:12, Leif Lindholm leif@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:
- 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.
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
boot-architecture@lists.linaro.org
-
Alexander Graf -
François Ozog -
Leif Lindholm