linux-kernel - Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid

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: <5c2f0af3-1740-f16b-6ff6-6bec6a325034@intel.com>
Date:   Mon, 4 Feb 2019 12:46:30 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>,
        Ashok Raj <ashok.raj@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Michael Chan <michael.chan@...adcom.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        Ricardo Neri <ricardo.neri@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid

On 2/4/19 11:57 AM, Borislav Petkov wrote:
> On Mon, Feb 04, 2019 at 11:05:52AM -0800, Dave Hansen wrote:
>> But, we're not being very persuasive because we kinda forgot about the
>> "if and only if" condition that you mentioned.
> But why does it have to be a cmdline parameter instead of
> being an automatic thing which sets the proper bits in
> arch/x86/kernel/cpu/intel.c based on f/m/s or MSR or whatever ?

It doesn't have to be a cmdline parameter.

Intel can obviously add or remove enumeration for a feature after
silicon ships.  But, that eats up microcode "patch" space which is an
even more valuable resource than the microcode "ROM" space.  That patch
space is a very constrained resource when creating things like the
side-channel mitigations.  The way I read this situation is that this
feature fills a bit small of a niche to justify consuming patch space.

So, the compromise we reached in this case is that Intel will fully
document the future silicon architecture, and then write the kernel
implementation to _that_.  Then, for the weirdo deployments where this
feature is not enumerated, we have the setcpuid= to fake the enumeration
in software.

The reason I'm pushing for setcpuid= instead of a one-off is that I
don't expect this to be the last time Intel does this.  I'd rather have
one setcpuid= than a hundred things like "ac_split_lock_disable".

The other alternative is that folks will run custom (non-mainline)
kernels with small patches to override the lack of enumeration.  Doing
setcpuid= keeps folks on mainline.  (BTW, we should probably taint the
kernel on setcpuid=....).