linux-kernel - Re: [RFC][PATCH] kconfig: introduce listunknownconfig

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: <20230820072119.GM907732@google.com>
Date:   Sun, 20 Aug 2023 16:21:19 +0900
From:   Sergey Senozhatsky <senozhatsky@...omium.org>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nicolas Schier <nicolas@...sle.eu>,
        Jonathan Corbet <corbet@....net>,
        Tomasz Figa <tfiga@...omium.org>, linux-kbuild@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] kconfig: introduce listunknownconfig

On (23/08/20 14:11), Masahiro Yamada wrote:
> > That doesn't seem cover the cases that I'm concerned with. I don't see
> > anything related to "!sym" in the patch.
> >
> > What will KCONFIG_VERBOSE do if it reads the following config file?
> >
> > // assuming that both config options were valid and existed in the old
> > // kernel, but were removed/renamed in the new kernel
> >
> >  $ cat .config
> >  CONFIG_DISABLE_BUGS=y
> >  # CONFIG_ENABLE_WINAPI is not set
> >
> >
> > I'd like to see warnings for both lines, even for config that is not
> > set, because it maybe we set by a build script depending on USE flags
> > for instance, so that build target may still refer to non-existent
> > config.
> 
> 
> I did not say Ying Sun's patch covered your case.
> 
> I just meant I dislike your approach.

Sure, OK.

> After his patch is applied, please come back with a similar approach

I guess Ying Sun's patch cannot be extended to cover these extra cases?

What the preferred approach would be? Do we want a new KCONFIG_FOO env
variable that changes behaviour of one of the targets? E.g.

	KCONFIG_LIST_MISSING=1 make oldconfig

and then have conf list symbols and terminate with exit(1) if there are
some unrecognized symbols?

We have "listnew", so "listmissing" sort of fits as a new target.

> if you want to address your case in the mainline kernel

Yes please, we want an upstream solution for the problem in question.