[Mesa-stable] [Mesa-dev] [PATCH] Disable the code that allocates W|X memory on OpenBSD

[Mark Kettenis]

> From: Emil Velikov <emil.l.velikov at gmail.com>
> Date: Thu, 8 Sep 2016 18:57:44 +0100
> 
> On 1 September 2016 at 18:23, Jonathan Gray <jsg at jsg.id.au> wrote:
> > OpenBSD now has strict W^X enforcement.  Processes that violate
> > the policy get killed by the kernel.  Don't attempt to use
> > executable memory on OpenBSD to avoid this.
> >
> > Patch from Mark Kettenis.

Jonathan, Emil,

That diff should probably not land "upstream".  We're still tweaking
the W^X policy, trying to find the code in ports that violates W^X.
We recently changed things around such that

    mmap(..., PROT_WRITE | PROT_EXEC)

will simply fail instead of aborting the process.  Since Mesa has
fallback code for that case, the changes I made (at least most of
them) are no longer necessary.  But I didn't revert them yet in order
to reduce the amount of false positives.

> > --- a/src/gallium/auxiliary/rtasm/rtasm_execmem.c
> > +++ b/src/gallium/auxiliary/rtasm/rtasm_execmem.c
> > @@ -69,6 +69,16 @@ static struct mem_block *exec_heap = NULL;
> >  static unsigned char *exec_mem = NULL;
> >
> >
> > +#ifdef __OpenBSD__
> > +
> > +static int
> > +init_heap(void)
> > +{
> > +   return 0;
> > +}
> Afaict this is equivalent to using the #else path in translate_see.c.
> In general I'm wondering if we can/should not have a configure toggle
> for this. Then again please look below.

Right.  We basically prefer the slow code paths over the unsecure
codepaths.  There are ways around W^X enforcement though.  One
possibility is to generate the code in pages that are writable, but
not executable, and then flip the permissions to make the page
read-only but executable.  Other techniques include using aliased
pages where one mapping is writable and the other mapping is
executable.  Although we don't really want to encourage using aliasing
since it is a bit of a cheat.

> > --- a/src/mapi/u_execmem.c
> > +++ b/src/mapi/u_execmem.c
> > @@ -45,8 +45,15 @@ static unsigned int head = 0;
> >
> >  static unsigned char *exec_mem = (unsigned char *)0;
> >
> > +#if defined(__OpenBSD__)
> >
> > -#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || defined(__sun) || defined(__HAIKU__)
> > +static int
> > +init_map(void)
> > +{
> > +  return 0;
> > +}
> > +
> And this one to --disable-glx-tls and/or --disable-asm. Which reminds
> me of - have you guys tried enabling either/both of them. Has there
> been (m)any issues ?

Pilip Guenther is working on enabling TLS support in OpenBSD.  He is
getting close, but he was grumbling that Mesa was uncovering some
toolchain bugs.

> For a long while the intent has been to use --enable-glx-tls by
> default and kill off the other codepaths. But with the write xor
> execute policy, it's going to be (close to) impossible.

Not entirely sure what TLS has to do with W^X enforcement.

> Have you guys considered a way to disable the restriction for usecases
> that need the behaviour ?

"no comment", erh, yes, there is a way.  But not for what we consider
the base of our OS.  Which includes X.  Mapping pages to be both
writable and executable is really bad from a security perspective.
And the goal is to eliminate that practice completely from the
ecosystem.  Please note that we're not alone here.  iOS for example
does not allow you to create mappings like that either.

Cheers,

Mark