linux-kernel - Re: Math-emu kills the kernel on Athlon64 X2

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

Date:	Mon, 18 Sep 2006 16:49:32 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Jesper Juhl <jesper.juhl@...il.com>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	billm@...bpc.org.au, billm@...urbia.net
Subject: Re: Math-emu kills the kernel on Athlon64 X2



On Tue, 19 Sep 2006, Jesper Juhl wrote:
> On 19/09/06, Linus Torvalds <torvalds@...l.org> wrote:
> > 
> > Basically, "no387" doesn't seem to disable any of the fancier FPU
> > features, even though it obviously should. If you ask for math emulation,
> > you'll get emulation faults for _all_ of the modern MMX stuff too (which
> > we don't do).
> > 
> Hmm, I guess that could be the problem. The emulator should disable
> any stuff which it's not able to handle. I've not actually looked very
> much at the emulator code yet, so I didn't realize it didn't disable
> what it couldn't handle, but getting it to do that sounds like a
> sensible first step.

I would guess that we might notice, for example, that the CPU supports 
FXSR (fxsave/fxrestor) through looking at cpuid, and then we have, for 
example:

    arch/i386/kernel/cpu/common.c: cpu_init() ->
	arch/i386/kernel/i387.c: mxcsr_feature_mask_init() ->


        if (cpu_has_fxsr) {
                memset(&current->thread.i387.fxsave, 0, sizeof(struct i387_fxsave_struct));
                asm volatile("fxsave %0" : : "m" (current->thread.i387.fxsave));
		...

ie we will do one of the fancy new instructions from kernel space (very 
early), because this path at no point even bothers to check whether it is 
supposed to even use hw FP at all.

You can try booting with "no387 nofxsr" to get rid of at least _that_ 
particular issue, but there might be other cases like that in the MMX 
code, for example ("nofxsr" should disable both the FXSR and XMM 
capabilities as far as the kernel is concerned).

If that works (or gets you further), we should just make "no387" disable 
FXSR by itself. 

Worth testing, and you can do it without even recompiling the kernel, 
since we already have that kernel command line flag.

		Linus
-
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/