linux-kernel - Re: Mounting NFS root FS

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: <20061203060208.GA900@1wt.eu>
Date:	Sun, 3 Dec 2006 07:02:08 +0100
From:	Willy Tarreau <w@....eu>
To:	Trond Myklebust <trond.myklebust@....uio.no>
Cc:	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	William Estrada <MrUmunhum@...dial.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Mounting NFS root FS

On Sat, Dec 02, 2006 at 09:37:18PM -0500, Trond Myklebust wrote:
> On Sat, 2006-12-02 at 23:55 +0100, Willy Tarreau wrote:
> > I'm not saying initramfs is not powerful, and indeed your example is
> > the common way of parsing cmdline for me too. What I'm saying is that
> > before nfsroot stops being supported, we'll need a working replacement
> > (and not "### further parse $arg"), if possible within the kernel tree
> > so that people who used to build kernels to boot such machines will
> > still be able to build kernels for them, even if this implies using
> > an initramfs with some tools in it.
> > 
> > The real danger of removing support for in-kernel features like this
> > is to leave people with no solution at all (because they don't know
> > how to proceed), and their workarounds are often worse than the
> > problem that we tried to fix in the first place.
> 
> It hasn't been removed yet. However most distributions choose not to
> enable it because that would force them to compile the NFS client into
> the main kernel instead of leaving it as a module.

That's a valid point, but in fact, building with NFS client and serial
port support in the kernel on some archs is as common as building with
IDE driver and VGA console in the kernel on x86. With some architectures
used in light networked workstations, it's very common to boot from the
network (sparc & parisc come to mind, sorry to those I forgot), hence
this common practise.

> As for the initramfs support, hpa has assured me that his klibc
> distribution already has a full solution for NFS mounting on current
> kernels.

That's again where we see the limits of this ever-developping 2.6.
I'm not saying that doing this from initramfs+tools is a bad solution,
since it solves lots of problems, it's just that it is *much* different
from what was previously done.

People who have installed a distro on their machines will not be
able to upgrade their kernel past a certain point by hand. Upgrading
distro packages in such environments is generally not always an
option (particularly boot packages such as boot loader and kernel),
because the boot server is not necessarily running on the same
OS/distro, and sometimes the kernel needs different build options.

Then the remaining solution to get stability and security fixes
is often to [cross-]compile a more recent kernel, and to put it
on the boot server. Fortunately Adrian maintains 2.6.16 :-/

> Trond

Regards,
Willy

-
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/