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: <CA+55aFxShsoiTfXUJM2463ZHPNzBsV_VcKBkM4NyGMpk6Cm=iQ@mail.gmail.com>
Date:	Mon, 15 Jul 2013 10:17:01 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:	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, 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. 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/