linux-kernel - Re: [PATCH v3] rootfs: Fix support for rootfstype= when root= is given

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c7b8d248-fb59-0476-dea8-89d40207460f@landley.net>
Date: Thu, 4 Jan 2024 10:38:53 -0600
From: Rob Landley <rob@...dley.net>
To: Askar Safin <safinaskar@...il.com>
Cc: Stefan Berger <stefanb@...ux.ibm.com>, gregkh@...uxfoundation.org,
 initramfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 stable@...r.kernel.org, zohar@...ux.ibm.com
Subject: Re: [PATCH v3] rootfs: Fix support for rootfstype= when root= is
 given

On 1/4/24 00:06, Askar Safin wrote:
> On Sat, Dec 30, 2023 at 8:01 PM Rob Landley <rob@...dley.net> wrote:
>> I've been following the initramfs xattr support threads forever:
> 
> Here is my proposal: add to the kernel support for catar (
> https://0pointer.net/blog/casync-a-tool-for-distributing-file-system-images.html
> ) in addition to cpio. catar has the following advantages:

Didn't we just have a thread about the inadvisability of adding more ways to do
the same thing, with each existing codepath still having to be supported forever?

And your solution is a link to the website of Lenart Pottering, author and
maintainer of systemd. You want to put systemd code into the kernel.

> - catar is simple and reproducible. For the same directory tree the
> same bit-precise catar file is generated, which is good for
> cryptographic signatures.

I can trivially reproduce the same cpio each time from the same tree, the trick
is just fetching the whole directory and sorting it before processing (to
squelch hash-impacted readdir() return order from the filesystem).

> As opposed to tar's monstrosity (
> https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar )
> - catar has support for xattr.

Adding xattr support to my toybox cpio implementation is maybe 10 lines of C, I
assume the other implementations aren't that much more tangled. The question was
always a largely aesthetic issue of file format.

Tar is NOT well-defined. I say this as someone who has IMPLEMENTED tar and has a
pending TODO item to patch up YET ANOTHER funky corner case du jour somebody hit:

https://github.com/landley/toybox/issues/469

Inventing a NEW file format... there are multiple dozens already: zip, arj,
lharc, zoo... You could theoretically extract squashfs into initramfs because
technically it's an archive format.

Good grief, there's an xkcd on that:

https://xkcd.com/927/

> It has support for nearly all types of

"nearly"

Please no.

> metainformation Linux offers (32 bit UIDs, nanosecond timestamps,
> "disable CoW" flag and various other flags, selinux file labels, file
> capabilities, etc). All this metainformation can be disabled if
> needed. So, next time we will want to add some new type of
> metainformation, there will be no need for lengthy discussions about
> how it should be stored.

There's no real need NOW. "We did not come to an agreement in email" does not
mean "let's add a new unrelated format". It means let's carve out an hour to
actually speak to each other, by voice and maybe video, using this thing called
the internet. (Without covid we'd have had a BOF at some conference by now.)

Rob