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

[Emil Velikov]

On 8 September 2016 at 19:46, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>> 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.
>
Fwiw I'm for upstreaming things where they don't seem too hacky. When
they do I try to elaborate why and how they could be addressed.

Here... thinking about the mmap solution (workaround?) I'm wondering
if it isn't the better option. Using it one won't need to patch X
projects and at the same time everyone should handle mmap() failure.
If they don't then that's a bug which should be fixed regardless of
anything else.

>> > --- 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.
>
Ack, looking forward to it. Hope that if there's problems on mesa
side, he'll shout early as he finds them.

>> 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.
>
Things are slightly overloaded, but the gist is that the TLS/ASM
codepaths constructs a jump table(?) which is used instead of calls
into the respective GL functions.

Linux has been explicitly using only the TLS codepath for 3+ years (if
not a lot more), with the only obstacle for keeping the other two
codepaths being BSD and maybe Solaris.
To make it even better the code (all three codepaths) has close to
zero fixes/updates since it was introduced and is quite dense.

>> 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.
Yes even though I'm not a security person, I'm aware that using W|X is
a bad idea.
The key point imho is that a) there must always be a contingency plan,
which involves toggling off and/or other methods that you've mentioned
and b) considering the limited amount of devs/interest in the area it
will take a while to untangle things.

> Please note that we're not alone here.  iOS for example
> does not allow you to create mappings like that either.
>
I see your point about iOS and/or other platforms using such policy
and I'm not against it. Merely pointing out be lots of divergent,
nasty code vs shortage of interest/manpower to address it.

Thanks
Emil