RFC: Update MINSIGSTKSZ and SIGSTKSZ

RFC: Update MINSIGSTKSZ and SIGSTKSZ

[H.J. Lu]

Since www.openwall.com is down and I can't subscribe to the libc-coord list, I
post it here.

MINSIGSTKSZ and SIGSTKSZ were defined as constant:

/* Minimum stack size for a signal handler.  */
#define MINSIGSTKSZ 2048

/* System default stack size.  */
#define SIGSTKSZ 8192

more than 20 years ago.  For today's processors, they are too small:

https://sourceware.org/bugzilla/show_bug.cgi?id=20305

I am proposing to make them as dynamic based on AT_MINSIGSTKSZ for
-D_GNU_SOURCE:

extern int getminsigstacksize (void);

#ifdef __USE_GNU
/* Minumum stack size for a signal handler: AT_MINSIGSTKSZ + 1.5KB.  */
# undef MINSIGSTKSZ
# define MINSIGSTKSZ (getminsigstacksize () + 1536)

/* System default stack size for a signal handler: MINSIGSTKSZ + 6KB.  */
# undef SIGSTKSZ
# define SIGSTKSZ (MINSIGSTKSZ + 6144)
#endif

On x86, we can emulate AT_MINSIGSTKSZ if kernel doesn't provide it:

 /* Emulate AT_MINSIGSTKSZ.  In Linux kernel, the signal frame data
     with XSAVE is composed of the following areas and laid out as:
     ------------------------------
     | alignment padding          |
     ------------------------------
     | xsave buffer               |
     ------------------------------
     | fsave header (32-bit only) |
     ------------------------------
     | siginfo + ucontext         |
     ------------------------------
 */

It works for most usages, except for

static char stack[MINSIGSTKSZ];

--
H.J.

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[Zack Weinberg]

On Tue, Sep 29, 2020 at 9:27 AM H.J. Lu via Libc-alpha
<libc-alpha@sourceware.org> wrote:
> MINSIGSTKSZ and SIGSTKSZ were defined as constant:
...
> I am proposing to make them as dynamic based on AT_MINSIGSTKSZ for
> -D_GNU_SOURCE:

A quick check of
https://dcs.zekjur.net/search?q=%5CbMINSIGSTKSZ%5Cb&literal=0 and
https://dcs.zekjur.net/search?q=%5CbSIGSTKSZ%5Cb&literal=0 gives me
the impression that this is likely to break a lot of software; these
constants are often used in #if expressions and compile-time constant
contexts (e.g. as static array sizes).

zw

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[H.J. Lu]

On Tue, Sep 29, 2020 at 7:02 AM Zack Weinberg <zackw@panix.com> wrote:
>
> On Tue, Sep 29, 2020 at 9:27 AM H.J. Lu via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
> > MINSIGSTKSZ and SIGSTKSZ were defined as constant:
> ...
> > I am proposing to make them as dynamic based on AT_MINSIGSTKSZ for
> > -D_GNU_SOURCE:
>
> A quick check of
> https://dcs.zekjur.net/search?q=%5CbMINSIGSTKSZ%5Cb&literal=0 and
> https://dcs.zekjur.net/search?q=%5CbSIGSTKSZ%5Cb&literal=0 gives me
> the impression that this is likely to break a lot of software; these
> constants are often used in #if expressions and compile-time constant
> contexts (e.g. as static array sizes).
>

True.  Some softwares must be updated for this change.   On the other hand,
they may not work correctly on the newer processors in any case and its impact
may be limited by -D_GNU_SOURCE.

-- 
H.J.

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[Andreas Schwab]

On Sep 29 2020, Zack Weinberg wrote:

> A quick check of
> https://dcs.zekjur.net/search?q=%5CbMINSIGSTKSZ%5Cb&literal=0 and
> https://dcs.zekjur.net/search?q=%5CbSIGSTKSZ%5Cb&literal=0 gives me
> the impression that this is likely to break a lot of software; these
> constants are often used in #if expressions and compile-time constant
> contexts (e.g. as static array sizes).

Any uses in preprocessor expressions are bugs though.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[H.J. Lu]

On Tue, Sep 29, 2020 at 7:21 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Sep 29 2020, Zack Weinberg wrote:
>
> > A quick check of
> > https://dcs.zekjur.net/search?q=%5CbMINSIGSTKSZ%5Cb&literal=0 and
> > https://dcs.zekjur.net/search?q=%5CbSIGSTKSZ%5Cb&literal=0 gives me
> > the impression that this is likely to break a lot of software; these
> > constants are often used in #if expressions and compile-time constant
> > contexts (e.g. as static array sizes).
>
> Any uses in preprocessor expressions are bugs though.
>

I put my implementation on users/hjl/AT_MINSIGSTKSZ branch at:

https://gitlab.com/x86-glibc/glibc/-/commits/users/hjl/AT_MINSIGSTKSZ

-- 
H.J.

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[Zack Weinberg]

On Tue, Sep 29, 2020 at 10:21 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Sep 29 2020, Zack Weinberg wrote:
> > A quick check of
> > https://dcs.zekjur.net/search?q=%5CbMINSIGSTKSZ%5Cb&literal=0 and
> > https://dcs.zekjur.net/search?q=%5CbSIGSTKSZ%5Cb&literal=0 gives me
> > the impression that this is likely to break a lot of software; these
> > constants are often used in #if expressions and compile-time constant
> > contexts (e.g. as static array sizes).
>
> Any uses in preprocessor expressions are bugs though.

POSIX does not specifically say that these "symbolic constants" are to
be usable in #if (unlike e.g. INT_MAX) but nonetheless there are a lot
of programs assuming that they are.

zw

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[Paul Eggert]

On 9/29/20 7:10 AM, H.J. Lu via Libc-alpha wrote:
> Some softwares must be updated for this change.   On the other hand,
> they may not work correctly on the newer processors in any case

A lot of software will continue to work if SIGSTKSZ continues to be a constant 
that is "too small" for the architecture. For example, Gnulib lib/c-stack.c does 
the following, and this should be fine on practical platforms with small-stack 
signal handlers:

   static union
   {
     char buffer[SIGSTKSZ];
     max_align_t align;
   } alternate_signal_stack;
   ...
   stack_t st;
   st.ss_flags = 0;
   st.ss_sp = alternate_signal_stack.buffer;
   st.ss_size = sizeof alternate_signal_stack.buffer;
   int r = sigaltstack (&st, NULL);
   if (r != 0)
     return r;

MINSIGSTKSZ is another matter but far less software uses MINSIGSTKSZ, I'd guess.

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[H.J. Lu]

On Tue, Sep 29, 2020 at 1:18 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 9/29/20 7:10 AM, H.J. Lu via Libc-alpha wrote:
> > Some softwares must be updated for this change.   On the other hand,
> > they may not work correctly on the newer processors in any case
>
> A lot of software will continue to work if SIGSTKSZ continues to be a constant
> that is "too small" for the architecture. For example, Gnulib lib/c-stack.c does

Currently, SIGSTKSZ is 8KB.  We will have CPUs which require more than 8KB
signal stake size in the very near future.

> the following, and this should be fine on practical platforms with small-stack
> signal handlers:
>
>    static union
>    {
>      char buffer[SIGSTKSZ];
>      max_align_t align;
>    } alternate_signal_stack;
>    ...
>    stack_t st;
>    st.ss_flags = 0;
>    st.ss_sp = alternate_signal_stack.buffer;
>    st.ss_size = sizeof alternate_signal_stack.buffer;

This should be changed to malloc or mmap now.

>    int r = sigaltstack (&st, NULL);
>    if (r != 0)
>      return r;
>
> MINSIGSTKSZ is another matter but far less software uses MINSIGSTKSZ, I'd guess.



-- 
H.J.

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[Paul Eggert]

On 9/29/20 2:07 PM, H.J. Lu wrote:
> Currently, SIGSTKSZ is 8KB.  We will have CPUs which require more than 8KB
> signal stake size in the very near future.

Then ports for those CPUs should increase SIGSTKSZ to a bigger constant now. 
That will be less work for everyone concerned than changing SIGSTKSZ to a 
non-constant expression, which violates POSIX and breaks too many programs.

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[H.J. Lu]

On Tue, Sep 29, 2020 at 2:42 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 9/29/20 2:07 PM, H.J. Lu wrote:
> > Currently, SIGSTKSZ is 8KB.  We will have CPUs which require more than 8KB
> > signal stake size in the very near future.
>
> Then ports for those CPUs should increase SIGSTKSZ to a bigger constant now.

What value do you have in mind? What if it is not big enough 20 years later?
It still leaves MINSIGSTKSZ unresolved.

> That will be less work for everyone concerned than changing SIGSTKSZ to a
> non-constant expression, which violates POSIX and breaks too many programs.

Constant SIGSTKSZ and MINSIGSTKSZ are from history.   They should be changed.

Linux kernel introduced AT_MINSIGSTKSZ.  It should be used like AT_PAGESZ.

-- 
H.J.

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[Paul Eggert]

On 9/29/20 2:49 PM, H.J. Lu wrote:
> What value do you have in mind?

64*1024

> What if it is not big enough 20 years later?

Then we change it later. We'll have plenty of time.

> Constant SIGSTKSZ and MINSIGSTKSZ are from history.   They should be changed.

Feel free to start the ball rolling at the POSIX level. In the meantime let's 
keep conforming to POSIX, since programs depend on constant SIGSTKSZ now. 
Changing POSIX will give application developers plenty of notice; changing glibc 
now won't do that.

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[H.J. Lu]

On Wed, Sep 30, 2020 at 10:27 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 9/29/20 2:49 PM, H.J. Lu wrote:
> > What value do you have in mind?
>
> 64*1024

So we change both SIGSTKSZ and MINSIGSTKSZ to 64KB.

> > What if it is not big enough 20 years later?
>
> Then we change it later. We'll have plenty of time.
>
> > Constant SIGSTKSZ and MINSIGSTKSZ are from history.   They should be changed.
>
> Feel free to start the ball rolling at the POSIX level. In the meantime let's
> keep conforming to POSIX, since programs depend on constant SIGSTKSZ now.
> Changing POSIX will give application developers plenty of notice; changing glibc
> now won't do that.

We add _SC_RSVD_SIG_STACK_SIZE for signal stack size reserved by the kernel.
Then we deprecate SIGSTKSZ and MINSIGSTKSZ if _SC_RSVD_SIG_STACK_SIZE
is in use.


-- 
H.J.

Re: RFC: Update MINSIGSTKSZ and SIGSTKSZ

[H.J. Lu]

On Wed, Sep 30, 2020 at 1:04 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Wed, Sep 30, 2020 at 10:27 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
> >
> > On 9/29/20 2:49 PM, H.J. Lu wrote:
> > > What value do you have in mind?
> >
> > 64*1024
>
> So we change both SIGSTKSZ and MINSIGSTKSZ to 64KB.
>
> > > What if it is not big enough 20 years later?
> >
> > Then we change it later. We'll have plenty of time.
> >
> > > Constant SIGSTKSZ and MINSIGSTKSZ are from history.   They should be changed.
> >
> > Feel free to start the ball rolling at the POSIX level. In the meantime let's
> > keep conforming to POSIX, since programs depend on constant SIGSTKSZ now.
> > Changing POSIX will give application developers plenty of notice; changing glibc
> > now won't do that.
>
> We add _SC_RSVD_SIG_STACK_SIZE for signal stack size reserved by the kernel.
> Then we deprecate SIGSTKSZ and MINSIGSTKSZ if _SC_RSVD_SIG_STACK_SIZE
> is in use.
>

This isn't the first time for a constant changed to sysconf:

* ARG_MAX is not anymore constant on Linux.  Use sysconf(_SC_ARG_MAX).

We can do

* Add _SC_MINSIGSTKSZ and _SC_SIGSTKSZ.  When _SC_SIGSTKSZ_SOURCE is
  defined, MINSIGSTKSZ and SIGSTKSZ are no longer constant on Linux.
  MINSIGSTKSZ is redefined to sysconf(_SC_MINSIGSTKSZ) and SIGSTKSZ
  is redefined to sysconf (_SC_SIGSTKSZ).

With -D_SC_SIGSTKSZ_SOURCE, compilation will fail if the source assumes
constant MINSIGSTKSZ and SIGSTKSZ.

-- 
H.J.