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

Date:   Fri, 26 May 2023 15:42:56 +0200
From:   Heiko Carstens <hca@...ux.ibm.com>
To:     Kees Cook <kees@...flux.net>
Cc:     Alexander Gordeev <agordeev@...ux.ibm.com>,
        linux-hardening@...r.kernel.org,
        Sven Schnelle <svens@...ux.ibm.com>
Subject: Re: s390/defconfigs: set CONFIG_INIT_STACK_NONE=y

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.

What is the overhead on other architectures?

That said: I was also unaware of __uninitialized. But on the other hand,
there is no sign of __uninitialized in the kernel, nor could I find
anything that could match in compiler_attributes.h.
Am I missing something here?

Thanks for bringing this up, I guess if there is some annotation available,
we can revisit at least the architecture specific entry code, and maybe
figure out how to avoid most of the extra runtime, but still keep the
feature enabled.

(Adding Sven, since I will be offline the next two weeks).