linux-kernel - Re: [PATCH] string: uninline memcpy_and

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

Message-ID: <de972f31-cf0d-6f68-5664-f965f80fb1b2@roeck-us.net>
Date:   Tue, 2 Nov 2021 07:20:55 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Andy Shevchenko <andy@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH] string: uninline memcpy_and_pad

On 11/2/21 12:56 AM, Geert Uytterhoeven wrote:
> Hi Günter,
> 
> Thanks for your patch!
> 
> On Tue, Nov 2, 2021 at 5:30 AM Guenter Roeck <linux@...ck-us.net> wrote:
>> When building m68k:allmodconfig, recent versions of gcc generate the
>> following error if the length of UTS_RELEASE is less than 8 bytes.
>>
>> In function 'memcpy_and_pad',
>>      inlined from 'nvmet_execute_disc_identify' at
>>          drivers/nvme/target/discovery.c:268:2:
>> arch/m68k/include/asm/string.h:72:25: error:
>>          '__builtin_memcpy' reading 8 bytes from a region of size 7
>>
>> Discussions around the problem suggest that this only happens if an
>> architecture does not provide strlen(), if -ffreestanding is provided as
>> compiler option, and if CONFIG_FORTIFY_SOURCE=n. All of this is the case
>> for m68k. The exact reasons are unknown, but seem to be related to the
>> ability of the compiler to evaluate the return value of strlen() and
>> the resulting execution flow in memcpy_and_pad(). It would be possible
>> to work around the problem by using sizeof(UTS_RELEASE) instead of
>> strlen(UTS_RELEASE), but that would only postpone the problem until the
>> function is called in a similar way. Uninline memcpy_and_pad() instead
>> to solve the problem for good.
>>
>> Suggested-by: Linus Torvalds <torvalds@...ux-foundation.org>
>> Cc: Geert Uytterhoeven <geert@...ux-m68k.org>
>> Signed-off-by: Guenter Roeck <linux@...ck-us.net>
> 
> Reviewed-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> 
>>   include/linux/string.h | 19 ++-----------------
>>   lib/string.c           | 19 +++++++++++++++++++
>>   2 files changed, 21 insertions(+), 17 deletions(-)
> 
> Given this now conflicts with commit cfecea6ead5f1588 ("lib/string:
> Move helper functions out of string.c"). perhaps you should move this
> to lib/string_helpers.c when respinning?
> 

Will do.

Thanks,
Guenter