linux-kernel - Re: [BUG] x86 kenel won't boot under Virtual PC

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, 8 Sep 2008 10:38:08 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	Andi Kleen <andi@...stfloor.org>, linux@...dersweb.net,
	linux-kernel@...r.kernel.org,
	the arch/x86 maintainers <x86@...nel.org>,
	Andi Kleen <andi-suse@...stfloor.org>
Subject: Re: [BUG] x86 kenel won't boot under Virtual PC

On Mon, 8 Sep 2008, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> > 
> > Peter - does gcc actually use NOPL in _32-bit_ code too? It really seems to
> > be a stupid decision to make a binary not run on other CPU's over something
> > as trivial as that. That's something I'd expect out of an Intel compiler
> > just to mess with AMD, not out of gcc.
> > 
> 
> Yes, it does:
> 
>   /* We need to decide which NOP sequence to use for 32bit and
>      64bit. When -mtune= is used:
> 
>      1. For PROCESSOR_I386, PROCESSOR_I486, PROCESSOR_PENTIUM and
>      PROCESSOR_GENERIC32, f32_patt will be used.
>      2. For PROCESSOR_PENTIUMPRO, PROCESSOR_PENTIUM4, PROCESSOR_NOCONA,
>      PROCESSOR_CORE, PROCESSOR_CORE2, and PROCESSOR_GENERIC64,
>      alt_long_patt will be used.
>      3. For PROCESSOR_ATHLON, PROCESSOR_K6, PROCESSOR_K8 and
>      PROCESSOR_AMDFAM10, alt_short_patt will be used.
> 
>      When -mtune= isn't used, alt_long_patt will be used if
>      cpu_arch_isa_flags has Cpu686. Otherwise, f32_patt will
>      be used.
> 
> "alt_long_patt" uses NOPL and its variants.

That is A TOTAL PIECE OF SH*T, and against gcc's own documentation.

"-mtune=x" is very much defined to be a performance _tuning_ option, not 
an "architectural" option. 

Quite frankly, this is a gcc bug. Plain and simple. 

Look at the gcc man-pages. It very much says:

       -mtune=cpu_type
           Set only the instruction scheduling parameters for machine type
           cpu_type.  The instruction set is not changed.

(in various different formats - it says the same things with different 
words for different architectures. For example, for 386/x86-64 it 
_specifically_ says:

       -mtune=cpu-type
           Tune to cpu-type everything applicable about the generated code,
           except for the ABI and the set of available instructions.  The
           choices for cpu-type are:

note the "except for the ABI and the set of available instructions".

Qutie frankly, I think this is a *much* bigger bug than any possible 
VirtualPC idiocy. It's expressly against the whole idea of "-mtune".

Of course, we do set "-march=i686" too, so maybe the gcc people will claim 
that that means "Intel CPU's only". But quite frankly, if they really 
claim that, then they are lying pond-scum:

           i686
               Same as "generic", but when used as "march" option, PentiumPro
               instruction set will be used, so the code will run on all i686
               family chips.

which any sane x86 person would claim includes all the various clone 
manufacturers too. Saying that NOPL is so important that "i686" should 
suddenly be Intel-only is dishonest and totally stupid.

IOW, somebody who has a gcc bugzilla login should just create a bug-report 
on this. There is no question but that this is a bug, plain and simple.

			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/