bug-gnulib
[Top][All Lists]
Advanced

[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: Tue, 18 May 2021 19:34:18 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-206-generic; KDE/5.18.0; x86_64; ; )

Hi Paul,

> > (Additionally, if we were to use malloc() as a replacement, watch out
> > that malloc()ed memory may not be executable, but some programs need
> > an executable stack.)
> 
> That shouldn't be a problem on GNU platforms, since it's documented that 
> you can malloc the alternate signal stack. If it does turn into a 
> problem, I suppose we can assume that when SIGSTKSZ is not a constant 
> that malloc should work

That's the theory. Here is how it really is:

On
  Linux/alpha,
  FreeBSD/i386,
  NetBSD/i386,
  macOS/i386,
  macOS/powerpc,
  Solaris 10/i386,
  Solaris 10/sparc
  Cygwin/i386,
  Minix/i386,
  Windows/i386 (mingw)
malloc'ed memory is executable.

On
  Linux/arm,
  Linux/arm64,
  Linux/i386,
  Linux/m68k,
  Linux/mips,
  Linux/powerpc,
  Linux/powerpc64le,
  Linux/s390,
  Linux/s390x,
  Linux/sparc,
  Linux/x86_64,
  Hurd/i386,
  FreeBSD/x86_64,
  DragonFly/i386,
  NetBSD/sparc,
  NetBSD/x86_64,
  OpenBSD/i386,
  OpenBSD/x86_64,
  macOS/x86_64,
  IRIX/mips,
  Solaris 10/x86_64,
  Cygwin/x86_64,
  Windows/x86_64 (mingw),
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).

On
  Linux/hppa,
  Linux/powerpc64,
  Linux/ia64,
  AIX,
  HP-UX,
it is irrelevant whether malloc'ed memory is executable, because GCC's
trampolines are built without executable code.

> (otherwise how could you ever create an alternate signal stack?).

You could call malloc() and then mprotect(rwx) on it. This would work
on some of the platforms above, namely:
  Hurd/i386,
  FreeBSD/x86_64,
  DragonFly/i386,
  NetBSD/sparc,
  NetBSD/x86_64,
  OpenBSD/i386,
  OpenBSD/x86_64,
  macOS/x86_64,
  IRIX/mips,
  Solaris 10/x86_64,
  Cygwin/x86_64,
It would not work on
  Linux (with SELinux),
  FreeBSD (hardened via kern.elf32.allow_wx=0, kern.elf64.allow_wx=0),
  macOS 11.

> > I don't have time to rewrite all these unit tests and autoconf tests.
> 
> Can we assume you wouldn't mind if someone did take the time? (Not that 
> I'm volunteering right just now.)

I wouldn't mind, if it's done properly:
  - The problem with non-executable malloc'ed memory would need to be
    solved.
  - The declaration in sigsegv.h needs to stay, at least for the next
    couple of years, because it is necessary for programs that use SIGSTKSZ
    (such as GNU m4 and GNU clisp) to compile fine.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]