linux-kernel - Re: [PATCH 4/4] x86, 32-bit: Drop new_cpu

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:	Sun, 03 Feb 2013 21:44:02 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Borislav Petkov <bp@...en8.de>
CC:	X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...e.de>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [PATCH 4/4] x86, 32-bit: Drop new_cpu_data

boot_cpu_data is ok for things that are indeed universally valid across.  That does not include CPUID level, for one.

Borislav Petkov <bp@...en8.de> wrote:

>On Sun, Feb 03, 2013 at 03:44:29PM -0800, H. Peter Anvin wrote:
>> On 02/03/2013 08:14 AM, Borislav Petkov wrote:
>> >From: Borislav Petkov <bp@...e.de>
>> >
>> >We copy it to boot_cpu_data anyway so use boot_cpu_data from the
>get-go.
>> >
>> 
>> Hmm... this is the only part of this patchset I feel skeptical
>> towards.  Overall, a lot of the early SMP code went way out of its
>> way to have zero impact on the !CONFIG_SMP case, but that was a long
>> time ago. Nowadays what we really should have is cpu_data being a
>> percpu variable separate from boot_cpu_data (which is really
>> "all_cpu_data") even on UP.
>
>Hmmkay.
>
>My thought vector here was to use boot_cpu_data to cache stuff
>here which is universally valid on the current system, i.e. like
>all_cpu_data. IOW, cache here family (model and stepping could differ,
>as we've come to realize over the years :)) vendor (btw, X86_VENDOR is
>unused) CPUID_EAX(0) level, capability, etc and use them later instead
>of querying them again.
>
>So, so early and in this case, we're saving CPU data which is valid for
>all CPUs on the system and thus it belongs into boot_cpu_data, right?
>
>And then, btw, that data could've been used in verify_cpu.S only if the
>damn thing wasn't being used in arch/x86/boot/...
>
>> Another cleanup desperately needed in this area is a bitvector for
>> bugs in addition to features.
>
>Yeah, c->x86_unfeatures! :-)
>
>> In fact, I kind of suspect we should make it the *same* bitvector
>> (different words) so we cpu_has(X) works on both without confusion
>> (just put the BUGS at the end; it means that if we add feature words
>> the bug numbers will shift but that is okay.)
>>
>> I actually mean to do this when I did the CPU feature vector stuff
>> over 10 years ago, but never got around to it... and it still has
>> never gotten done.
>>
>> The difference between bugs and features, of course, is that the
>> former should be combined across CPUs with an OR whereas the latter
>> get combined with an AND.
>
>Yeah, that should be pretty easy to do with the current machinery
>already in place. I'll take a look.
>
>Thanks.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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/