Kernel-hardening archive on
 help / color / Atom feed
From: Kees Cook <>
To: Jann Horn <>
Cc: Andrew Morton <>,
	Hector Marco-Gisbert <>,
	Jason Gunthorpe <>,
	kernel list <>,
	the arch/x86 maintainers <>,
	Thomas Gleixner <>,
	Andy Lutomirski <>,
	Kernel Hardening <>,
	Mark Rutland <>,
	linux-arm-kernel <>,, Linux API <>
Subject: Re: [PATCH] binfmt_elf: Update READ_IMPLIES_EXEC logic for modern CPUs
Date: Tue, 23 Apr 2019 12:25:17 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Apr 23, 2019 at 12:02 PM Jann Horn <> wrote:
> It's probably worth going a bit more into detail in this description
> on how libraries typically allocate thread stacks.
> It looks like glibc will be fine; before commit 54ee14b3882
> (;a=blobdiff;f=nptl/allocatestack.c;h=dc501650b8629eda4502f2016016f09106cfb526;hp=6ada1fe1381de104153c0627e27f09fe5ad02caa;hb=54ee14b3882;hpb=16a76cd23ce9d3924fa192395e730423e3dc8b36),
> thread stacks were always RWX, and since then, from what I can tell,
> thread stacks were executable depending on the executable's ELF
> headers (as parsed by glibc).

2003, which seems safely (?) in the past. :)

> But e.g. musl's __pthread_create() seems to hardcode
> PROT_READ|PROT_WRITE, which I think would mean that if someone built a
> multithreaded program with nested functions and linked with musl, that
> program would stop working? Or maybe I'm just reading the code wrong.

Rephrasing for myself: this could break multithread binaries linked
with musl and marked with PT_GNU_STACK to RWE since musl doesn't check
ELF headers to determine stack executable-ness when allocating stack
space in __pthread_create().

> Then again, I'm not sure whether anyone actually uses nested functions...

It is blissfully rare, but it seems common (?) for Fortran binaries.
Are there multithreaded fortran binaries linked with musl that will
break because of this? I guess it's possible. If that happens, we can
adjust the logic with notes of an actual case. :)

Kees Cook

  reply index

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-23 18:12 Kees Cook
2019-04-23 19:02 ` Jann Horn
2019-04-23 19:25   ` Kees Cook [this message]
2019-04-23 19:25   ` [musl] " Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Kernel-hardening archive on

Archives are clonable:
	git clone --mirror kernel-hardening/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernel-hardening kernel-hardening/ \
	public-inbox-index kernel-hardening

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone