linux-kernel - Re: [PATCH 1/9] ASoC: Intel: Fix Kconfig with top-level selector

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: <s5hr2rr3tul.wl-tiwai@suse.de>
Date:   Tue, 19 Dec 2017 11:17:06 +0100
From:   Takashi Iwai <tiwai@...e.de>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     alsa-devel@...a-project.org, broonie@...nel.org,
        torvalds@...ux-foundation.org, vinod.koul@...el.com,
        liam.r.girdwood@...ux.intel.com, andriy.shevchenko@...ux.intel.com,
        arnd@...db.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/9] ASoC: Intel: Fix Kconfig with top-level selector

On Fri, 15 Dec 2017 13:30:28 +0100,
Pierre-Louis Bossart wrote:
> 
> On 12/15/17 5:07 AM, Takashi Iwai wrote:
> > On Fri, 15 Dec 2017 01:44:43 +0100,
> > Pierre-Louis Bossart wrote:
> >>
> >> +config SND_SOC_ACPI_INTEL_MATCH
> >> +	tristate
> >> +	depends on X86 && ACPI
> >> +	select SND_SOC_ACPI
> >
> > An item that is selected by others can only select, not depend.
> > The depends need to be put for the items that select this instead.
> 
> Initially the code was
> 
> config SND_SOC_ACPI_INTEL_MATCH
>         tristate
>         select SND_SOC_ACPI if ACPI
> 
> I changed it to use depends to make some 0-day reports go away, for
> some reason this option was selected with ARCH=mn10300 and generated
> warnings. I don't quite understand how that happened since X86 and
> ACPI are clear dependencies in the items which select this option...
> 
> Vinod also added a similar pattern with
> 
> +config SND_SOC_INTEL_SST_TOPLEVEL
> +	bool "Intel ASoC SST drivers"
> +	default y
> +	depends on X86 || COMPILE_TEST
> +	select SND_SOC_INTEL_MACH
> 
> +menuconfig SND_SOC_INTEL_MACH
> +	bool "Intel Machine drivers"
>  	depends on SND_SOC_INTEL_SST_TOPLEVEL
> 
> Maybe that needs to be removed as well?

Having both depends and select on the top-level is OK.  The only
problem is when an item that is selected by others has another
depends.  For example, a simple-looking case like below is actually
buggy:

config BAR
	tristate
	depends on X

config FOO
	tristate "foo"
	select BAR

Here BAR would be enabled by FOO no matter what X is, even if X=n.
That said, when an item is selected, its own dependency is ignored.

For correcting this, the depends-on-X must be moved to the top-level
who selects the item:

config BAR
	tristate

config FOO
	tristate "foo"
	depends on X
	select BAR

Note that the reverse-select chain works as expected.  The breakage is
only the mixture of select and depends in the selected items.


Takashi