linux-hardening - Re: s390/defconfigs: set CONFIG_INIT_STACK

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: <yt9dy1l6mi82.fsf@linux.ibm.com>
Date:   Tue, 30 May 2023 08:44:13 +0200
From:   Sven Schnelle <svens@...ux.ibm.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Heiko Carstens <hca@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        linux-hardening@...r.kernel.org
Subject: Re: s390/defconfigs: set CONFIG_INIT_STACK_NONE=y

Hi Kees,

Kees Cook <keescook@...omium.org> writes:

> On Fri, May 26, 2023 at 03:42:56PM +0200, Heiko Carstens wrote:
>> Hi Kees,
>> 
>> > I had this[1] patch pointed out to me, but I couldn't find any discussion
>> > about it on public lists. Can you give me some background on this? There
>> > haven't been any general workloads identified where this has been
>> > a problem, so I'm curious why this was seen as globally an issue on
>> > s390. The expectation was to use __uninitialized on any variables where
>> > this was noticed as a performance issue, and where the memory safety of
>> > the variable could be proven. Turning it off by default seems like
>> > rather too much, but perhaps there is something unique to s390 I don't
>> > know about. :)
>> 
>> This was the result of some micro benchmarks being reported "too slow".
>> Actually our syscall entry/exit path got naturally slower since we switched
>> to generic entry; now we are trying to improve things a bit again.
>> 
>> There is also this RFC from Sven, which tries to inline some of the
>> generic system call functions, in order to avoid function calls:
>> https://lore.kernel.org/lkml/20230516133810.171487-1-svens@linux.ibm.com/
>> 
>> I stumbled upon CONFIG_INIT_STACK_NONE only by accident when wondering why
>> the compiler would generate quite some instructions which aren't necessary,
>> just to zero variables. For the getpid() system call this makes a runtime
>> difference of ~3%, which is quite a bit.
>
> Hm, that does seem high. It implies there are large variable that are
> being passed by reference, perhaps in the syscall path? I had similar
> problems a while back on x86 but due to stack-protector seeing the
> register arrays and thinking they needed protection. I had to explicitly
> turn that off for the entry code, since they're provably safe. :)

>From looking at our s390 specific entry code i don't see big arrays on
the stack, but let me do some profiling. Maybe i missed something.

Regards,
Sven