La 07.09.2019 00:16, Thomas Gleixner a scris:
On Fri, 6 Sep 2019, Johannes Erdfelt wrote:
On Fri, Sep 06, 2019, Thomas Gleixner wrote:
What your customers are asking for is a receipe for disaster. They can
check the safety of late loading forever, it will not magically become safe
because they
Hi Thomas,
On Tue, Sep 17, 2019 at 08:37:10AM +0200, Thomas Gleixner wrote:
> > microode updates should be of 3 types.
> >
> > - Only loadable from BIOS (Only via FIT tables)
> > - Suitable for early load (things that take cpuid bits for e.g.)
> > - Suitable for late-load. (Where no cpuid bits sh
On Tue, Sep 17, 2019 at 08:37:10AM +0200, Thomas Gleixner wrote:
> So what happens if the ucode update "fixes" one of the executed
> instructions on the fly? Is that guaranteed to be safe? There is nothing
> which says so.
You'd expect that when you load microcode on the core, the one thread
does
Raj,
On Mon, 16 Sep 2019, Raj, Ashok wrote:
> On Mon, Sep 16, 2019 at 12:36:11PM +0200, Thomas Gleixner wrote:
> > That said, there is also a distinct lack of information about micro code
> > loading in a safe way in general. We absolutely do not know whether a micro
> > code update affects any in
On Mon, Sep 16, 2019 at 12:36:11PM +0200, Thomas Gleixner wrote:
> > On Fri, 6 Sep 2019, Raj, Ashok wrote:
> > > On Fri, Sep 06, 2019 at 11:16:00PM +0200, Thomas Gleixner wrote:
> > > > Now #1 is actually a sensible and feasible solution which can be pulled
> > > > off
> > > > in a reasonably shor
On Sat, 7 Sep 2019, Thomas Gleixner wrote:
> On Fri, 6 Sep 2019, Raj, Ashok wrote:
> > On Fri, Sep 06, 2019 at 11:16:00PM +0200, Thomas Gleixner wrote:
> > > Now #1 is actually a sensible and feasible solution which can be pulled
> > > off
> > > in a reasonably short time frame, avoids all the bou
On Fri, 6 Sep 2019, Raj, Ashok wrote:
> On Fri, Sep 06, 2019 at 11:16:00PM +0200, Thomas Gleixner wrote:
> > Now #1 is actually a sensible and feasible solution which can be pulled off
> > in a reasonably short time frame, avoids all the bound to be ugly and
> > failure laden attempts of fixing lat
On Fri, Sep 06, 2019 at 11:16:00PM +0200, Thomas Gleixner wrote:
>
> So if we want to do late microcode loading in a sane way then there are
> only a few options and none of them exist today:
>
> 1) Micro-code contains a description of CPUID bits which are going to be
> exposed after the loa
On Fri, 6 Sep 2019, Johannes Erdfelt wrote:
> On Fri, Sep 06, 2019, Thomas Gleixner wrote:
> > What your customers are asking for is a receipe for disaster. They can
> > check the safety of late loading forever, it will not magically become safe
> > because they do so.
> >
> > If you want late lo
On Fri, Sep 06, 2019 at 09:52:07AM -0700, Johannes Erdfelt wrote:
> That doesn't mean that late loading isn't still useful.
If it weren't useful, it would've been gone a long time ago. No one is
arguing whether it is useful or not.
> Just as I can't know for sure that every future microcode updat
On Fri, Sep 06, 2019 at 12:43:53PM -0400, Konrad Rzeszutek Wilk wrote:
> Do you have insights on the best way to restructure the code for this?
Well, I only started thinking about this when you guys brought it on and
you were actually serious about it. :)
So IINM, this is one of the livepatch pro
Hi Thomas,
On Fri, Sep 06, 2019 at 02:51:17PM +0200, Thomas Gleixner wrote:
> Raj,
>
> On Thu, 5 Sep 2019, Raj, Ashok wrote:
> > On Thu, Sep 05, 2019 at 11:22:31PM +0200, Thomas Gleixner wrote:
> > > That's all nice, but what it the general use case for this outside of
> > > Intel's
> > > microc
On Fri, Sep 06, 2019, Borislav Petkov wrote:
> On Fri, Sep 06, 2019 at 08:46:18AM -0700, Johannes Erdfelt wrote:
> > That said, we very much rely on late microcode loading and it has helped
> > us and our customers significantly.
>
> You do realize that you rely on an update method which *won't*
> Or someone could rewrite arch/x86/ to rediscover new features upon a
> microcode reload or a feature disabling. And do that in a clean way. Who
> knows...
The clean way to do microcode reloading and the vast amount of re-initialization
that has to happen is the definitly what we all want.
It ma
On Fri, Sep 06, 2019 at 08:46:18AM -0700, Johannes Erdfelt wrote:
> That said, we very much rely on late microcode loading and it has helped
> us and our customers significantly.
You do realize that you rely on an update method which *won't* work in
all possible cases and then you *will* have to r
On Fri, Sep 06, 2019, Borislav Petkov wrote:
> On Fri, Sep 06, 2019 at 07:40:39AM -0700, Johannes Erdfelt wrote:
> > I ask because we have successfully used late microcode loading on tens
> > of thousands of hosts.
>
> How do you deal with all the mitigations microcode loaded late?
We developed
On Fri, Sep 06, 2019 at 07:40:39AM -0700, Johannes Erdfelt wrote:
> You say that switching of CPU feature bits is problematic, but adding
> new features should result only in a warning ("x86/CPU: CPU features
> have changed after loading microcode, but might not take effect.").
That's the only san
On Fri, Sep 06, 2019, Thomas Gleixner wrote:
> What your customers are asking for is a receipe for disaster. They can
> check the safety of late loading forever, it will not magically become safe
> because they do so.
>
> If you want late loading, then the whole approach needs to be reworked from
Raj,
On Thu, 5 Sep 2019, Raj, Ashok wrote:
> On Thu, Sep 05, 2019 at 11:22:31PM +0200, Thomas Gleixner wrote:
> > That's all nice, but what it the general use case for this outside of
> > Intel's
> > microcode development and testing?
> >
> > We all know that late microcode loading has severe li
On Thu, Sep 05, 2019 at 03:27:06PM -0700, Raj, Ashok wrote:
> Several customers have asked this to check the safety of late loads.
> They want to validate in production setup prior to rolling late-load
> to all production systems.
First of all, they should use *early* loading. I don't know how man
Hi Thomas,
On Thu, Sep 05, 2019 at 11:22:31PM +0200, Thomas Gleixner wrote:
> Raj,
>
> On Thu, 5 Sep 2019, Raj, Ashok wrote:
> > On Thu, Sep 05, 2019 at 09:20:29AM +0200, Borislav Petkov wrote:
> > > On Wed, Sep 04, 2019 at 05:21:32PM -0700, Raj, Ashok wrote:
> > > > But echo 2 > reload would al
Raj,
On Thu, 5 Sep 2019, Raj, Ashok wrote:
> On Thu, Sep 05, 2019 at 09:20:29AM +0200, Borislav Petkov wrote:
> > On Wed, Sep 04, 2019 at 05:21:32PM -0700, Raj, Ashok wrote:
> > > But echo 2 > reload would allow reading a microcode file from
> > > /lib/firmware/intel-ucode/ even if the revision h
On Thu, Sep 05, 2019 at 09:49:50PM +0200, Borislav Petkov wrote:
> On Thu, Sep 05, 2019 at 12:40:44PM -0700, Raj, Ashok wrote:
> > The original description said to load a new microcode file, the content
> > could have changed, but revision in the header hasn't increased.
>
> How does the hardware
On Thu, Sep 05, 2019 at 12:40:44PM -0700, Raj, Ashok wrote:
> The original description said to load a new microcode file, the content
> could have changed, but revision in the header hasn't increased.
How does the hardware even accept a revision which is the same as the
one already loaded?
--
Re
Hi Boris
On Thu, Sep 05, 2019 at 09:20:29AM +0200, Borislav Petkov wrote:
> On Wed, Sep 04, 2019 at 05:21:32PM -0700, Raj, Ashok wrote:
> > But echo 2 > reload would allow reading a microcode file from
> > /lib/firmware/intel-ucode/ even if the revision hasn't changed right?
> >
> > #echo 1 > re
On Thu, 5 Sep 2019, Borislav Petkov wrote:
> On Wed, Sep 04, 2019 at 05:21:32PM -0700, Raj, Ashok wrote:
> > But echo 2 > reload would allow reading a microcode file from
> > /lib/firmware/intel-ucode/ even if the revision hasn't changed right?
> >
> > #echo 1 > reload wouldn't load if the revisi
On Wed, Sep 04, 2019 at 05:21:32PM -0700, Raj, Ashok wrote:
> But echo 2 > reload would allow reading a microcode file from
> /lib/firmware/intel-ucode/ even if the revision hasn't changed right?
>
> #echo 1 > reload wouldn't load if the revision on disk is same as what's
> loaded,
> and we want
On Thu, Sep 05, 2019 at 12:12:29AM +0200, Boris Petkov wrote:
> On September 5, 2019 12:06:54 AM GMT+02:00, Boris Ostrovsky
> wrote:
> >Why do we need to taint kernel here? We are not making any changes.
>
> Because this is not a normal operation we want users to do. This is only for
> testing
On 9/3/19 12:46 PM, Borislav Petkov wrote:
>
>
> @@ -629,8 +639,12 @@ static ssize_t reload_store(struct device *dev,
> if (ret)
> return ret;
>
> - if (val != 1)
> + if (val == 2) {
> + add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
Why do we need
On September 5, 2019 12:06:54 AM GMT+02:00, Boris Ostrovsky
wrote:
>Why do we need to taint kernel here? We are not making any changes.
Because this is not a normal operation we want users to do. This is only for
testing microcode quicker.
>This won't allow people to load from new microcode bl
On Thu, Aug 29, 2019 at 06:02:14AM -0700, Raj, Ashok wrote:
> > As I've said before, I don't like the churn in this version and how it
> > turns out. I'll have a look at how to do this cleanly when I get some
> > free cycles.
Ok, here's an untested rough version. It is doing a couple of things in
On Thu, Aug 29, 2019 at 08:09:42AM +0200, Borislav Petkov wrote:
> On Wed, Aug 28, 2019 at 10:33:22PM -0700, Ashok Raj wrote:
> > During microcode development, its often required to test different versions
> > of microcode. Intel microcode loader enforces loading only if the revision
> > is
> > gr
On Wed, Aug 28, 2019 at 10:33:22PM -0700, Ashok Raj wrote:
> During microcode development, its often required to test different versions
> of microcode. Intel microcode loader enforces loading only if the revision is
> greater than what is currently loaded on the cpu. Overriding this behavior
> all
Hi Boris,
sorry i added the wrong message id in the commit log.
https://lore.kernel.org/r/20190824085300.gb16...@zn.tnic/
On Wed, Aug 28, 2019 at 10:33:22PM -0700, Ashok Raj wrote:
> During microcode development, its often required to test different versions
> of microcode. Intel microcode load
During microcode development, its often required to test different versions
of microcode. Intel microcode loader enforces loading only if the revision is
greater than what is currently loaded on the cpu. Overriding this behavior
allows us to reuse the same revision during development cycles.
This f
35 matches
Mail list logo
