OpenBSD Journal

Testing wanted: execute-only on amd64

Contributed by rueda on from the I-can't-read-code dept.

On the tech@ mailing list, Theo de Raadt (deraadt@) has issued a request for testing of patch(es) for execute-only (xonly) binaries on amd64. The message is quite long, but well worth reading in its entirety for those interested. Selected highlights include:

Some of you have probably noticed activity about "xonly" happening
to a bunch of architectures.  First arm64, then riscv64, then hppa,
and ongoing efforts with octeon, sparc64 (sun4u only), and more of this
is going to come in the future.

Like past work decades ago (and I suppose continually also) on W^X, and
increasing use of c, the idea here is to have code (text segments)
not be readable.  Or in a more generic sense, if you mprotect a region
with only PROT_EXEC, it is not readable.

But most of us have amd64 machines.  Thrilling news:
It turns out we can do this fairly modern modern 64-bit x86 machines
from Intel and AMD, if operating in LONG mode, aka. amd64.  The cpu
needs to have a feature called PKU.  The way this works is not 100%
perfect, but it a serious enough hinderance.

As I mention, some other architectures have crossed already, but not
without little bits of pain.  Especially in the ports tree, where
unprepared code is more common.  Mostly this consists of assembly language
files that have put read-only data into the .text region, instead of into
the .rodata (some people still haven't read the memos from around 1997).

So I'd like to recruit some help from those of you capable of building
your own kernels.  Can you apply the following kernel diff, and try the
applications you are used to.  A list of applications that fail on some
way would be handy.  Be sure to ktrace -di then, and check there is a
SIGSEGV near the end, and include a snippet of that information.

If you don't know how to do this, please don't ask for help.  Just let
others do it.

The kernel diff isn't perfect yet, because it is less than 24 hours
since this started working.  But it appears good enough for testing,
while we work out the wrinkles.

So, if in a position to do so, please do as Theo asks and help usher in the execute-only future!

(Comments are closed)


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]