linux-kernel - Re: [PATCH] s390: Add WARN_DYNAMIC

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]

Date:   Wed, 15 Sep 2021 07:08:21 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Christian Borntraeger <borntraeger@...ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>
Cc:     Vasily Gorbik <gor@...ux.ibm.com>, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] s390: Add WARN_DYNAMIC_STACK dependencies

On 9/15/21 2:02 AM, Christian Borntraeger wrote:
> 
> 
> On 15.09.21 06:40, Guenter Roeck wrote:
>> s390:allmodconfig fails to build with the following errors.
>>
>> arch/s390/kernel/syscall.c: In function '__do_syscall':
>> arch/s390/kernel/syscall.c:168:1: error:
>>     '__do_syscall' uses dynamic stack allocation
>>
>> lib/test_kasan.c: In function 'kasan_alloca_oob_right':
>> lib/test_kasan.c:782:1: error:
>>     'kasan_alloca_oob_right' uses dynamic stack allocation
>>
>> lib/test_kasan.c: In function 'kasan_alloca_oob_left':
>> lib/test_kasan.c:767:1: error:
>>     'kasan_alloca_oob_left' uses dynamic stack allocation
>>
>> The first error is seen if RANDOMIZE_KSTACK_OFFSET_DEFAULT,
>> WARN_DYNAMIC_STACK, and WERROR are enabled. The other problems
>> are seen if KASAN_KUNIT_TEST, WARN_DYNAMIC_STACK, and WERROR
>> are enabled.
>>
>> It does not make sense to abort a build in that situation.
>> If either RANDOMIZE_KSTACK_OFFSET_DEFAULT or KASAN_KUNIT_TEST
>> is enabled, dynamic stack allocation is on purpose and should
>> not fail the build. Add dependencies to reflect that situation.
>>
> 
> Thanks for the patch. I think Heiko (on vacation) has a patch to
> get rid  of this config alltogether, which is probably the better
> solution.
> 

I did consider that, but concluded that this would be something a maintainer
should do and went with what I thought was the least invasive method.
I did check the various mailing lists for other patches, but I did not
find anything there. Sorry if I missed it.

Guenter