JIT breaks on feather3
Geoffrey Broadwell
geoff at broadwell.org
Wed Dec 3 15:54:43 UTC 2008
On Wed, 2008-12-03 at 06:40 -0800, Mark Glines wrote:
> chromatic wrote:
> > On Tuesday 02 December 2008 22:27:15 Mark Glines wrote:
> >
> >> Kevin mentioned that parrot is using mprotect() to explicitly ask glibc
> >> to make this memory executable. Since it isn't, that possibly makes
> >> this a glibc bug. Either way, this seems like the sort of issue which
> >> would keep cropping up in weird ways, unless we could detect/prevent it
> >> somehow.
> >>
> >> So, List, does anyone happen to know why processes under screen have
> >> non-executable stacks? Or possibly a bash shopt or ulimit or dropped
> >> privilege or somesuch?
> >
> > SELinux or GCC stack protection might also do this (though I'm not *sure* of
> > the latter).
>
> Yeah, that would make sense. This is the heap, not the stack, but the
> same issues and motivations would apply.
>
> The weird thing is how selective it is. GCC stack protection should
> affect all binaries compiled with that version of GCC, but here, the
> same binary behaves in different ways depending on whether you run it
> from within screen. That sounds crazy to me.
Perhaps some security option is being set based on not having a "real"
tty?
> So it seems like something environmental. And I did tweak %ENV so they
> were as close to identical as possible, basically everything except
> $ENV{PPID} (which is readonly for bash). That had no effect.
>
> If it helps, feather3 is a virtual machine running Debian lenny/sid,
> kernel 2.6.18-6-xen-686, and libc6 version 2.7-15.
That's a pretty old kernel (from the previous stable release). My
Debian lenny/sid system reports a 2.6.26 kernel, and according to
apt-cache linux-image-2.6-xen-686 is up to 2.6.26+16. I'm not sure it
makes a big difference, but Xen is developed fairly rapidly so there
might be fixes to memory protection bits in between 2.6.18 and 2.6.26.
-'f
More information about the parrot-dev
mailing list