linux-kernel - Re: [PATCH 2/2] x86/mm: Do not lose cpuinfo_x86:x86_phys

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: <alpine.DEB.2.21.1803271115040.1964@nanos.tec.linutronix.de>
Date:   Tue, 27 Mar 2018 11:23:50 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
cc:     Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Dave Hansen <dave.hansen@...el.com>,
        Kai Huang <kai.huang@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
        Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH 2/2] x86/mm: Do not lose cpuinfo_x86:x86_phys_bits
 adjustment

On Thu, 15 Mar 2018, Kirill A. Shutemov wrote:

> Some features (Intel MKTME, AMD SME) may reduce number of effectively

May? They fricking reduce the number of bits.

> available physical address bits. We adjust x86_phys_bits accordingly.
> 
> But if get_cpu_cap() got called more than one time we may lose this
> information.

We may? Dammit, I asked you more than once to stop writing fairy
tales. Changelogs are about facts and not about may/could or whatever. And
not WE lose the information, the information gets overwritten by the
subsequent invocation of get_cpu_cap().

> That's exactly what happens in setup_pku(): it gets called after
> detect_tme() and x86_phys_bits gets overwritten.
> 
> Add x86_phys_bits_adj which stores by how many bits we should reduce
> x86_phys_bits comparing to what CPUID returns.

That's just sloppy, really.

The real question is: Why on earth is get_cpu_cap() updating the 0x80000008
leaf information again after the first initialization?

If there is no reason to do so, then this needs to be taken out of
get_cpu_caps().

If there is a reason, then this wants to be explained proper.

This 'add some duct tape' mode has to stop. The cpu feature detection is
messy enough already, there is no need to add more to it unless there is a
real compelling reason.

Thanks,

	tglx