linux-kernel - [x86/mm] vsyscall_fn fault in early startup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080111072143.D940526F9A9@magilla.localdomain>
Date:	Thu, 10 Jan 2008 23:21:43 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: [x86/mm] vsyscall_fn fault in early startup

I bisected my startup problem down to:

	197e4989b0404996dfe3ab091c1398e4c2813d44 is first bad commit
	commit 197e4989b0404996dfe3ab091c1398e4c2813d44
	Author: Ingo Molnar <mingo@...e.hu>
	Date:   Wed Jan 9 13:31:06 2008 +0100

	    x86: mark native_read_tsc() as __vsyscall_fn

	    Andi Kleen reported the following breakage: the 64-bit vdso faulted
	    because native_read_tsc() is not a vsyscall-fn. Mark it as such.

	    Signed-off-by: Ingo Molnar <mingo@...e.hu>

Without that commit, it gets past early startup and boots fine,
but of course then init crashes in the vDSO just as Andi reported.

Apparently this one:

	commit 715cf488c640ef4bed6c971660251d8d6cba4fbb
	Author: Ingo Molnar <mingo@...e.hu>
	Date:   Wed Jan 9 13:31:06 2008 +0100

	    x86: map vsyscalls early enough

	    map vsyscalls early enough. This is important if a __vsyscall_fn
	    function is used by other kernel code too.

	    Signed-off-by: Ingo Molnar <mingo@...e.hu>

is not really doing its job.  It's not early enough for the use I'm hitting.

Thanks to qemu-gdbserver, I have this handy backtrace for the early startup
case even though it dies too hard to print one.  
0xffffffffff60010d is really &native_read_tsc+0 though gdb reports the name
of the preceding symbol (vread_tsc).

   #0  early_idt_handler ()
       at /home/roland/redhat/linux/2.6/arch/x86/kernel/head_64.S:289
   #1  0x0000000000000010 in ?? ()
   #2  0xffffffffff60010d in vread_tsc ()
       at /home/roland/redhat/linux/2.6/arch/x86/kernel/tsc_64.c:308
   #3  0xffffffff80258cec in __lock_acquire (lock=0xffffffff806f4bf8, 
       subclass=0, trylock=0, read=0, check=2, hardirqs_off=1, 
       ip=18446744071564512884)
       at /home/roland/redhat/linux/2.6/kernel/lockdep.c:2416
   #4  0xffffffff802598f2 in lock_acquire (lock=0xffffffff806ea460, subclass=1, 
       trylock=3340, read=131072, check=-1, ip=18446744071564405679)
       at /home/roland/redhat/linux/2.6/kernel/lockdep.c:2703
   #5  0xffffffff8054de4f in _spin_lock (lock=0xffffffff806f4be0)
       at /home/roland/redhat/linux/2.6/kernel/spinlock.c:180
   #6  0xffffffff80254e74 in clockevents_register_notifier (
       nb=0xffffffff806f4c80)
       at /home/roland/redhat/linux/2.6/kernel/time/clockevents.c:114
   #7  0xffffffff807dc1f4 in tick_init ()
       at /home/roland/redhat/linux/2.6/kernel/time/tick-common.c:390
   #8  0xffffffff807c9811 in start_kernel ()
       at /home/roland/redhat/linux/2.6/init/main.c:531
   #9  0xffffffff807c9110 in x86_64_start_kernel (
       real_mode_data=0x92dc0 <Address 0x92dc0 out of bounds>)
       at /home/roland/redhat/linux/2.6/arch/x86/kernel/head64.c:73

So with lockdep et al turned on, tick_init leads to native_read_tsc.
setup_arch is after tick_init, so not early enough.  

I don't know if map_vsyscall needs too much stuff to come much earlier than
it is.  

It might be best just to let native_read_tsc be inlined ;-)


Thanks,
Roland
--
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/