linux-kernel - Re: Subject:[PATCH 1:1] boot paramer "root=" gets a list of devices

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPXgP12QS3jGi3pcEhSAoGcWdtjmujL-HP69Cgy9_+kRLFq1sQ@mail.gmail.com>
Date:	Thu, 15 Dec 2011 19:11:46 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	rbenyehuda@...z.com, "wad@...omium.org" <wad@...omium.org>,
	Rasty Slutsker <RSlutsker@...z.com>,
	Lior Brafman <LBrafman@...z.com>, raziebe@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: Subject:[PATCH 1:1] boot paramer "root=" gets a list of devices

On Thu, Dec 15, 2011 at 16:22, H. Peter Anvin <hpa@...or.com> wrote:
> On 12/15/2011 07:19 AM, Raz Ben Yehuda wrote:
>>>
>>> To which point I have to ask, once again, at which point we stop putting
>>> this stuff in the kernel to "bypass the need for initramfs"...
>>
>> because there are times where we cannot use initramfs. is this a problem
>> with way i phrase or with with the whole idea ?

I don't see why stuff needs to search a hard-coded list of stuff. That
logic seems pretty much backwards to me. You either use the GPT stuff
that allows to flag the right partition to boot from a set of
partitions, or you go as far as make the kernel parse the filesystem
UUID of partitions. But hard-coding search lists on the commandline, I
really don't understand.

> There are problems with the whole concept of "cannot use initramfs".  We
> allow the initramfs to be integrated with the kernel image for a reason, for
> example.
>
> I'm obviously ranting on this in part to make people think about what they
> are doing, and partly to remind that the more complex the in-kernel
> root-mounting code get, the more it might be worth reconsidering klibc in
> the kernel build tree.

I think the whole picture of klibc is confusing and I very much don't
want to see that busybox-style hacking in the kernel sources.

Distros can not afford to support 2 libcs at bootup, and the distro
initramfss gets so complicated today, that a klibc-only solution does
not really work. So we end up with 2 libcs in the same initramfs
image, which makes zero sense. Leave alone the fact, that the klibc
tools duplicate all the stuff that already works in the real root in a
completely different and mostly insufficient and sometimes scary way.

The thing is, if the setup is that simple that klibc works, it is very
likely that the current in-kernel mount code is simple, well tested
and sufficient enough. If a distro-style intramfs is needed, klibc is
not usable (see above). The big distros will very unlikely ever pick
it up. The the remaining use-cases will stay a niche, that, I think,
does not justify the kernel inclusion of klibc.

If the whole klibc approach, if not entirely rethought, I doubt it
will ever go anywhere. In my opinion, with all what I've seen the last
years, we either work on a full libc in the kernel tree, that can be
used by normal userspace too, or we leave the tiny stuff to busybox
and one of the existing tiny libcs.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/