linux-kernel - Re: [PATCH 1/2] kconfig: also warn of unhandled characters in statements

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: <CAEMqcmrBWGFGTZXvASDXRtTUtb=5=q-b_9a3A_hQ8RC47zNhUg@mail.gmail.com>
Date:	Sun, 5 Jul 2015 08:06:33 +0200
From:	Ulf Magnusson <ulfalizer.lkml@...il.com>
To:	Andreas Ruprecht <andreas.ruprecht@....de>
Cc:	Paul Bolle <pebolle@...cali.nl>,
	Valentin Rothberg <valentinrothberg@...il.com>,
	rafael.j.wysocki@...el.com,
	"open list:KCONFIG" <linux-kbuild@...r.kernel.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	hengelein Stefan <stefan.hengelein@....de>,
	linux@...inikbrodowski.net, Michal Marek <mmarek@...e.cz>
Subject: Re: [PATCH 1/2] kconfig: also warn of unhandled characters in statements

A more exact commit title would be something like "warn for unhandled
characters before the initial token on a line".

On Fri, Jul 3, 2015 at 2:46 PM, Andreas Ruprecht
<andreas.ruprecht@....de> wrote:
> While commit 2e0d737fc76f ("kconfig: don't silently ignore unhandled
> characters") introduced a warning for unsupported characters inside
> parameters, it does not cover situations where a statement
> has additional characters around it.

This could say something like "...introduces a warning for unhandled characters
after the initial token on a line, but does not cover unhandled characters
before the initial token, which are ignored using a different mechanism."

>
> This change introduces a warning if superfluous characters are found
> around statements. As the 'help' statement sometimes is written as
> '---help---', the '-' character would now also be regarded as
> unhandled, this change also adds a special rule for this case.

Similarly above.

>
> Reported-by: Valentin Rothberg <valentinrothberg@...il.com>
> Signed-off-by: Andreas Ruprecht <andreas.ruprecht@....de>
> ---
>  scripts/kconfig/zconf.l | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
> index 200a3fe..84a5d05 100644
> --- a/scripts/kconfig/zconf.l
> +++ b/scripts/kconfig/zconf.l
> @@ -106,7 +106,15 @@ n  [A-Za-z0-9_]
>                 zconflval.string = text;
>                 return T_WORD;
>         }
> -       .
> +       "---help---"    {
> +               /* Support old syntax for help statement */
> +               return T_HELP;
> +       }

I haven't tried it out to see if there would be problems, but adding '-' to the

n    [A-Za-z0-9_]

definition in zconf.l and adding '---help---' to zconf.gperf seems cleaner than
special-casing it in zconf.l. If '---help---' is treated as a token, then it
makes sense to include '-' among the token characters.

(I also rambled a bit in
http://www.spinics.net/lists/linux-kbuild/msg11393.html.)

With that change, '-' could be removed from the parameter regex ({n}|[-/.])+ in
zconf.l too.

> +       .       {
> +               fprintf(stderr,
> +                       "%s:%d:warning: ignoring unsupported character '%c'\n",
> +                       zconf_curname(), zconf_lineno(), *yytext);
> +       }
>         \n      {
>                 BEGIN(INITIAL);
>                 current_file->lineno++;
> @@ -132,7 +140,6 @@ n   [A-Za-z0-9_]
>                 BEGIN(STRING);
>         }
>         \n      BEGIN(INITIAL); current_file->lineno++; return T_EOL;
> -       ---     /* ignore */
>         ({n}|[-/.])+    {
>                 const struct kconf_id *id = kconf_id_lookup(yytext, yyleng);
>                 if (id && id->flags & TF_PARAM) {
> --
> 1.9.1
>

Cheers,
Ulf
--
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/