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] [day] [month] [year] [list]

Message-ID: <20140919144408.GA5318@nazgul.tnic>
Date:	Fri, 19 Sep 2014 16:44:08 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	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 Fri, Sep 19, 2014 at 03:40:29PM +0200, Paolo Bonzini wrote:
> And similarly, Intel would not extend a bit from 16 to 17 bits if it
> weren't zero on all older processors.

Nothing is stopping a hw designer to say we're using 17 bits now. And
software needs to deal with that. It is that simple!

> > 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.
> 
> Once that bit gets a meaning in newer processors, the same meaning will
> work retroactively for existing processors.  That's just how CPUID is
> used.  Nobody checks families before testing bits, Intel/AMD do not even
> suggest that.

I know that, and I bet those bits won't even get reused but we don't
know, do we?! All I'm pointing at is that even the feature bits which
are reserved cannot be relied to be of any value.

In any case, the moment hw designers decide to change any field width
for which you have an union defined, this fragile scheme breaks with you
needing to introduce ifdeffery.

And frankly, this whole waste-time discussion is only about you guys
wanting to use those bitfields so that constructing a CPUID value works
more conveniently. (Reportedly, I'm not convinced of that at all).

While the gazillion other places in the kernel simply use logical
operations to construct a value and write it into the corresponding
register. Does that mean that they have to go and define unions for
those registers too? Of course not! That would be insane.

I remember a time where we did remove exactly that type of bitfields
from the ide code because it wasn't helping, it was counter-intuitive
and needless.

Geez, can we drop this already! It is a dumb idea, it doesn't bring us
anything besides some superficial readability which you don't really
need. Nowadays you can use even goddam wikipedia to understand what the
CPUID bits mean:

https://en.wikipedia.org/wiki/CPUID

Everytime we have to access registers, we need to open the corresponding
manual (or wikipedia, alternatively :-)) and look at the bit
definitions. This will not change.

> > Do you have a guarantee that this won't happen in the future and break
> > all your fancy bitfields assumptions?
> 
> No guarantee, but were that to happen, I'd expect tar and feathers
> spectacles around Intel's engineering headquarters.

You're going over and doing some fireworks there?

:-P

-- 
Regards/Gruss,
    Boris.
--
--
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/