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:	Wed, 19 Aug 2015 15:33:50 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ingo Molnar <mingo@...nel.org>, Juergen Gross <jgross@...e.com>,
	Andy Lutomirski <luto@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86 fixes

On Wed, Aug 19, 2015 at 3:00 AM, H. Peter Anvin <hpa@...or.com> wrote:
>
> And I bet if CPUID actually reported the right thing it probably would work
> okay.  As I said, I tested this under Qemu which reported an accurate (lack
> of) CPUID for a 486SX.

While I agree that cpuid is a problem for FPU emulation on modern
CPU's, if this is due to "fucomip" then I think it's just that modern
distributions (and not-so-modern ones, for that matter) are compiled
with i686 support, so gcc just generates fucomip directly. So it's
just "plain FPU" code (no mmx, nothing like that), but it still fails.

The "set regular integer flags instructions" versions of floating
point compares are some of the bigger improvements to the legacy i87
instruction set, because the sequences to do FP compares without them
are just insane. I forget the details, but it's something like "store
status word to ax, then use sahf to get it into the flags register".
Crazy crazy crap. So it's no wonder that gcc wants to use a i686-only
instruction even for just regular FP code if at all possible.

I suspect it shouldn't be that hard to add f[u]compi[p] support to the
emulator.

But I also expect that most modern distributions are likely fairly
eager to use mmx etc, which sounds like a major pain to emulate.

                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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ