Chuck Silvers non-executable stack és heap mapping támogatást commitolt a NetBSD-be. A dolog hasonló Molnár Ingo májusban kiadott Exec Shield for Linux/x86 foltjához. Lényege, hogy megpróbál védelmet nyújtani a puffer túlcsordulásból eredő kódfuttatás ellen. A kód az OpenBSD kódja alapján készült.
Bejelentés:Subject: non-executable mappings
To: None
From: Chuck Silvers
List: tech-kern
Date: 08/24/2003 22:34:41
hi folks,
I checked in the support for non-executable mappings that I talked about
a couple months back. many thanks to the openbsd guys for the head-start
on this that I got from their code.
several ports still need work done to support this: amd64 hppa sh5.
of these, I only have the hardware for hppa, but the port is currently
languishing in the pre-LWP era, so it doesn't build. I'm looking into
reviving it, but that will likely take a fair bit of work. if anyone
wants to send me some hardware for either of the others, that would be
fabulous.
for the other ports that are not listed as either working or not-implemented,
the hardware doesn't allow for non-executable mappings. c'est la vie.
there are still a bunch of improvements to be made. right now, several
of the ports (alpha, sparc, maybe others) have the .data ELF section
marked executable, which I believe is due to GOT and PLT issues.
though on the alpha, even static binaries have the .data section
marked executable, so I'm not sure what's going on there. powerpc/oea
can only do non-executable stuff on a segment (ie. 256MB) granularity,
so ideally we'd re-jigger the toolchain and runtime linker to put
all the executable stuff in segment 0 and everything else elsewhere.
openbsd has addressed many of these issues in their tree, but I'd
rather wait until the toolchain upgrade is complete before looking
at any toolchain issues. and really, the toolchain isn't so much
my favorite area, so if someone else wants to continue with that
side of things, that would be great. don't everyone speak up at once...
-Chuck
===========================
From: Chuck Silvers
To: tech-kern@netbsd.org
Subject: non-executable mapping
Date: Sun, 20 Jul 2003 22:03:29 GMT
hi folks,
I've started having a bit of time for netbsd again lately,
so I'm trying to finish incorporating the non-executable-mapping
work from openbsd. the current diff is at:
ftp://ftp.netbsd.org/pub/NetBSD/mis...c/diff.20030720
here's the status of the various pmaps:
working
alpha
i386
powerpc/oea
sparc
sparc64
not implemented
amd64 (I don't have hardware)
hppa (port isn't LWP'd)
powerpc/ibm4xx (-current didn't work on my explora)
sh5 (I don't have hardware)
not possible due to hardware constraints
acorn26 ?
arm32
m68k
mips
ns32k ?
sh3
sun2
sun3
vax
please correct me if I'm wrong about any of the not-possibles.
stuff left to do:
- there's a hack in the sparc pmap that turns pmap_protect() into
pmap_remove() for hypersparcs. if I remove that, I get "level 15"
interrupts while rc is running.
- on some platforms, the linker creates the ELF header for the data segment
with permissions of "rwx" instead of "rw". the ones I wrote down are:
alpha data rwx -- static + dynamic
sparc data rwx -- dynamic
maybe this will magically be fixed with the newer toolchain, let's hope.
- on powerpc/oea, the hardware only does execute permission on a "segment"
granularity, where a segment is 256MB. ideally the linker would arrange
to start the data section at 0x10000000 so that it's in a different
ppc segment than the text. then we can stuff shlib code in segment 0
after the program text and all will be happy.
- on i386, the hardware-walked page tables don't have an executable bit,
so the only efficient way to do execute permission is by adjusting the
segment descriptor used for %cs. in the current diff, there are two
code segments, one that covers the whole user address space (like it is
now), and a new one that doesn't include the stack. the second descriptor
is used as long as the user doens't request any executable mappings in
the stack, but if that happens then the full-address-space segment is used.
one enhancement to this would be to rearrange the address space so that
the usual case is for all the executable mappings to be below some boundary,
then more of the user data, bss and heap could be non-executable.
the openbsd guys did some more work in this area, but I haven't looked
into that yet.
in my opinion, none of these issues are serious enough that they need to be
fixed before this change can be committed (but feel free to make an argument
the other way), so I'm looking for people to try out the diff and let me know
if there are any other issues that need to be addressed before this goes in.
there's a test program "noexec.c" in the same directory (also from openbsd).
-Chuck