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  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 <>
To:	Borislav Petkov <>
Cc:	Paolo Bonzini <>,
	Nadav Amit <>,
	Ingo Molnar <>,
	"H. Peter Anvin" <>, Ingo Molnar <>,
	Thomas Gleixner <>,
	the arch/x86 maintainers <>,
	kvm <>,
	Linux Kernel Mailing List <>,
	Linus Torvalds <>,
	Andrew Morton <>,
	Peter Zijlstra <>
Subject: Re: [RESEND PATCH 1/3] x86: Adding structs to reflect cpuid fields

On Sep 19, 2014, at 10:58 AM, Borislav Petkov <> 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. 


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

Powered by blists - more mailing lists