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:40:34 +0100
From:	Markus Trippelsdorf <markus@...ppelsdorf.de>
To:	Ingo Molnar <mingo@...nel.org>
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)

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.

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. 

-- 
Markus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ