Re: [RFCv2 0/9] UEFI emulator for kexec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon Sep 9, 2024 at 4:55 PM EEST, Philipp Rudo wrote:
> Hi Jarkko,
>
> On Sat, 07 Sep 2024 14:41:38 +0300
> "Jarkko Sakkinen" <jarkko@xxxxxxxxxx> wrote:
>
> > On Sat Sep 7, 2024 at 2:31 PM EEST, Jarkko Sakkinen wrote:
> > > On Sat Sep 7, 2024 at 2:27 PM EEST, Jarkko Sakkinen wrote:  
> > > > On Fri Sep 6, 2024 at 1:54 PM EEST, Philipp Rudo wrote:  
> > > > > Let me throw an other wild idea in the ring. Instead of implementing
> > > > > a EFI runtime we could also include a eBPF version of the stub into the
> > > > > images. kexec could then extract the eBPF program and let it run just
> > > > > like any other eBPF program with all the pros (and cons) that come with
> > > > > it. That won't be as generic as the EFI runtime, e.g. you couldn't
> > > > > simply kexec any OS installer. On the other hand it would make it
> > > > > easier to port UKIs et al. to non-EFI systems. What do you think?  
> > > >
> > > > BPF would have some guarantees that are favorable such as programs
> > > > always end, even faulty ones. It always has implicit "ExitBootServices".
> > > >
> > > > Just a remark.  
> > >
> > > Some days ago I was thinking could some of the kernel functionality be
> > > eBPF at least like in formal theory because most of it is amortized,
> > > i.e. does a fixed chunk of work. Not going into that rabbit hole but
> > > I really like this idea and could be good experimentation ground for
> > > such innovation.  
> > 
> > E.g. let's imagine there would imaginary eBPF-TPM driver framework.
> > 
> > How I would go doing that would be to take the existing TPM driver
> > functionality and provide extra functions and resources available for
> > subsystem specific BPF environment, and have the orhestration code as
> > eBPF. I pretty much concluded that there is a chance that such could
> > work out.
> > 
> > Not something in my immediate table but it is still really interesting
> > idea, as instead of using language to separate "safe" and unsafe"
> > regions you would use "VM" environments to create the walls. In the
> > end of the day that would also great venture for Rust in kernel, i.e.
> > compile that BPF from Rust.
> > 
> > Sorry going of the hook the comment triggered me ;-)
>
> I'm glad you like the idea :-)
>
> Sounds like an interesting idea you are having there!

Yeah, if you go forward with this please CC to me any possible
follow-ups :-)

BR, Jarkko





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux