Re: s390/defconfigs: set CONFIG_INIT_STACK_NONE=y

Re: s390/defconfigs: set CONFIG_INIT_STACK_NONE=y

[Kees Cook]

Hi Heiko,

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. :)

Thanks,

-Kees

[1] https://git.kernel.org/linus/124acbe275040809abfa5fbe6e25790a53d5a161

-- 
Kees Cook                                            @outflux.net

Re: s390/defconfigs: set CONFIG_INIT_STACK_NONE=y

[Heiko Carstens]

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).

Re: s390/defconfigs: set CONFIG_INIT_STACK_NONE=y

[Kees Cook]

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. :)

> What is the overhead on other architectures?

It's been in the noise for real workloads.

> 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?

No, nothing missed -- there just have been no workloads identified yet
where it's needed.

> 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).

Yeah, if you find a place where it's needed, please add the compiler
attribute and put it to use. It'll give people an example use-case for
it. :)

-- 
Kees Cook

Re: s390/defconfigs: set CONFIG_INIT_STACK_NONE=y

[Sven Schnelle]

Hi Kees,

Kees Cook <keescook@chromium.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