On 10/20/10 21:42, Richard L. Hamilton wrote:
While I still like the idea of a runtime function (new syscall
or extension to mprotect()) to control default stack or heap
permissions (mainly for use with a preloadable shared object
to apply to existing binaries that don't have a spare program
head
> On 10/20/10 3:39 AM, casper@sun.com wrote:
> >
> >
> >> I had a few minutes today to try an
> experiment, and I'm afraid
> >> the idea of having ld always generate a
> PT_SUNWSTACK is a non-starter.
> >>
> >> The problem is that it overrides the behavior of
> 'set noexec_user_stack=1'
> >
On 10/20/10 3:39 AM, casper@sun.com wrote:
I had a few minutes today to try an experiment, and I'm afraid
the idea of having ld always generate a PT_SUNWSTACK is a non-starter.
The problem is that it overrides the behavior of 'set noexec_user_stack=1'
in /etc/system, and can therefore
In that case, let me revise my earlier proposal:
ADDR_HEAP would apply to the entire heap, current and future.
ADDR_STACK would alter future behavior (both for main stack and
by invalidating stackprot as previously mentioned, for thread stacks),
but for the sake of gcc trampolines and the complex
>Looks to me like
>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/thr.c
>
>checks sysconf(_SC_STACK_PROT) and honors it. The only problem is
>that it caches the return value (static variable stackprot), which
>would have to be invalidated by the mprotect() wr
>
>
> >Which does the PT_SUNWSTACK header apply to?
>
> It sets the fields in the proc structure which
> defines the stack
> protection.
>
> >I'm not sure what point there would be in per-thread
> >control; if any one thread in an address space is
> exploitable,
> >the whole address space is p
>Which does the PT_SUNWSTACK header apply to?
It sets the fields in the proc structure which defines the stack
protection.
>I'm not sure what point there would be in per-thread
>control; if any one thread in an address space is exploitable,
>the whole address space is potentially corruptible.
>
>
> >I picture this somehow as being just a bit more
> functionality added to mprotect(2):
> >
> >/* following magic to identify operating on that
> segment, rather than
> > * a particular address
> > */
> >#define ADDR_STACK (void *) (-1)
> >#define ADDR_HEAP (void *) (-2)
> >
> >mprotect(ADDR
>How does the trampoline work on architectures which have noexec bit
>for stack by default, like sparcv9?
A long time ago, I made some changes to gcc; I'm not sure if the changes
are still in current gcc, but what happens is that we run mprotect() on
the parts of the stack where we need to exec
How does the trampoline work on architectures which have noexec bit
for stack by default, like sparcv9?
Olga
On Wed, Oct 20, 2010 at 2:26 PM, wrote:
>
>
>>I picture this somehow as being just a bit more functionality added to
>>mprotect(2):
>>
>>/* following magic to identify operating on that
>I picture this somehow as being just a bit more functionality added to
>mprotect(2):
>
>/* following magic to identify operating on that segment, rather than
> * a particular address
> */
>#define ADDR_STACK (void *) (-1)
>#define ADDR_HEAP (void *) (-2)
>
>mprotect(ADDR_STACK, 0, (PROT_READ|PR
>
>
> >I had a few minutes today to try an experiment,
> and I'm afraid
> >the idea of having ld always generate a PT_SUNWSTACK
> is a non-starter.
> >
> >The problem is that it overrides the behavior of
> 'set noexec_user_stack=1'
> >in /etc/system, and can therefore quietly allow
> programs
>I had a few minutes today to try an experiment, and I'm afraid
>the idea of having ld always generate a PT_SUNWSTACK is a non-starter.
>
>The problem is that it overrides the behavior of 'set noexec_user_stack=1'
>in /etc/system, and can therefore quietly allow programs that would
>not previ
> On 10/17/10 10:01, Ali Bahrami wrote:
[...]
> Until there's a consensus that Solaris should ignore
> the platform ABI,
> I think we're back to the original assertion that the
> best you can do is
> to always link with -M /usr/lib/ld/map.noexstk, and
> to set noexec_user_stack.
>
> Since executab
On 10/17/10 10:01, Ali Bahrami wrote:
I've had the same thought about having ld always generate
a PT_SUNWSTACK, and even sent some internal email yesterday
proposing it to my fellow linker alien. It's actually simpler
than what we do now, since we'd just remove the code that
checks the header fla
On 10/17/10 4:58 AM, Richard L. Hamilton wrote:
While it doesn't help existing binaries, would it be possible
to for new 32-bit binaries persuade the linker to issue a
redundant (same as ABI) PT_SUNWSTACK header? That I
suppose elfedit _would_ be able to change after-the-fact.
I gather one coul
While it doesn't help existing binaries, would it be possible
to for new 32-bit binaries persuade the linker to issue a
redundant (same as ABI) PT_SUNWSTACK header? That I
suppose elfedit _would_ be able to change after-the-fact.
I gather one could do it indirectly, by linking with -M /usr/lib/ld
On 10/16/10 08:54 AM, Richard L. Hamilton wrote:
Doesn't help with existing binaries, but it's good to know for
when one can re-link. If there's a way to construct an
LD_PRELOAD'able shared object to do the trick for existing
binaries, I don't see how given the description of mprotect(2),
to spe
>Thanks for the info.
>
>Doesn't help with existing binaries, but it's good to know for
>when one can re-link. If there's a way to construct an
>LD_PRELOAD'able shared object to do the trick for existing
>binaries, I don't see how given the description of mprotect(2),
>to specify the entire pres
>
> >ppgsz(1) or mpss.so.1(1) can set preferred page size
> for
> >existing (ppgsz) or new (both) processes.
> >
> >Is there anything that can similarly remove execute
> permission
> >from the stack of 32-bit processes, without do so on
> a system-wide
> >basis (i.e. without putting set noexec_use
>ppgsz(1) or mpss.so.1(1) can set preferred page size for
>existing (ppgsz) or new (both) processes.
>
>Is there anything that can similarly remove execute permission
>from the stack of 32-bit processes, without do so on a system-wide
>basis (i.e. without putting set noexec_user_stack=1 in /etc/s
ppgsz(1) or mpss.so.1(1) can set preferred page size for
existing (ppgsz) or new (both) processes.
Is there anything that can similarly remove execute permission
from the stack of 32-bit processes, without do so on a system-wide
basis (i.e. without putting set noexec_user_stack=1 in /etc/system)?
22 matches
Mail list logo
