linux-kernel - Re: CONFIG_EXPERT is a booby trap

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: <50690CFE.6010600@xenotime.net>
Date:	Sun, 30 Sep 2012 20:24:46 -0700
From:	Randy Dunlap <rdunlap@...otime.net>
To:	Tim Shepard <shep@...m.mit.edu>
CC:	linux-kernel@...r.kernel.org
Subject: Re: CONFIG_EXPERT is a booby trap

On 09/30/2012 07:21 PM, Tim Shepard wrote:

> A month or two ago when I attempted to upgrade from 3.4 to 3.5 on my
> MacBook Pro laptop, in preparation to try an interesting patch to TCP
> developed against 3.5 by a colleague, my keyboard stopped working.  I
> tried bisecting, but that lead to nowhere useful and much confusion.
> 
> 
> It turns out that while I was looking for some debug options under
> "General setup" and "Kernel hacking", I turned on "Configure standard
> kernel features (expert users)" which is also known as CONFIG_EXPERT.
> I read the documentation for that option, and I perused the options
> which appeared underneath when it was turned on, thought to myself "oh,
> hmm, I don't want to change any of these" and wandered off and
> eventually found what I was actually looking for elsewhere in the
> kernel configuration tree.
> 
> This weekend I finally figured out why the keyboard in my MacBook Pro
> stopped working between 3.4 and 3.5.
> 
> When I turned on CONFIG_EXPERT it turned off CONFIG_HID_APPLE.  There
> was no warning that selecting "Configure standard kernel features" will
> invisibly turn off needed things elsewhere in the configuration tree.
> 
> Something needs to be fixed, but it's not obvious that any simple change
> will work without causing other troubles.
> 
> I've read some of the lkml history history and learned that references
> to CONFIG_EXPERT (like the one on CONFIG_HID_APPLE) used to be
> references to CONFIG_EMBEDDED, so CONFIG_EXPERT used to mean something
> else.
> 
> Maybe "make menuconfig" should show you all the things that you've just
> changed and ask for confirmation when changing one configuration option
> causes actual configuration changes elsewhere in the tree.
> 
> And may I suggest that CONFIG_EXPERT should be factored into two
> CONFIGs, one of which makes configuration things visible, and another
> which changes the default values to something more appropriate for
> embedded systems (perhaps call it CONFIG_EMBEDDED_DEFAULTS).  That way
> you'd have to select CONFIG_EXPERT, and then select the
> CONFIG_EMBEDDED_DEFAULTS option that CONFIG_EXPERT made visible to
> actually change any configuration, and the documentation for
> CONFIG_EMBEDDED_DEFAULTS could explain that it changes defaults
> throughout the tree (and selecting CONFIG_EXPERT alone would not go off
> and muck things up with no warning).
> 
> The transition plan such a factoring needs some further thought to avoid
> breaking anyone's current configuration when they "make oldconfig".


I don't disagree with you that it can be a problem, but
the help text for CONFIG_EXPERT does say:

	Only use this if you really know what you are doing.


Anyway, the hid drivers are certainly a big user of this mechanism.
Many of them are like HID_APPLE:

config HID_APPLE
	tristate "Apple {i,Power,Mac}Books" if EXPERT
	depends on (USB_HID || BT_HIDP)
	default !EXPERT


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