Subject: kern/5140: if network mountroot fails, interface remains configured
To: None <gnats-bugs@gnats.netbsd.org>
From: None <cgd@NetBSD.ORG>
List: netbsd-bugs
Date: 03/09/1998 16:49:42
>Number:         5140
>Category:       kern
>Synopsis:       if network mountroot fails, interface remains configured
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Mar  9 17:05:01 1998
>Last-Modified:
>Originator:     Chris G. Demetriou
>Organization:
Kernel Hackers 'r' Us
>Release:        NetBSD-current as of March 3, 1998.
>Environment:
System: NetBSD brick.demetriou.com 1.3D NetBSD 1.3D (BRICK) #36: Wed Feb 18 21:00:25 PST 1998 cgd@brick.demetriou.com:/usr/src/sys/arch/i386/compile/BRICK i386
(the actual system which demonstrated the problem was an alpha.)


>Description:
	Logically, the mountroot functions should have no side-effects
	on error.  If network (nfs) mountroot fails, the interface used
	to try to do the mountroot remains configured, instead of being
	unconfigured.

	This can lead to a situation where the machine is pingable,
	etc., but is sitting at the "root device:"  prompt.

	It can also lead to a network interface being incorrectly
	configured if a different root device is chosen.

>How-To-Repeat:
	Try to net-boot a system, but set things up so that the
	NFS mountroot fails for some reason.  (In my case, I observed
	the problem when I had only BOOTP boot support compiled into
	the kernel and the root path wouldn't fit into the bootp
	reply packet being sent by the server.  In that case, the
	kernel was able to configure the interface's IP address,
	etc., and respond to pings, but mountroot failed.)

	Note that the interface can remain configured, respond to
	pings, etc., even when you've returned to the "root device:"
	prompt.

	Similarly, note that if booting single-user, if you try a
	NFS mountroot that fails in the fashion described above then
	go on to try a different mountroot (e.g. ffs) that succeeds,
	the interface will remain up.  (Note that I've not actually
	verified that this happens, because I don't have a file
	system on my disk right now...  but it should, given the
	symptoms.)  If the startup scripts don't reconfigure the
	network interface, this can be an annoyance and is a
	potential security problem.

>Fix:
	Undo the interface configuration if the mountroot fails.

	This would be easier to do (you'd only have to do it once,
	rather than once for the dhcp code and once for the
	bootparam code) if the ioctl-calling network configuration
	code were shared between the NFS dhcp and bootparam
	configuration functions, but even as is it should be a
	relatively simple (and duplicated!) job for someone familiar
	with the code.  "I'm not," and I didn't even attempt it.
>Audit-Trail:
>Unformatted: