linux-kernel - Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH] x86/kconfig: Sanity-check config file during oldconfig)

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:	Tue, 19 Jan 2016 09:54:12 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Markus Trippelsdorf <markus@...ppelsdorf.de>
Cc:	Borislav Petkov <bp@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Marek <mmarek@...e.cz>,
	Måns Rullgård <mans@...sr.com>,
	Thomas Voegtle <tv@...96.de>, linux-kernel@...r.kernel.org,
	x86-ml <x86@...nel.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jiri Olsa <jolsa@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Frédéric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y (was: Re: [RFC PATCH]
 x86/kconfig: Sanity-check config file during oldconfig)


* Markus Trippelsdorf <markus@...ppelsdorf.de> wrote:

> On 2016.01.19 at 09:20 +0100, Ingo Molnar wrote:
> > 
> > ( I've Cc:-ed Linus, Greg and Andrew, to see whether doing something like what I 
> >   suggest below in the x86 architecture would be acceptable. )
> > 
> > * Borislav Petkov <bp@...e.de> wrote:
> > 
> > > From: Borislav Petkov <bp@...e.de>
> > > 
> > > Thomas Voegtle reported that doing oldconfig with a .config which has
> > > CONFIG_MICROCODE enabled but BLK_DEV_INITRD disabled prevents the
> > > microcode loading mechanism from being built.
> > > 
> > > Add a short script which hooks into the "make oldconfig" handling and
> > > sanity-checks the config file for that discrepancy. It issues a message
> > > which should hopefully sensitize the user to that issue and point her
> > > into the right direction.
> > 
> > So it would be much better to just do such things automatically, and only allow 
> > 'safe' combination of options - without the user having to do anything.
> > 
> > The guiding principle is: kernel configuration is (still...) our worst barrier of 
> > entry for new users/developers, and kernel configuration still sucks very much 
> > from a UI point of view.
> > 
> > In fact our kernel configuration UI and workflow is still so bad that it's an 
> > effort to stay current even with a standalone and working .config, even for 
> > experienced kernel developers...
> > 
> > Adding a (somewhat hacky) post processing script and forcing users to read 
> > something 99% of them does not have a clue about is a step in the wrong direction, 
> > IMHO.
> > 
> > So can we do something more intelligent instead, such as modifying the Kconfigs in 
> > a way that it's not possible to have CONFIG_MICROCODE enabled while BLK_DEV_INITRD 
> > is disabled?
> > 
> > I'd be fine with a 'select BLK_DEV_INITRD' for example. If people doing super 
> > specialized setups disagree because they really need that nonsensical combination 
> > of config options, they can complain and provide a better solution.
> > 
> > In fact on x86 I'd suggest we go farther than that and add a core set of selects 
> > that can be disabled only through a sufficiently scary "I really know I'm doing 
> > something utmost weird" (and default disabled) config option.
> 
> This is essential. Because, believe it or not, there are still users out
> there that don't use systemd. And to force enable totally superfluous
> config options for them would be bad.

Well, I think the argument I raised later on is important:

> >  [...] from a usability POV it's _much_ better to have a few more options 
> > enabled in a .config of thousands of entries, than to accidentally have the 
> > one option not enabled that your user-space somehow critically depends on ...

I.e. the costs of quirks are _massively_ assymetric: having an extra system call 
or compat option quirk enabled is essentially unmeasurable for those who don't 
technically need them, while it can be a big and hard to debug show-stopper for 
others.

'default y' was supposed to cover such cases, but arguably it's too opaque, I 
think we need a separate, more obvious layer - such as the 
CONFIG_FORCE_MINIMALLY_SANE_CONFIG=y option I suggested.

> So, as long as this "systemd config" could be easily disabled, your approach 
> looks fine and would definitely be helpful to many mainstream distro users.

It sure can be easily disabled, that's a given.

The key point is that I'd like "naively configured" kernels to work on just about 
any Linux distro that allow kernel testing - so the superset of all quirks should 
be included - as long as enabling a quirk does not break things (and none of the 
ones I listed do as far as I've tested).

Thanks,

	Ingo