[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34
From: |
Bruno Haible |
Subject: |
Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34 |
Date: |
Sun, 23 May 2021 00:59:54 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-210-generic; KDE/5.18.0; x86_64; ; ) |
Hi Paul,
What you are doing now is to deconstruct
- GCC extensions, and
- POSIX.
1) Regarding GCC extensions:
> > malloc'ed memory is not executable. But GCC's trampolines (used by nested
> > functions) require an executable stack. When an object file has such nested
> > functions, the toolchain arranges for the executable to ask the OS to
> > allocate an executable stack. But that only has an effect on the primary
> > stack of each thread. It does not have an effect on an alternate stack
> > (AFAIK).
>
> That should be OK so long as stack-overflow handlers don't used nested
> functions.
Wait a moment. GCC's nested functions are a documented GCC feature [1] for
ca. 30 years. When "security" became an important topic and people demanded
non-executable stacks for web browsers, GCC and the binutils were extended
in such a way that
- on one hand, programs that use GCC nested functions (on most architectures)
got a bit set in the executable, which has the consequence of an
executable stack,
- on the other hand, programs that don't need this — such as web browsers —
can have a non-executable stack.
Now, you are arguing "let's ignore whether programs use nested functions".
As if that wasn't a documented way, in the GNU system, of writing programs.??
> > I wouldn't mind, if it's done properly:
> > - The problem with non-executable malloc'ed memory would need to be
> > solved.
>
> Or, we could just document that stack-overflow handers can't use
> trampolines. That is a reasonable restriction for most apps, I would think.
It adds complexity to the calling program. The developer has to check whether
their code uses nested functions.
2) Regarding POSIX:
> The only place I found that assumed that SIGSTKSZ is a constant, was in
> Gnulib test cases. I removed that assumption by installing the first
> attached patch.
By doing so, you moved the Gnulib code away from POSIX. In so many occasions,
you voted for making Gnulib closer to POSIX, and that is a significant
reason why Gnulib is successful.
Here,
- The current POSIX specifies a constant SIGSTKSZ,
- Eric Blake is proposing that POSIX drops the constant-ness, and that
SIGSTKSZ becomes a macro that merely expands to an expression. [2]
So, being close to POSIX would mean to use SIGSTKSZ for the allocation
of an alternate stack, most likely through malloc.
Whereas your patch removes all traces of SIGSTKSZ and hardcodes a constant
(1 << 24) in various places instead.
The point of your patch appears to be to proactively react to other systems
(FreeBSD, Solaris, etc.) to follow glibc's move and make SIGSTKSZ non-
constant. But then, still, it would have been more maintainable to write
/* SIGSTKSZ can no longer be guaranteed to be a constant. Until POSIX
clarifies it, use a large constant anyway. */
#undef SIGSTKSZ
#define SIGSTKSZ (1 << 24)
3) The approach you used now, to use a 16 MB space for sigaltstack(),
is not portable to multithreaded situations. For example, I have a test
program (attached) that I consider to add as a unit test to gnulib.
It uses stack space from the thread itself as alternate signal stack.
That is a perfectly natural thing to do, because
- the permissions of the alternate stack are automatically right,
- this alternate stack gets deallocated automatically when the thread
dies (no memory leak).
But allocating 16 MB on a thread's stack is not portable. On Solaris/SPARC,
the main thread's size is only 8 MB.
Really, my goals here are that the unit tests in Gnulib
- use POSIX the best they can,
- give a coding pattern that people can use in their applications,
be they single-threaded or multi-threaded, and interoperable with
whatever GCC extensions the programmer wants.
Bruno
[1] https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Nested-Functions.html
[2] https://sourceware.org/pipermail/libc-alpha/2021-March/123553.html
sigaltstack-per-thread.c
Description: Text Data
- sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Bruno Haible, 2021/05/16
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Paul Eggert, 2021/05/16
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Bruno Haible, 2021/05/18
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Paul Eggert, 2021/05/21
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34,
Bruno Haible <=
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Paul Eggert, 2021/05/23
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Bruno Haible, 2021/05/23
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Paul Eggert, 2021/05/23
- Re: sigsegv, c-stack: Avoid compilation error with glibc >= 2.34, Bruno Haible, 2021/05/24
- Re: sigsegv.h interface, Bruno Haible, 2021/05/22
- Re: sigsegv.h interface, Paul Eggert, 2021/05/23