Re: [Valgrind-developers] Fedora Core 2

[Tom H. <th...@cy...>]

In message <108...@lo...>
        Jeremy Fitzhardinge <je...@go...> wrote:

> The initial problem is caused by VDSOs, which are placed low in the
> address space.  When Valgrind clears out the client area in stage2, it
> also clears out the sysinfo page, which happens to be where the munmap
> syscall returns to...

I believe they are actually placed at a random address, or so the
kernel source claims.

> So, if you turn off VDSOs (echo 0 > /proc/sys/kernel/vdso), you get to
> the next crash.  This is a fair bit further on, typicially when the
> client wants to expand the stack.  It gets a fault, calls our SIGSEGV
> handler, which expands the stack, and then returns from the handler with
> the intent of restarting the faulting instruction - BANG.  The handler
> returns to address 0x440 and explodes.  I haven't confirmed this yet,
> but it looks to me like a FC2 kernel bug.  I'm guessing that when it
> sets up the signal frame return address, it uses the sysinfo syscall
> return address, which is sysinfo_page + 0x440 - and since the sysinfo
> page hasn't been installed, it's just 0x440.

The code to setup the signal frame in arch/i386/kernel/signal.c is
doing this:

  restorer = current->mm->context.vdso + (long)&__kernel_sigreturn;

Now if vdso is set to zero then current->mm->context.vdso will be null
as no vdso will have been allocated. Hence restorer will be in zero
page which seems rather nasty. I'm a bit surprised anything at all
works with vdso's turned off in fact.

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/