linux-kernel - Re: gcc 4.6.0 breaks User Mode Linux

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-prev] [day] [month] [year] [list]

Message-ID: <BANLkTi=iTRhJwLmUmPqbKWdiu4DtgfGe=w@mail.gmail.com>
Date:	Sat, 2 Apr 2011 12:38:42 +0200
From:	richard -rw- weinberger <richard.weinberger@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	user-mode-linux-devel@...ts.sourceforge.net,
	Jeff Dike <jdike@...toit.com>
Subject: Re: gcc 4.6.0 breaks User Mode Linux

On Thu, Mar 31, 2011 at 5:28 PM, richard -rw- weinberger
<richard.weinberger@...il.com> wrote:
> Hi,
>
> The um kernel (Linus's tree as of today) crashes very early during boot-up.
>
> ---cut---
> $ ./linux
> Locating the bottom of the address space ... 0x10000
> Locating the top of the address space ... 0xc0000000
> Core dump limits :
>        soft - 0
>        hard - NONE
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced syscall emulation patch for ptrace...OK
> Checking for tmpfs mount on /dev/shm...nothing mounted on /dev/shm
> Checking PROT_EXEC mmap in /tmp/...OK
> Checking for the skas3 patch in the host:
>  - /proc/mm...not found: No such file or directory
>  - PTRACE_FAULTINFO...not found
>  - PTRACE_LDT...not found
> UML running in SKAS0 mode
> Aborted
> ---cut---
>
> Here the gdb backtrace:
> ---cut---
> Program received signal SIGILL, Illegal instruction.
> kmem_cache_create (name=0x81efe77 "pid", size=44, align=4,
> flags=270336, ctor=0) at mm/slab.c:2181
> 2181                    BUG();
> (gdb) bt
> #0  kmem_cache_create (name=0x81efe77 "pid", size=44, align=4,
> flags=270336, ctor=0) at mm/slab.c:2181
> #1  0x0804c902 in pidmap_init () at kernel/pid.c:565
> #2  0x080494e9 in start_kernel () at init/main.c:591
> #3  0x0804a539 in start_kernel_proc (unused=0x0) at
> arch/um/kernel/skas/process.c:46
> #4  0x08063ec2 in run_kernel_thread (fn=0x804a50f <start_kernel_proc>,
> arg=0x0, jmp_ptr=0x823e7dc)
>    at arch/um/os-Linux/process.c:267
> #5  0x08057717 in new_thread_handler () at arch/um/kernel/process.c:153
> #6  0x00000000 in ?? ()
> ---cut---
>
> BUG() was trigged by in_interrupt() at mm/slab.c:2181.
> in_interrupt() returns misleadingly a non-zero value.
> My first idea was that in_interrupt() returns always a non-zero value,
> but this is not the case.
> preempt_count() seems broken in some way.
>
> I can reproduce this issue using gcc 4.6.0 on x86 and x86_64 hosts.
> Now I'm wondering whether this is a gcc or a uml bug.
>
> Any ideas where to start?
>
> --
> Thanks,
> //richard
>

current_thread_info() is broken, it returns not always a correct
thread_info struct.
At first place i thought -fpartial-inlining is guilty. But the problem
occurs also with
-fno-partial-inlining.

The attached patch fixes the problem.
It is not a nice solution, but it works for now.
As UML supports only on x86/x86_64 the asm("esp") is not a big deal...

diff --git a/arch/um/include/asm/thread_info.h
b/arch/um/include/asm/thread_info.h
index e2cf786..5da7fa6 100644
--- a/arch/um/include/asm/thread_info.h
+++ b/arch/um/include/asm/thread_info.h
@@ -47,10 +47,8 @@ struct thread_info {
 /* how to get the thread information struct from C */
 static inline struct thread_info *current_thread_info(void)
 {
- struct thread_info *ti;
- unsigned long mask = THREAD_SIZE - 1;
- ti = (struct thread_info *) (((unsigned long) &ti) & ~mask);
- return ti;
+ register unsigned long sp asm("esp");
+ return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
 }

 #define THREAD_SIZE_ORDER CONFIG_KERNEL_STACK_ORDER

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