linux-kernel - Re: [RESEND PATCH 1/3] x86: Adding structs to reflect cpuid fields

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:	Fri, 19 Sep 2014 11:59:32 +0300
From:	Nadav Amit <nadav.amit@...il.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Paolo Bonzini <pbonzini@...hat.com>,
	Nadav Amit <namit@...technion.ac.il>,
	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	the arch/x86 maintainers <x86@...nel.org>,
	kvm <kvm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RESEND PATCH 1/3] x86: Adding structs to reflect cpuid fields


On Sep 19, 2014, at 10:58 AM, Borislav Petkov <bp@...en8.de> wrote:

> On Thu, Sep 18, 2014 at 03:36:43PM +0200, Paolo Bonzini wrote:
>> We're talking about the case where the field is not reserved anymore and
>> we _know_ that the vendor has just decided to grow the bitfield that
>> precedes it.
> 
> We're talking about the case where you assumed that a reserved bit is 0
> which is an unsafe assumption, the least.
> 
>> As soon as we know that the field is not reserved anymore, we
>> obviously rely on reserved bits being zero in older processors, and in
>> future processors from other vendors.
> 
> Again, this is an unsafe assumption.
> 
>> The trivial example is feature bits like XSAVE. We query them all the
>> time without checking the family when they were first introduced,
>> don't we?
> 
> The feature bits would obviously be 0 if features are not supported.
> 
> However, even there
> 
> "16 - Reserved - Do not count on the value."
> 
> I'm quoting Intel's CPUID doc 241618-037 from 2011 (there might be a
> newer one though), the CPUID(1).ECX description.

New fields which which replace reserved bits would be handled the same way with bitfields and bit masks.

As for the concern that CPUID fields would be extended into non-zero reserved bits - can someone point me to a single case that occurred in the last 20 years during which CPUID existed? 

The closest thing I found was “extended family id”, but this field is separate than “family id” and treated this way. 

Nadav

Download attachment "signature.asc" of type "application/pgp-signature" (496 bytes)