linux-kernel - Re: [all better] Re: regression: massive trouble with fpu rework

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: <20150629095745.GE12383@pd.tnic>
Date:	Mon, 29 Jun 2015 11:57:45 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Mike Galbraith <umgwanakikbuti@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andy Lutomirski <luto@...nel.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>, Dave Hansen <dave@...1.net>
Subject: Re: [all better] Re: regression: massive trouble with fpu rework

On Mon, Jun 29, 2015 at 11:35:04AM +0200, Ingo Molnar wrote:
> I wish that 'unmasking' logic came with more comments:
> 
>   - Why do BIOSen ever mask CPUIDs?

Doesn't say a thing why:

066941bd4eeb ("x86: unmask CPUID levels on Intel CPUs")

SDM doesn't say why either:

"Limit CPUID Maxval (R/W)

When this bit is set to 1, CPUID.00H returns a maximum value in EAX[7:0]
of 3. BIOS should contain a setup question that allows users to specify
when the installed OS does not support CPUID functions greater than 3.

...

Setting this bit may cause unexpected behavior in software that depends
on the availability of CPUID leaves greater than 3."

In the case of hiding XSAVE from windoze ninety-old, probably something
was exploding there, there wasn't a fix to the software so the hardware
had to become soft.

Purely hypothetical, of course.

The last sentence from the SDM quote above also explains why the Linux
workaround of clearing that bit again, exists.

>   - Why do we unmask the masking?

Also purely hypothetical: because Linux doesn't have the windoze
problem.

>   - Why doesn't the kernel keep on working just fine even if certain
>   CPUID aspects are turned off?

I guess that should be doable but one has to get such a box, enable
that BIOS feature and fix all the fallout that happens. Provided it
can be fixed. hpa went and reenabled those CPUID leafs instead in
066941bd4eeb1.

I guess we simply shouldn't do any CPUID-dependent stuff before:

        if (this_cpu->c_early_init)
                this_cpu->c_early_init(c);

and slap a big fat comment above it.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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/