linux-kernel - Re: [git pull] x86 fixes

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]

Message-ID: <alpine.LFD.1.10.0809081213330.3117@nehalem.linux-foundation.org>
Date:	Mon, 8 Sep 2008 12:30:02 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>,
	x86 maintainers <x86@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] x86 fixes

On Mon, 8 Sep 2008, Ingo Molnar wrote:
> 
> but 486 and higher is certainly quite reasonable, and is still being 
> tested.
> 
> ... and _in practice_ 99% of all systems that run Linux today understand 
> CMOV.

cmov, cmpxchg and xadd are the noticeable things.

I think there are realistically three classes:

 - _really_ old, to the point of being totally useless for SMP.

   This is really just 386 and clones. We _need_ a working WP for a 
   race-free access_ok(), and we need cmpxchg (and lately xadd).

   SMP cannot really realistically work reasonably (ys, there were SMP 
   machines. No, they don't matter), and you'd have to be insane to care 
   about this as a vendor even on UP. Probably nobody really cares (ie if 
   you have hardware that old, you are likely much better off with an 
   older kernel too)

   Smaller pains even on UP: bswap doesn't exist. invlpg doesn't exist. 

 - old. pre-cmov. i486 and pentium, and some clones.

   It's workable, but code generation differences are really big enough 
   that it's worth having a totally separate architecture option for newer 
   CPUs where the kernel simply won't work.

   And most newer distros probably simply don't care, although there may 
   be individual cases where this makes sense (embedded places still use 
   pentium clones etc, and there are probably a fair amount of individuals 
   that want to still use this)

   Other pains: TSC doesn't necessarily exist.

 - "modern 32-bit": PPro and better. Can take CMOV, MMX and TSC for 
   granted.

Yes, there are graduations to the above, but reasonably, those three are I 
think the "architectural" big versions. The rest should be:

 - pure "tuning" options. A Pentium 4 is different from Core 2 in tuning, 
   and the best code sequences can be very very different, but the binary 
   should work on both.

 - with *dynamic* choices for the differences that are architecturally 
   visible.

   Ie the whole choice of syscall/sysenter/int80 is dynamic, not specified 
   statically at compile time with a config option. So are things like the 
   different XMM versions etc.

Hmm? Doesn't that sound like a sane model?

		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/