Index | Thread | Search

From:
Daniel Dickman <didickman@gmail.com>
Subject:
Re: lang/polyml: fix (stupid because needless) W^X violation
To:
Daniel Dickman <didickman@gmail.com>, ports@openbsd.org
Date:
Tue, 15 Jul 2025 20:51:20 -0400

Download raw body.

Thread

On Wed, 16 Jul 2025, Stuart Henderson wrote:

> On 2025/07/15 19:35, Daniel Dickman wrote:
> > Should ports not even try to do a runtime check in the first place?
> 
> I think these runtime checks are mainly for OS where the binary might
> be compiled on a system with no W^X protection and then run on a system
> with a kernel which enforces it (as long as it wasn't opted-out for the
> binary..) and they don't seem to make much sense for OpenBSD to me.
> 
> On OpenBSD the possibilities (where a program deliberately tries to
> make a W+X mapping and checks the return code like this) are:
> 
> - port forces W+X to be permitted (USE_WXNEEDED); binary run from
>   wxallowed partition: test will succeed, program uses W+X and runs
> 
> - port forces W+X to be permitted (USE_WXNEEDED); binary run from
>   !wxallowed partition: test will fail, program avoids W+X and runs
> 
> - port leaves W^X protection enabled; run with kern.wxabort=0; test
>   will fail, program avoids W+X and runs
> 
> - port leaves W^X protection enabled; run with kern.wxabort=1; crash
> 

I don't agree.

I could be wrong but I suspect most ports have support for only one 
code-path not both. So it makes sense to use USE_WXNEEDED in those 
other cases.

But this port includes support for running under either codepath:
- W^X enabled
- W^X disabled

The user's policy is detected at runtime and then the appropriate code 
path is used.

Now we could hard-code this for PolyML at compile time and insist that all 
PolyML users must ONLY run the W^X enabled code-path, even if they do not 
have W^X set system-wide, but this seems like an odd choice so long as W^X 
is not mandatory on OpenBSD.

> For a port which does not set USE_WXNEEDED 

We shouldn't set USE_WXNEEDED because we don't know until runtime what the 
user's policy is.

> then avoiding the runtime
> check gives the most useful behaviour under both possibilities.

Avoiding the runtime check simply hard-codes one of the 2 supported code 
paths.

Again, this is fine if we think that when a port supports both paths, we 
should force the W^X path and not give the user an option.

I'll leave it to others to make a call on this because it's not really 
something I care too much about. I'll only be running the port with W^X 
enabled (which the current port correctly checks at run-time and goes down 
the appropriate code path).