kexec.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Philipp Rudo <prudo@redhat.com>
To: "Jan Hendrik Farr" <kernel@jfarr.cc>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	x86@kernel.org, tglx@linutronix.de, dhowells@redhat.com,
	vgoyal@redhat.com, keyrings@vger.kernel.org,
	akpm@linux-foundation.org, "Baoquan He" <bhe@redhat.com>,
	bhelgaas@google.com, "Luca Boccassi" <bluca@debian.org>,
	lennart@poettering.net
Subject: Re: [PATCH v2 0/2] x86/kexec: UKI Support
Date: Thu, 14 Sep 2023 21:09:46 +0200	[thread overview]
Message-ID: <20230914210946.25730571@rotkaeppchen> (raw)
In-Reply-To: <63952cb0-5217-42a8-9b62-8be6d03f5844@app.fastmail.com>

Hi Jan,

On Wed, 13 Sep 2023 16:42:33 +0200
"Jan Hendrik Farr" <kernel@jfarr.cc> wrote:

> On Wed, Sep 13, 2023, at 4:00 PM, Philipp Rudo wrote:

[...]

> In [5] Luca writes:
> > [...] we fully intend for the UKI format to be an open and stable
> > specification, that anybody can support and rely on.  
> But that is unfortunately not where the format is at this point.
> 
> What is annoying though is where this leaves a user that actually
> wants this feature. They can carry a patch or they might have to wait
> a long time.
> 
> Can you indicate what it would take for the kernel community to consider
> this spec as stable enough?

I don't think there is a good answer to that question. In fact I
believe if you ask 10 people from the community you will get 20+
different answers.

My guess is that either (1) the spec is moved to some official standard
committee where people spend decades to polish it before it makes it
into the kernel or (2) there's a big flamewar on LKML until Linus had
enough and passes his judgment on it. So definitely (2) ;-)

Thanks
Philipp

> 
> 
> > In the end the only benefit this series brings is to extend the
> > signature checking on the whole UKI except of just the kernel image.
> > Everything else can also be done in user space. Compared to the
> > problems described above this is a very small gain for me.  
> 
> Correct. That is the benefit of pulling the UKI apart in the
> kernel. However having to sign the kernel inside the UKI defeats
> the whole point.
> 
> 
> [1] https://uapi-group.org/specifications/specs/unified_kernel_image/
> [2] https://github.com/uapi-group/specifications/pull/72
> [3] https://github.com/uapi-group/specifications/pull/73
> [4] https://github.com/uapi-group/specifications/issues/74
> [5] https://github.com/systemd/systemd/issues/28538
> 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2023-09-14 19:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-11  5:25 [PATCH v2 0/2] x86/kexec: UKI Support Jan Hendrik Farr
2023-09-11  5:25 ` [PATCH v2 1/2] move pefile_parse_binary to its own file Jan Hendrik Farr
2023-09-11  5:25 ` [PATCH v2 2/2] x86/kexec: UKI support Jan Hendrik Farr
2023-09-12  1:03 ` [PATCH v2 0/2] x86/kexec: UKI Support Baoquan He
2023-09-12 19:25   ` Jan Hendrik Farr
2023-09-13 14:00 ` Philipp Rudo
2023-09-13 14:42   ` Jan Hendrik Farr
2023-09-14 19:09     ` Philipp Rudo [this message]
2023-09-20  7:43     ` Dave Young
2023-09-20  8:40       ` Dave Young
2023-09-20 10:50         ` Ard Biesheuvel
2023-09-20 12:07           ` Dave Young
2023-09-20 12:18             ` Dave Young
2023-09-21  3:14               ` Dave Young
2023-09-20 22:02           ` Jan Hendrik Farr
2023-09-25 14:36             ` Philipp Rudo
2023-09-14  9:32   ` Lennart Poettering
2023-09-14 12:26     ` Jarkko Sakkinen
2023-09-14 15:33       ` Jarkko Sakkinen
2023-09-14 16:11         ` Jan Hendrik Farr
2023-09-14 21:14           ` Jarkko Sakkinen
2023-09-14 18:51     ` Philipp Rudo
2023-09-14 21:04       ` Jan Hendrik Farr
2023-09-18 15:36         ` Philipp Rudo

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=20230914210946.25730571@rotkaeppchen \
    --to=prudo@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=bluca@debian.org \
    --cc=dhowells@redhat.com \
    --cc=kernel@jfarr.cc \
    --cc=kexec@lists.infradead.org \
    --cc=keyrings@vger.kernel.org \
    --cc=lennart@poettering.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vgoyal@redhat.com \
    --cc=x86@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;
as well as URLs for NNTP newsgroup(s).