On Tue, Oct 15, 2013 at 9:03 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Kees Cook <keesc...@chromium.org> wrote: > >> On Mon, Oct 14, 2013 at 11:04 PM, Ingo Molnar <mi...@kernel.org> wrote: >> > >> > * Kees Cook <keesc...@chromium.org> wrote: >> > >> >> On Mon, Oct 14, 2013 at 9:28 AM, H. Peter Anvin <h...@zytor.com> wrote: >> >> > On 10/14/2013 07:19 AM, H. Peter Anvin wrote: >> >> >> My guess is that the 95 addresses are randomized and the 82 address is >> >> >> an address which failed to relocate. >> >> > >> >> >> ffffffff82a04a58 is: >> >> >> ffffffff82a03000 t init_per_cpu__gdt_page >> >> > >> >> > >> >> > Specifically, it looks like the percpu stuff isn't getting set up >> >> > correctly. >> >> >> >> It wouldn't surprise me if there are even more percpu things to fix. >> >> It's the main area we've continued to trip over while working on this >> >> with various linkers. Which linker and version are you seeing this >> >> with? >> > >> > The failure I saw triggered with fairly modern userspace: >> > >> > GNU ld version 2.23.52.0.1-9.fc19 20130226 >> > >> > gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC) >> >> Can you try with the gold linker? When not using Gold, I can produce a >> similar crash with GNU ld ver 2.23.2 but not 2.22. > > I'm not set up for Gold - but maybe others can try your experiment. > > If you can see/reproduce the 2.23 crash then maybe that fix will work for > my testcase as well.
I haven't isolated the problem with 2.23 yet, but I'll start digging. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
