linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gao Xiang <xiang@kernel.org>
To: Askar Safin <safinaskar@zohomail.com>
Cc: "Gao Xiang" <hsiangkao@linux.alibaba.com>,
	"Byron Stanoszek" <gandalf@winds.org>,
	"Christoph Hellwig" <hch@lst.de>,
	gregkh <gregkh@linuxfoundation.org>,
	"julian.stecklina" <julian.stecklina@cyberus-technology.de>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	rafael <rafael@kernel.org>,
	torvalds <torvalds@linux-foundation.org>,
	viro <viro@zeniv.linux.org.uk>,
	"\"Thomas Weißschuh\"" <thomas.weissschuh@linutronix.de>,
	"Christian Brauner" <brauner@kernel.org>,
	systemd-devel <systemd-devel@lists.freedesktop.org>,
	"Lennart Poettering" <mzxreary@0pointer.de>
Subject: Re: [PATCH] initrd: support erofs as initrd
Date: Sat, 30 Aug 2025 20:23:01 +0800	[thread overview]
Message-ID: <aLLtJcHt0NcaZeDm@debian> (raw)
In-Reply-To: <198facfefe8.11982931078232.326054837204882979@zohomail.com>

On Sat, Aug 30, 2025 at 03:49:48PM +0400, Askar Safin wrote:
>  ---- On Thu, 28 Aug 2025 21:14:34 +0400  Gao Xiang <hsiangkao@linux.alibaba.com> wrote --- 
>  > Which part of the running system check the cpio signature.
> 
> You mean who checks cpio signature at boot?
> Ideally, bootloader should do this.

The kernel shouldn't trust the bootloader even the bootloader
checked before, it should re-check itself to re-ensure that.

Ideally, the running system should have a way to check itself
is in a safe environment and the data provided by the bootloader
is genuine, otherwise some dedicated malicious bootloader could
have a way to do some bad behavior.

> 
> For example, as well as I understand, UKI's EFI stub checks
> initramfs signature. (See
> https://github.com/systemd/systemd/blob/main/docs/ROOTFS_DISCOVERY.md
> ).
> 
> It seems that this document (ROOTFS_DISCOVERY) covers
> zillions of use cases, so I hope you will find something for you.

I've said I have no time to look into this.

> 
> I also added to CC Poettering and systemd, hopefully they have some
> ideas.
> 

...

> 
>  > Personally I just don't understand why cpio stands out considering it
>  > even the format itself doesn't support xattrs and more.
> 
> As I said above, initramfs should not be feature-rich.
> 
> (But xattrs can be added to it, if needed.)

The point is:

AFAIK, There is no formal standard for POSIX cpio to implement xattrs,
IOWs, it will be some non-standard cpio just for kernel initramfs
cases, and the new added xattr code has no other usage: just for
temporary booting use case.

Take a look at `init/initramfs.c`, the entire file is just for
unpacking an unaligned/in-random-accessable cpio even it cannot be
called as `cpiofs`.

There are many real filesystems with enough features in the kernel
can help on the same use cases and data doesn't need to be moved
from unaligned cpio to tmpfs. It just sounds like a net win to me.

As for your initramfs size assumption, I don't want to comment on
this, because I'm not distribution guy, I don't know but since
users already claimed they use compressed initrd and they don't want
to unpack them all in one shot, it sounds to me that it may not be
so small.

Thanks,
Gao Xiang

> 
> -- 
> Askar Safin
> https://types.pl/@safinaskar
> 

  reply	other threads:[~2025-08-30 12:23 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-20 19:28 [PATCH] initrd: support erofs as initrd Julian Stecklina via B4 Relay
2025-03-21  2:08 ` Al Viro
2025-03-21  8:46   ` Christian Brauner
2025-03-21 12:49   ` Julian Stecklina
2025-03-21  5:01 ` Christoph Hellwig
2025-03-21  5:27   ` Gao Xiang
2025-03-21 13:17     ` Julian Stecklina
2025-03-21 13:57       ` Gao Xiang
2025-04-07  8:57       ` hch
2025-04-07 11:19         ` Julian Stecklina
2025-04-07 16:05         ` Gao Xiang
2025-08-25 18:27   ` Askar Safin
2025-08-26  7:59     ` Christoph Hellwig
2025-08-26 14:21       ` Byron Stanoszek
2025-08-26 15:32         ` Gao Xiang
2025-08-26 16:00           ` Gao Xiang
2025-08-27  9:22           ` Askar Safin
2025-08-27  9:48             ` Gao Xiang
2025-08-27  9:58               ` Gao Xiang
2025-08-28 16:44                 ` Askar Safin
2025-08-28 17:00                   ` Gao Xiang
2025-08-28 17:14                     ` Gao Xiang
2025-08-30 11:49                       ` Askar Safin
2025-08-30 12:23                         ` Gao Xiang [this message]
2025-08-26 17:00         ` Askar Safin
2025-03-21  8:48 ` Christian Brauner
2025-03-21  9:16 ` Thomas Weißschuh
2025-03-21 13:26   ` Julian Stecklina

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=aLLtJcHt0NcaZeDm@debian \
    --to=xiang@kernel.org \
    --cc=brauner@kernel.org \
    --cc=gandalf@winds.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=hsiangkao@linux.alibaba.com \
    --cc=julian.stecklina@cyberus-technology.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mzxreary@0pointer.de \
    --cc=rafael@kernel.org \
    --cc=safinaskar@zohomail.com \
    --cc=systemd-devel@lists.freedesktop.org \
    --cc=thomas.weissschuh@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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).