linux-kernel - Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC

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:   Thu, 25 Jan 2018 17:24:49 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
cc:     David Woodhouse <dwmw2@...radead.org>, arjan@...ux.intel.com,
        karahmed@...zon.de, x86@...nel.org, linux-kernel@...r.kernel.org,
        tim.c.chen@...ux.intel.com, bp@...en8.de, peterz@...radead.org,
        pbonzini@...hat.com, ak@...ux.intel.com,
        torvalds@...ux-foundation.org, gregkh@...ux-foundation.org,
        dave.hansen@...el.com, ashok.raj@...el.com, mingo@...nel.org
Subject: Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC_CTRL on early
 Spectre v2 microcodes

On Thu, 25 Jan 2018, Alan Cox wrote:

> > Here's what I have now. I'm happy enough with this, so the main thing
> > I'm looking for is an ack from Alan for patch #5 of the series, if I've
> > got that sufficiently correct now.
> 
> You have my ACK for patch 5: Any further changes I'll submit as updates
> once it's merged.
> 
> I am happy with patch 5 and I think for 64bit we are probably done for
> the mainstream. VIA/Centaur data would be nice.
> 
> The microcode otoh I don't think makes sense - do you want to be secure
> with a slightly higher risk of crashes or insecure ? Once you can point
> at a newer ucode for each case then yes I personally at least think it
> then makes sense to tell users they want the newer one.

Yes, ideally we can tell the user to update to ucode rev > X for a
particular SKU. Though with the current state of affairs all we can do is
accumulate ucode revisions which are marked bad by Intels Quality
Assumptions at a given day.

Once Intel gets its act together and provides authoritative information we
can revisit this and make it user friendly. You might be able to speculate
more precisely when this is going to happen.

Thanks,

	tglx