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
| ||
|
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/
Powered by blists - more mailing lists