lkml.org 
[lkml]   [2004]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [LTP] Re: Recent changes in LTP test results
From
Date
On Fri, 2004-07-09 at 23:45, Andrew Morton wrote:

> Here's mine, with current -linus bk:
>
> 40000000-40001000 ---p 40000000 00:00 0
>
> > So it looks like the page being executable allows read
> > access.
> >
> > Not sure why you do not see this on your machine. This
> > fails on my 2-proc xeon box (and all the STP machines).
> >
>
>
> #include <unistd.h>
> #include <errno.h>
> #include <sys/mman.h>
>
>
> main()
> {
> char *p0 = 0;
> char *p1 = (char *)-1;
> char *p2;
> int err;
>
> p2 = mmap(0, 4096, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
>
> printf("p2=%p\n", p2);
> printf("pid=%d\n", getpid());
>
> getchar();
>
> errno = 0;
> err = access(p0, R_OK);
> printf("access 0 ptr %p return code %d errno %d\n", p0, err, errno);
> perror("access result:");
> errno = 0;
> err = access(p1, R_OK);
> printf("access 1 ptr %p return code %d errno %d\n", p1, err, errno);
> perror("access result:");
> errno = 0;
> err = access(p2, R_OK);
> printf("access 2 ptr %p return code %d errno %d\n", p2, err, errno);
> perror("access result:");
> }
>
> vmm:/home/akpm> ./x
> p2=0x40000000
> pid=2038
>
> access 0 ptr (nil) return code -1 errno 14
> access result:: Bad address
> access 1 ptr 0xffffffff return code -1 errno 14
> access result:: Bad address
> access 2 ptr 0x40000000 return code -1 errno 14
> access result:: Bad address
>
> I get this result on both p4 xeon and p3 xeon.


Andrew,

It is the elf file that makes the difference. I was using
gcc 3.2.2 and ld (GNU ld version 2.13.90.0.18 20030206).
This produces elf binary without the PT_GNU_STACK program
section (from objdump -p x.gcc322)

Program Header:
PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2
filesz 0x000000c0 memsz 0x000000c0 flags r-x
INTERP off 0x000000f4 vaddr 0x080480f4 paddr 0x080480f4 align 2**0
filesz 0x00000013 memsz 0x00000013 flags r--
LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
filesz 0x00000750 memsz 0x00000750 flags r-x
LOAD off 0x00000750 vaddr 0x08049750 paddr 0x08049750 align 2**12
filesz 0x00000118 memsz 0x0000011c flags rw-
DYNAMIC off 0x0000075c vaddr 0x0804975c paddr 0x0804975c align 2**2
filesz 0x000000c8 memsz 0x000000c8 flags rw-
NOTE off 0x00000108 vaddr 0x08048108 paddr 0x08048108 align 2**2
filesz 0x00000020 memsz 0x00000020 flags r--

With gcc 3.4.1 and GNU ld version 2.14.90.0.6 20030820 and
compile with cc -o x.rw -z noexecstack x.c produces a
elf binary without execute permission on the stack.
(from objdump -p x.rw)

Program Header:
PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2
filesz 0x000000e0 memsz 0x000000e0 flags r-x
INTERP off 0x00000114 vaddr 0x08048114 paddr 0x08048114 align 2**0
filesz 0x00000013 memsz 0x00000013 flags r--
LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
filesz 0x00000735 memsz 0x00000735 flags r-x
LOAD off 0x00000738 vaddr 0x08049738 paddr 0x08049738 align 2**12
filesz 0x0000011c memsz 0x00000120 flags rw-
DYNAMIC off 0x00000748 vaddr 0x08049748 paddr 0x08049748 align 2**2
filesz 0x000000c8 memsz 0x000000c8 flags rw-
NOTE off 0x00000128 vaddr 0x08048128 paddr 0x08048128 align 2**2
filesz 0x00000020 memsz 0x00000020 flags r--
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rw-

With gcc 3.4.1 and GNU ld version 2.14.90.0.6 20030820 and
compiled with cc -o x.rwx -z execstack x.c. This produces
the same binary as with out the "-z execstack".

Program Header:
PHDR off 0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2
filesz 0x000000e0 memsz 0x000000e0 flags r-x
INTERP off 0x00000114 vaddr 0x08048114 paddr 0x08048114 align 2**0
filesz 0x00000013 memsz 0x00000013 flags r--
LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
filesz 0x00000735 memsz 0x00000735 flags r-x
LOAD off 0x00000738 vaddr 0x08049738 paddr 0x08049738 align 2**12
filesz 0x0000011c memsz 0x00000120 flags rw-
DYNAMIC off 0x00000748 vaddr 0x08049748 paddr 0x08049748 align 2**2
filesz 0x000000c8 memsz 0x000000c8 flags rw-
NOTE off 0x00000128 vaddr 0x08048128 paddr 0x08048128 align 2**2
filesz 0x00000020 memsz 0x00000020 flags r--
0x6474e551 off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rwx

Here's the corresponding /proc/pid/maps output from the
3 different binaries:


x.gcc322: 40013000-40014000 --xp 40013000 00:00 0
x.rw: 40013000-40014000 ---p 40013000 00:00 0
x.rwx: 40013000-40014000 ---p 40013000 00:00 0


So binaries compiled with an old compiler are not being
handled correctly with the nx-update.patch changes.

In load_elf_binary()

for (i = 0; i < elf_ex.e_phnum; i++, elf_ppnt++)
if (elf_ppnt->p_type == PT_GNU_STACK) {
if (elf_ppnt->p_flags & PF_X)
executable_stack = EXSTACK_ENABLE_X;
else
executable_stack = EXSTACK_DISABLE_X;
break;
}
if (i == elf_ex.e_phnum)
def_flags |= VM_EXEC | VM_MAYEXEC;

This setting of def_flags if the PT_GNU_STACK is NOT found
is causing the old binaries to get exec on PROT_NONE mmaps.

I've attached the 3 elf binaries.

Daniel
[unhandled content-type:application/x-executable-binary][unhandled content-type:application/x-executable-binary][unhandled content-type:application/x-executable-binary]
\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.036 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site