Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 25 Jan 2018 17:24:49 +0100 (CET)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Alan Cox <gnomes@lxorguk.ukuu.org.uk>
cc:     David Woodhouse <dwmw2@infradead.org>, arjan@linux.intel.com,
        karahmed@amazon.de, x86@kernel.org, linux-kernel@vger.kernel.org,
        tim.c.chen@linux.intel.com, bp@alien8.de, peterz@infradead.org,
        pbonzini@redhat.com, ak@linux.intel.com,
        torvalds@linux-foundation.org, gregkh@linux-foundation.org,
        dave.hansen@intel.com, ashok.raj@intel.com, mingo@kernel.org
Subject: Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC_CTRL on early
 Spectre v2 microcodes
In-Reply-To: <20180125161547.33e63bb3@alans-desktop>
Message-ID: <alpine.DEB.2.20.1801251718210.2020@nanos>
References: <1516872189-16577-1-git-send-email-dwmw@amazon.co.uk> <1516872189-16577-7-git-send-email-dwmw@amazon.co.uk> <1516876994.30244.51.camel@infradead.org> <alpine.DEB.2.20.1801251146450.2020@nanos> <1516879213.30244.74.camel@infradead.org>
 <alpine.DEB.2.20.1801251221360.2020@nanos> <1516887714.30244.121.camel@infradead.org> <20180125161547.33e63bb3@alans-desktop>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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