linux-kernel - Re: CONFIG_* used by user-space to figure out whether a feature is on/off

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: <1373935603.31535.3.camel@warfang>
Date:	Mon, 15 Jul 2013 17:46:43 -0700
From:	Raymond Jennings <shentino@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: CONFIG_* used by user-space to figure out whether a feature is
 on/off

On Mon, 2013-07-15 at 10:17 -0700, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 8:40 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@...cle.com> wrote:
> >
> > I am hoping you can help me draw an understanding and a line in sand whether:
> >  a) Tools should not depend on /proc/config.gz to figure out whether
> >     a kernel has some CONFIG_X=y feature.
> 
> Well, /proc/config.gz is better than some crazy saved-off config file,
> since it at least is guaranteed to match the kernel you're running,
> but it's still a completely crazy idea. Not the least because it's not
> at all guaranteed to be there, and even if it's there, we'll rename
> config options without caring one whit. It's meant for "make
> oldconfig" style stuff, nothing more. Any user program that depends on
> it is broken by design.
> 
> >  b) If they are OK to do so, what do we do when certain CONFIG_X options
> >     get reworked/removed. Would they be considered regressions? Aka
> >     is this similar to 'you shall not break user-space'?
> 
> Absolutely not. If you depend on any config file, you're broken by
> definition. The only thing that can depend on the config file is the
> kernel tree itself, and even then we happily break that at any time
> (ie "make oldconfig" is meant to give an _approximation_ of the old
> config, but if some config option gets renamed, the old value is
> thrown away without question, and the new name is asked about).
> 
> > Irrespective of that, do you have any ideas of how a user-space program (say GRUB)
> > can figure out whether the configuration stanze it generates is supported by
> > the kernel.

I'd like to point out that Google Chrome also makes use of CONFIG_ tests
to detect support for namespaces and pid containers and stuff.

> If you don't want to answer this question - since this might
> > open a can of worms you prefer not to deal with - that is absolutly OK.
> 
> I think grub should stop trying to be clever. Quite frankly, from my
> own experience, grub has become too clever by half, and become harder
> to use and configure as a result. Just don't do it.
> 
> If you want to have grub Xen options for the kernel, make them grub
> options. In the grub config file. And if that option isn't there, just
> boot it as a native kernel. That had better work anyway, and is a hell
> of a lot more flexible and stable anyway. Don't try to be clever, and
> certainly don't try to parse some random config file that may or may
> not even match the kernel you're booting.
> 
>                  Linus
> --
> 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/


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