|
From: Julian S. <js...@ac...> - 2005-10-09 02:40:48
|
Am just playing with V (svn trunk) on SuSE 10.0, and I get failures from the sync checker with --sanity-level=3. It looks like all segments listed in /proc/self/maps have x permission regardless. A section from "cat /proc/self/maps" says (skipping inode/dev and offset): 4001e000-4001f000 r-xp /usr/lib/locale/en_GB.utf8/LC_MEASUREMENT 4001f000-40020000 r-xp /usr/lib/locale/en_GB.utf8/LC_TELEPHONE 40020000-40021000 r-xp /usr/lib/locale/en_GB.utf8/LC_ADDRESS whereas on SuSE 9.2 they are r--p as you'd expect. On SuSE 10.0 the only sections listed as not having x are [stack] and [vdso]. The only thing that might be strange is that they are both running on VMware Workstation 5, although that seems unlikely. Can anyone with SuSE 10.0 on real hardware check this? This is screwing up the new address space manager's sync checker because it maps in the client's data sections as rw- (also the interpreter's) as they request, but when it compares against /proc/self/maps it sees rwx. J |
|
From: Josef W. <Jos...@gm...> - 2005-10-09 11:20:19
|
On Sunday 09 October 2005 04:40, Julian Seward wrote: > 4001e000-4001f000 r-xp /usr/lib/locale/en_GB.utf8/LC_MEASUREMENT > 4001f000-40020000 r-xp /usr/lib/locale/en_GB.utf8/LC_TELEPHONE > 40020000-40021000 r-xp /usr/lib/locale/en_GB.utf8/LC_ADDRESS > > ... > > Can anyone with SuSE 10.0 on real hardware check this? Happens on real hardware here, too :-( Above segments (LC_*) are only mapped with PROT_READ, but show up with x in /proc/*/maps. I did not investigate further. Time for a bug report? Josef |
Julian Seward wrote: > It looks like all segments listed in /proc/self/maps have x > permission regardless. SuSE isn't the only one. Fedora Core 4 also has this on x86, and maintainers think that this is good: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160889#c3 I haven't tracked it down all the way, but my guess is that as long as the page is within the limit of the %cs segment, then I'll see 'x' in /proc/pid/maps. In other words, if there is an executable page at any higher address, then all lower pages will see 'x', regardless of requested permissions. Supposedly this is "closer to reality" on any machine that does not have the NX permission feature, than omitting the 'x' from the report if you asked for "rw-p". Observe this program carefully. The page at 0x100000 (1MB) gets reported as "--xp" because there are executable pages at higher addresses (including 0x08048000, the default start of .text.) Jumping to the page gives a SIGSEGV on the 1st instruction because 0x100000: add %al,(%eax) %eax [0x100000] does not have Read or Write permission. ----- #include <sys/types.h> #include <sys/mman.h> main() { char *vaddr= mmap(0x100000, 4096, PROT_NONE, MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE, 0,0); ((void (*)(void))vaddr)(); return 0; } ----- Asking for ~MAP_FIXED at 0x0 gives a page above the limit of %cs, [0xb7f08000 on Fedora Core 4] so that page is reported as "---p", and the SIGSEGV happens one instruction earlier, on the CALL itself: 0x80483b8 <main+60>: call *%eax because the address is beyond the limit of %cs. -- |
|
From: Julian S. <js...@ac...> - 2005-10-10 11:57:35
|
> SuSE isn't the only one. Fedora Core 4 also has this on x86, > and maintainers think that this is good: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160889#c3 Then it looks like the sync checker will have to ignore 'x' on the basis that semantics are unreliable and don't match what you ask for in mmap. Thanks for digging that up. Let us know if they make any further changes. J |
|
From: Ashley P. <as...@qu...> - 2005-10-10 12:04:01
|
On Mon, 2005-10-10 at 12:59 +0100, Julian Seward wrote: > > SuSE isn't the only one. Fedora Core 4 also has this on x86, > > and maintainers think that this is good: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160889#c3 > > Then it looks like the sync checker will have to ignore 'x' on > the basis that semantics are unreliable and don't match what > you ask for in mmap. Thanks for digging that up. Let us know > if they make any further changes. I have seen machines where the address are all set to zero as well, again a redhat security feature... I don't know if you've seen it but I'll try and remember which machine it was if you like. Ashley, |
|
From: Julian S. <js...@ac...> - 2005-10-10 12:35:35
|
> I have seen machines where the address are all set to zero as well, > again a redhat security feature... I don't know if you've seen it but > I'll try and remember which machine it was if you like. Interesting. LMK if you have any more details. I can't see how V could ever work in such an arrangement since this would make it impossible to even establish the initial memory layout. J |
|
From: Tom H. <to...@co...> - 2005-10-10 12:05:35
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> SuSE isn't the only one. Fedora Core 4 also has this on x86,
>> and maintainers think that this is good:
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160889#c3
>
> Then it looks like the sync checker will have to ignore 'x' on
> the basis that semantics are unreliable and don't match what
> you ask for in mmap. Thanks for digging that up. Let us know
> if they make any further changes.
Only on x86 though - ppc32 has proper X support and all amd64
processors should have NX and hence proper X support.
It is only pre-NX bit 32 bit x86 processors that have the problem
by the sounds of it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-10-10 12:25:59
|
> Only on x86 though - ppc32 has proper X support and all amd64 > processors should have NX and hence proper X support. > > It is only pre-NX bit 32 bit x86 processors that have the problem > by the sounds of it. Yes. So (sorry, should have said this) only for x86. I guess that means adding a #if defined(VGA_x86) style hack to the sync checker. J |
|
From: Josef W. <Jos...@gm...> - 2005-10-10 13:44:37
|
On Monday 10 October 2005 14:27, Julian Seward wrote: > > Only on x86 though - ppc32 has proper X support and all amd64 > > processors should have NX and hence proper X support. > > > > It is only pre-NX bit 32 bit x86 processors that have the problem > > by the sounds of it. Obviously any x86 without active PAE mode has this problem. In the standard i386 page table entry layout there is no place for an execute-bit. I wonder why the semantic of /proc/*/maps was changed. Perhaps to be able to check if the hardware can enforce no-execute on a given segment... Josef |
|
From: Julian S. <js...@ac...> - 2005-10-11 22:10:02
|
> > > Only on x86 though - ppc32 has proper X support and all amd64 > > > processors should have NX and hence proper X support. > > > > > > It is only pre-NX bit 32 bit x86 processors that have the problem > > > by the sounds of it. I committed a suitable kludge in r4901. J |