|
From: Tom H. <to...@co...> - 2005-11-17 12:25:33
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> In that case should we make this code:
>>
>> /* We make the data segment (heap) executable because LinuxThreads on
>> ppc32 creates trampolines in this area. */
>> sres = VG_(am_mmap_anon_fixed_client)(
>> anon_start,
>> anon_size,
>> VKI_PROT_READ|VKI_PROT_WRITE|VKI_PROT_EXEC
>> );
>>
>> only set EXEC for ppc32, using a "#if defined(ppc32)"?
>
> Well, the thing is, I'm not sure why it didn't screw up LinuxThreads
> on x86 (I tried that too). It's kind-of hard to argue that ppc32 and
> x86 LinuxThreads have the stack of their manager thread in totally
> different places. I did notice that the order in which signals were
> delivered was different running the same ultra-trivial threaded test
> on both x86 and ppc32 running SuSE10 with LD_ASSUME_KERNEL=2.2.19.
Maybe LinuxThreads on x86 doesn't have the manager thread stack in
the heap or maybe nobody has tried it since I took away the exec
permission a few weeks ago.
Most x86 processors won't be policing exec properly anyway so you
still might get away with it.
> However .. the clinchers are that (1) even on x86, the data seg is
> rwx natively, at least according to cat /proc/self/maps, and (2)
> having a non-executable data seg would kill any program which tried
> to create code in the data seg and then run it. So I'd say it should
> be rwx on all platforms.
Like I said my x86 boxes don't have it executable, although that
can be open to variation due to x86 exec flag wierdness. My amd64
boxes certainly don't have it executable.
Killing programs that put executable code in the heap/stack is of
course exactly what operating systems are trying to do these days
in the name of security.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|