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]
Date:	Fri, 18 Sep 2015 16:59:01 +0200
From:	Ortwin Glück <odi@....ch>
To:	Drew DeVault <sir@...wn.com>, Richard Weinberger <richard@....at>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Failover root devices

On 17.09.2015 20:28, Drew DeVault wrote:
> I don't think this is a strong argument against this feature. The implementation of this feature
> will be pretty straightfoward - only a small part of the code has to actually change its behavior
> and it can do without changing the interfaces it already relies on. On top of that, I don't think it
> can be done "nicely" in userspace anyway.

I personally think this is opening a can of worms. Now it's just a list of alternative root devices. 
But the kernel knows absolutely nothing about these. When is it fine to try an alternative? Why did 
the first one not work? Did we just not wait long enough? Or is it a failed RAID device? Or is it an 
encrypted disk that needs setup? Or is it on NFS and the network is not available (or we are lacking 
driver firmware)?

It could actually introduce security problems: if I know that a device will fallback to an 
alternative root (under my control), I can try and DOS the primary root.

In short: if a simple root device doesn't work for you, you should *really* use an initramfs.

One could even argue to remove the boot= parameter altogether and always use initramfs :-)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ