linux-kernel - [PATCH] kconfig: make 'imply' obey the direct dependency

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-next>] [day] [month] [year] [list]

Date:   Wed, 19 Feb 2020 16:49:50 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     linux-kbuild@...r.kernel.org
Cc:     Arnd Bergmann <arnd@...db.de>, Nicolas Pitre <nico@...xnic.net>,
        Richard Cochran <richardcochran@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        John Stultz <john.stultz@...aro.org>,
        Josh Triplett <josh@...htriplett.org>,
        Mark Brown <broonie@...nel.org>,
        Ulf Magnusson <ulfalizer@...il.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Michal Marek <michal.lkml@...kovi.net>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH] kconfig: make 'imply' obey the direct dependency

The 'imply' statement may create unmet direct dependency when the
implied symbol depends on m.

[Test Code]

  config FOO
          tristate "foo"
          imply BAZ

  config BAZ
          tristate "baz"
          depends on BAR

  config BAR
          def_tristate m

  config MODULES
          def_bool y
          option modules

If you set FOO=y, BAZ is also promoted to y, which results in the
following .config file:

  CONFIG_FOO=y
  CONFIG_BAZ=y
  CONFIG_BAR=m
  CONFIG_MODULES=y

This ignores the dependency "BAZ depends on BAR".

Unlike 'select', what is worse, Kconfig never shows the
"WARNING: unmet direct dependencies detected for ..." for this case.

Because 'imply' should be weaker than 'depends on', Kconfig should
take the direct dependency into account.

Describe this case in Documentation/kbuild/kconfig-language.rst for
clarification.

Commit 237e3ad0f195 ("Kconfig: Introduce the "imply" keyword") says that
a symbol implied by y is restricted to y or n, excluding m.

As for the combination of FOO=y and BAR=m, the case of BAZ=m is excluded
by the 'imply', and BAZ=y is also excluded by 'depends on'. So, only the
possible value is BAZ=n.

Having said that, this case was probably "We don't care" at that time
because Kconfig did not handle 'depends on m' correctly until
commit f622f8279581 ("kconfig: warn unmet direct dependency of tristate
symbols selected by y") fixed it.

Backporting this to 4.19+ will probably be fine. If you care this
problem on 4.14.x, you need to backport f622f8279581 as well.

Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
---

 Documentation/kbuild/kconfig-language.rst |  7 +++++--
 scripts/kconfig/symbol.c                  | 17 +++++++++++++----
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
index d0111dd26410..9141f03ff744 100644
--- a/Documentation/kbuild/kconfig-language.rst
+++ b/Documentation/kbuild/kconfig-language.rst
@@ -159,11 +159,11 @@ applicable everywhere (see syntax).
   Given the following example::
 
     config FOO
-	tristate
+	tristate "foo"
 	imply BAZ
 
     config BAZ
-	tristate
+	tristate "baz"
 	depends on BAR
 
   The following values are possible:
@@ -174,6 +174,9 @@ applicable everywhere (see syntax).
 	n		y		n		N/m/y
 	m		y		m		M/y/n
 	y		y		y		Y/n
+	n		m		n		N/m
+	m		m		m		M/n
+	y		m		n		N
 	y		n		*		N
 	===		===		=============	==============
 
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 8d38b700b314..6100e6ead8ad 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -221,7 +221,7 @@ static void sym_calc_visibility(struct symbol *sym)
 		sym_set_changed(sym);
 	}
 	tri = no;
-	if (sym->implied.expr && sym->dir_dep.tri != no)
+	if (sym->implied.expr)
 		tri = expr_calc_value(sym->implied.expr);
 	if (tri == mod && sym_get_type(sym) == S_BOOLEAN)
 		tri = yes;
@@ -393,7 +393,17 @@ void sym_calc_value(struct symbol *sym)
 				}
 				if (sym->implied.tri != no) {
 					sym->flags |= SYMBOL_WRITE;
-					newval.tri = EXPR_OR(newval.tri, sym->implied.tri);
+					newval.tri = EXPR_OR(newval.tri,
+							     sym->implied.tri);
+					newval.tri = EXPR_AND(newval.tri,
+							      sym->dir_dep.tri);
+
+					if (newval.tri == mod && sym->implied.tri == yes) {
+						if (sym->dir_dep.tri == yes)
+							newval.tri = yes;
+						else
+							newval.tri = no;
+					}
 				}
 			}
 		calc_newval:
@@ -401,8 +411,7 @@ void sym_calc_value(struct symbol *sym)
 				sym_warn_unmet_dep(sym);
 			newval.tri = EXPR_OR(newval.tri, sym->rev_dep.tri);
 		}
-		if (newval.tri == mod &&
-		    (sym_get_type(sym) == S_BOOLEAN || sym->implied.tri == yes))
+		if (newval.tri == mod && sym_get_type(sym) == S_BOOLEAN)
 			newval.tri = yes;
 		break;
 	case S_STRING:
-- 
2.17.1