From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05DC7158A12; Sat, 7 Sep 2024 11:31:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725708707; cv=none; b=FGCpBAbqCHsXKDvg+/inojaNTm8ziFtR2RF9PEIs7EdaeCp5Q0ws5CYUm7R6G5ftWpTd3nLERrR2H9JAB5dv51LyM99xkJ+FzuPX7u2jW8Mjn5TR0Rq3/RWL6wr6VaLu4iicXqmpyOiHsJZMVnMBU8hRLWVCJCs4OLXnemhiqXU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725708707; c=relaxed/simple; bh=efk1JOla+fXnaGRV8mAv/M39xrggt3sD41Iy3FnCrpk=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=k3uYPRtGS09rJYKqN+HKC4jLuAXHluNiR+88LSbZ2WurojblFcIAwcUwIllooQYl3Ux8UySb9Bs5OzLLlhYHACzPCOcZDZxtYXsGS4lQl0nXgiM6RLXR+CiqCkCKAJLxINjC2PDEL7aZoNf7hXGZvnCrLnexfgNCoWZZfW7UKl8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Sv4JhscT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Sv4JhscT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02483C4CEC2; Sat, 7 Sep 2024 11:31:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725708706; bh=efk1JOla+fXnaGRV8mAv/M39xrggt3sD41Iy3FnCrpk=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=Sv4JhscTcVihP0i6jCXpUm2sov6FUqr1PCfWWuw6lRkZpIw9wxglUmH/2GaXtKYZF ydqPWeeIKO8qxVNmO8yS42UggxhewJnGioNkZtbe74GkSeqnylctbvllZPdVCQlJqH 8Ilqcr23mP8Zb0irRhg8SoMcwszBhLam2zileDI8ukpXuiK1CofNP58jAzfYQqSRCt yMBOIlOw6NcvuLd6owhTqXgkTUiEMnoCBCCClpOin3ZJbpFP6LKwYRqgyjNrOzfiOB YDAGy50fLKeeMFQYJ0+rKDEqwrZTTmMrLUeUxDpYXSMN5LaNZX2lT9R1Gxwfwjr1b+ YKTLFtbr4oQTQ== Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 07 Sep 2024 14:31:42 +0300 Message-Id: Cc: "Pingfan Liu" , "Jan Hendrik Farr" , "Lennart Poettering" , "Eric Biederman" , "Baoquan He" , "Dave Young" , "Mark Rutland" , "Will Deacon" , "Catalin Marinas" , , , Subject: Re: [RFCv2 0/9] UEFI emulator for kexec From: "Jarkko Sakkinen" To: "Jarkko Sakkinen" , "Philipp Rudo" , "Ard Biesheuvel" X-Mailer: aerc 0.18.2 References: <20240819145417.23367-1-piliu@redhat.com> <20240906125438.1e54c5f6@rotkaeppchen> In-Reply-To: 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. BR, Jarkko