[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUyJWQnQsX22+wrvPbXkj67nhZ0SMP1_hCo2yZ+Z5tMyA@mail.gmail.com>
Date: Sun, 9 Mar 2014 21:46:21 -0700
From: Andy Lutomirski <luto@...capital.net>
To: "H. Peter Anvin" <hpa@...ux.intel.com>
Cc: Stefani Seibold <stefani@...bold.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Martin Runge <Martin.Runge@...de-schwarz.com>,
Andreas Brief <Andreas.Brief@...de-schwarz.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000
On Sun, Mar 9, 2014 at 8:18 PM, Andy Lutomirski <luto@...capital.net> wrote:
> (Of course, I haven't the faintest idea what l_addr in glibc means.
> If there was a way to arrange for l_addr to be zero, then maybe none
> of this would matter. Hmm, I wonder if just not relocating the vdso
> at all would have the desired effect. Anyone out there understand
> glibc?)
No, that won't work. The bug is that glibc expects PT_DYNAMIC's vaddr
to be the virtual address of the dynamic table. This can only be true
if the vdso is mapped at the address that the kernel relocated it to.
I also learned that glibc's code is really hideous. Wow.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists