linux-kernel - Re: [PATCH 04/10] misc: lkdtm: bugs: At least try to use popuated variable

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 26 Jun 2020 16:37:16 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     gregkh <gregkh@...uxfoundation.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 04/10] misc: lkdtm: bugs: At least try to use popuated variable

On Fri, Jun 26, 2020 at 3:05 PM Lee Jones <lee.jones@...aro.org> wrote:
>
> The result may not be intereresting, but not using a set variable
> is bad form and causes W=1 kernel builds to complain.
>
> Fixes the following W=1 warning(s):
>
>  drivers/misc/lkdtm/bugs.c: In function ‘lkdtm_STACK_GUARD_PAGE_LEADING’:
>  drivers/misc/lkdtm/bugs.c:331:25: warning: variable ‘byte’ set but not used [-Wunused-but-set-variable]
>  331 | volatile unsigned char byte;
>  | ^~~~
>  drivers/misc/lkdtm/bugs.c: In function ‘lkdtm_STACK_GUARD_PAGE_TRAILING’:
>  drivers/misc/lkdtm/bugs.c:345:25: warning: variable ‘byte’ set but not used [-Wunused-but-set-variable]
>  345 | volatile unsigned char byte;
>  | ^~~~
>
> Cc: Kees Cook <keescook@...omium.org>
> Signed-off-by: Lee Jones <lee.jones@...aro.org>

I think a clearer way to address this would be to add a cast to void than
to actually use the variable.

Looking at the implementation, it also seems odd to use a 'const char *' as
the source and a 'volatile char' as the destination, I would have expected
the opposite (marking the source volatile to force the access),
though I suppose the effect is the same.

    Arnd