atom feed20 messages in org.freebsd.freebsd-archRe: Time to make the stack non-execut...
FromSent OnAttachments
Terry LambertJun 29, 2002 3:13 pm 
Jake BurkholderJun 29, 2002 3:55 pm 
Alfred PerlsteinJun 29, 2002 4:08 pm 
Julian ElischerJun 29, 2002 4:14 pm 
Jake BurkholderJun 29, 2002 4:24 pm 
Bill HueyJun 29, 2002 4:25 pm 
Terry LambertJun 29, 2002 5:50 pm 
Bill HueyJun 29, 2002 6:18 pm 
David O'BrienJun 29, 2002 7:39 pm 
Bakul ShahJun 29, 2002 10:40 pm 
Arun SharmaJun 29, 2002 11:31 pm 
Peter WemmJun 29, 2002 11:59 pm 
Igor SysoevJun 30, 2002 2:49 am 
Terry LambertJun 30, 2002 3:24 am 
Terry LambertJun 30, 2002 3:38 am 
Eivind EklundJun 30, 2002 3:44 am 
Terry LambertJun 30, 2002 4:39 am 
Cedric BergerJun 30, 2002 5:14 am 
Terry LambertJun 30, 2002 5:24 am 
Peter WemmJun 30, 2002 1:42 pm 
Subject:Re: Time to make the stack non-executable?
From:Jake Burkholder (ja@locore.ca)
Date:Jun 29, 2002 4:24:17 pm
List:org.freebsd.freebsd-arch

Apparently, On Sat, Jun 29, 2002 at 04:09:18PM -0700, Alfred Perlstein said words to the effect of;

* Jake Burkholder <ja@locore.ca> [020629 15:51] wrote:

For signals, this is easy: copy SVR4, and modify the signal functions to pass in a return address, then disable the execute bits on stack pages and see whose head blows up.

Frankly, I'm very surprised to discover that OpenBSD has not already done this.

Opinions? Patches from people who know and love the signals facility on Alpha, SPARC64, PPC, etc.?

The sparc64 signal trampoline is already in libc, I'm running a kernel which maps the stack non-executable locally.

I recently (last week or two) forwarded a cvs commitlog from NetBSD which seems to have solved this.

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=462972+0+archive/2002/freebsd-arch/20020623.freebsd-arch

Have you guys had a look? Sorry if this is red herring, I haven't investigated it deeply.

Yes, I looked at it. Its mostly about standardizing the naming of the userland trampoline to include the type of the arguments it expects, sigcontext or ucontext, and a version number. It doesn't say much about how the address of the trampoline would be passed to the kernel, which is more important. I just used a sysarch call in crt0, which could be optimized to be done just before the first call to sigaction.

FWIW, the netbsd scheduler activations upcall trampoline is copied out to the stack with the signal code (kse doesn't use the same kind of upcall trampoline), which I expect is their motivation for changes.

Jake

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message