Received-SPF: pass (google.com: domain of linux-kernel+bounces-13934-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <01010fbc-50d9-37f3-309c-f01643865ed9@landley.net>
Date: Mon, 1 Jan 2024 12:50:31 -0600
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [PATCH v3] rootfs: Fix support for rootfstype= when root= is
 given
Content-Language: en-US
To: Stefan Berger <stefanb@linux.ibm.com>, Askar Safin <safinaskar@gmail.com>
Cc: gregkh@linuxfoundation.org, initramfs@vger.kernel.org,
 linux-kernel@vger.kernel.org, stable@vger.kernel.org, zohar@linux.ibm.com
References: <CAPnZJGDcNwPLbzC99qNQ+bRMwxPU-Z0xe=TD6DWQU=0MNyeftA@mail.gmail.com>
 <d4b227de-d609-aef2-888b-203dbcf06707@landley.net>
 <CAPnZJGBeV-E_AN8GnTfkaJvRtBmCeMYYCt+O0XMsc3kDULRuKg@mail.gmail.com>
 <fb776d99-1956-4e1b-9afc-84f27ca40f46@linux.ibm.com>
 <0879141d-462c-7e94-7c87-7a5b5422b8ed@landley.net>
 <e32077de-b159-4a7b-89a3-e1925239142f@linux.ibm.com>
 <fcb45898-0699-878f-0656-f570607fbed4@landley.net>
 <8b85253d-dd75-42e4-9a05-dafb3618269c@linux.ibm.com>
From: Rob Landley <rob@landley.net>
In-Reply-To: <8b85253d-dd75-42e4-9a05-dafb3618269c@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/31/23 10:03, Stefan Berger wrote:
>> Let me see if I understand your problem: it sounds like debian's initramfs-tools
>> overloads the root= and rootfstype= arguments parsed by the kernel to have a
>> second meaning (the kernel uses them for one thing, you want to use them for
>> something else, and there's currently a semantic gap between the two.)
> 
> My intention is to be able to pass rootfstype= to the kernel and have it 
> interpreted correctly in the presence of root=, which currently does not 
> work. User space tools that interpret the value of rootfstype= as if 
> this option belonged to user space is not helpful, though it should be 
> easy to teach the user space scripts to strip a leading 'tmpfs,' or 
> 'ramfs,' from the rootfstype value and let them interpret the rest.

Does your initramfs plumbing need to pass a rootfstype equivalent on to the
userspace mount at all? In what cases does it not autodetect the type correctly?

(Even NFS and SMB mounts are generally detectable because of the leading \\ or
blah: although I suppose there are other network filesystem types that wouldn't
be. Or if you wanted to micromanage the fat variant you were using...)

"rootfstype=" is the argument that tells the _kernel_ how to mount / and by the
time init runs the kernel's already mounted what it's going to mount. The kernel
only exposes one visible / mount to userspace, you don't return back into it and
get another init launched running in a different root filesystem.

>> You want to add a new capability requiring a new build dependency in the
>> initramfs-tools package because it's doing new stuff, but there cannot be any
>> OTHER changes made to initramfs-tools, so the kernel should change its existing
>> semantics instead.
> 
> I haven't even thought of what would need to be added to Debian's 
> initramfs-tools package since my primary goal was to enable tmpfs for 
> the initramfs on OpenBMC where we then read the xattr values from a file 
> and write them into the filesystem because cpio format doesn't carry 
> them.

Me, I'd have a simple initramfs extract/decrypt a tarball with the filesystem
that needs xattr values into a new tmpfs mount and switch_root to that. But I
tend to statically link an initramfs into the kernel image when I want to be
sure what it's running, and have never quite been clear on the benefit of
_additionally_ verifying data that originates from within the kernel image. (If
they can change that, they can change ring 0 code.)

Still, adding xattr support to cpio comes up a lot. It seems like a couple days
work tops, maybe the interested parties should do a video conference thingy,
hammer out the details, and come up with a patch to add support? The userspace
side sounds easy enough, I added xattr support to toybox tar in 2021 in a
weekend, and have sent "would you like to keep up with toybox" patches at the
busybox guys semi-regularly.

I even poked coreutils about feature parity once (the Android guys asked me to),
which they said they would like to add, but which but still isn't in years later:

https://lists.gnu.org/archive/html/coreutils/2023-08/msg00009.html
https://lists.gnu.org/archive/html/coreutils/2023-08/msg00100.html

But eh, I'm used to that with 30 year old projects licensed under copyleft...

> Also, I didn't expect that any user space tools would try to 
> handle a kernel command line option as if it was theirs.

Debian predates the 1.0 kernel release, so has some historical design baggage.
That's why it's I tend to check them for snags in this area.

>> You can't NOT provide root=, and you can't provide initramfstype=tmpfs...
> 
> I only know about rootfstype= ( 
> https://github.com/torvalds/linux/blob/master/init/do_mounts.c#L128 ). 
> If currently handling of rootfstype= in presence of root= is not 
> considered a bug and we should introduce initramfstype= instead, we 
> could do that. But doesn't this become a bit confusing if rootfstype= 
> can be passed when root= is absent but then initramfstype= must be used 
> when root= is present?

I personally think having two would be confusing, and changing the existing API
without adding new capabilities is pointless.

> This is 'our' patch describing the issue: 
> https://github.com/torvalds/linux/blob/master/init/do_mounts.c#L128
> 
>> either, and those are the two existing ways to tell rootfs to be tmpfs instead
>> of ramfs. You'd like to add a third way to specify the same thing.
> 
> Do you have a link to initramfstype= handling in kernel code?

No, it's never done that. There was a suggestion to do that earlier in this thread:

https://lkml.iu.edu/hypermail/linux/kernel/2312.2/07060.html

And I thought it was a bad idea. The submitter agreed it was a bad idea. (Over
the holidays I've haven't been paying close attention and threads tend to bleed
together, sorry. :)

The answer to my "do I have this right" question was, apparently, "no". I mixed
together what two different people wanted...

Rob