public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Jarkko Sakkinen" <jarkko@kernel.org>,
	"Philipp Rudo" <prudo@redhat.com>,
	"Ard Biesheuvel" <ardb@kernel.org>
Cc: "Pingfan Liu" <piliu@redhat.com>,
	"Jan Hendrik Farr" <kernel@jfarr.cc>,
	"Lennart Poettering" <mzxreary@0pointer.de>,
	"Eric Biederman" <ebiederm@xmission.com>,
	"Baoquan He" <bhe@redhat.com>, "Dave Young" <dyoung@redhat.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	<kexec@lists.infradead.org>, <linux-efi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [RFCv2 0/9] UEFI emulator for kexec
Date: Sat, 07 Sep 2024 14:41:38 +0300	[thread overview]
Message-ID: <D400W37FR01S.CLFIKA98YWX7@kernel.org> (raw)
In-Reply-To: <D400OHF2ODNK.3JF7DJ87Q4BYI@kernel.org>

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 ;-)

BR, Jarkko

  reply	other threads:[~2024-09-07 11:41 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-19 14:53 [RFCv2 0/9] UEFI emulator for kexec Pingfan Liu
2024-08-19 14:53 ` [RFCv2 1/9] efi/libstub: Ask efi_random_alloc() to skip unusable memory Pingfan Liu
2024-08-19 18:00   ` Jarkko Sakkinen
2024-08-20  0:58     ` Pingfan Liu
2024-08-28 13:28   ` Ard Biesheuvel
2024-08-19 14:53 ` [RFCv2 2/9] efi/libstub: Complete efi_simple_text_output_protocol Pingfan Liu
2024-08-19 14:53 ` [RFCv2 3/9] efi/emulator: Initial rountines to emulate EFI boot time service Pingfan Liu
2024-08-19 14:53 ` [RFCv2 4/9] efi/emulator: Turn on mmu for arm64 Pingfan Liu
2024-08-19 14:53 ` [RFCv2 5/9] kexec: Introduce kexec_pe_image to parse and load PE file Pingfan Liu
2024-08-19 14:53 ` [RFCv2 6/9] arm64: kexec: Introduce a new member param_mem to kimage_arch Pingfan Liu
2024-08-19 14:53 ` [RFCv2 7/9] arm64: mm: Change to prototype of Pingfan Liu
2024-08-19 14:53 ` [RFCv2 8/9] arm64: kexec: Prepare page table for emulator Pingfan Liu
2024-08-19 14:53 ` [RFCv2 9/9] arm64: kexec: Enable kexec_pe_image Pingfan Liu
2024-08-21 14:27 ` [RFCv2 0/9] UEFI emulator for kexec Lennart Poettering
2024-08-22  5:42   ` Pingfan Liu
2024-08-22  6:16     ` Dave Young
2024-08-22 10:51       ` Pingfan Liu
2024-08-22 11:54         ` Dave Young
2024-08-22 10:56       ` Jan Hendrik Farr
2024-08-22 12:04         ` Dave Young
2024-08-22  8:23     ` Lennart Poettering
2024-08-22 10:45       ` Pingfan Liu
2024-08-22 11:42         ` Jan Hendrik Farr
2024-08-22 11:45           ` Lennart Poettering
2024-08-22 14:29       ` Pingfan Liu
2024-08-26 13:39         ` Lennart Poettering
2024-09-09 13:38           ` Pingfan Liu
2024-09-10  7:06             ` Lennart Poettering
2024-08-28 17:08 ` Ard Biesheuvel
2024-09-02  5:40   ` Pingfan Liu
2024-09-06 10:54   ` Philipp Rudo
2024-09-07 11:27     ` Jarkko Sakkinen
2024-09-07 11:31       ` Jarkko Sakkinen
2024-09-07 11:41         ` Jarkko Sakkinen [this message]
2024-09-09 13:55           ` Philipp Rudo
2024-09-09 17:09             ` Jarkko Sakkinen
2024-09-09  9:48     ` Lennart Poettering
2024-09-09 10:42       ` Jan Hendrik Farr
2024-09-09 13:49         ` Philipp Rudo
2024-09-09 14:04           ` Ard Biesheuvel
2024-09-09 14:37             ` Jan Hendrik Farr
2024-09-10  7:54         ` Lennart Poettering
2024-10-08 11:59   ` Pingfan Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D400W37FR01S.CLFIKA98YWX7@kernel.org \
    --to=jarkko@kernel.org \
    --cc=ardb@kernel.org \
    --cc=bhe@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=kernel@jfarr.cc \
    --cc=kexec@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mzxreary@0pointer.de \
    --cc=piliu@redhat.com \
    --cc=prudo@redhat.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox