[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1801040131050.1957@nanos>
Date: Thu, 4 Jan 2018 01:31:43 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Alan Cox <gnomes@...rguk.ukuu.org.uk>
cc: Andi Kleen <andi@...stfloor.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
dwmw@...zon.co.uk, Tim Chen <tim.c.chen@...ux.intel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Dave Hansen <dave.hansen@...el.com>
Subject: Re: Avoid speculative indirect calls in kernel
On Thu, 4 Jan 2018, Alan Cox wrote:
> On Wed, 3 Jan 2018 16:15:01 -0800
> Andi Kleen <andi@...stfloor.org> wrote:
>
> > > It should be a CPU_BUG bit as we have for the other mess. And that can be
> > > used for patching.
> >
> > It has to be done at compile time because it requires a compiler option.
> >
> > Most of the indirect calls are in C code.
> >
> > So it cannot just patched in, only partially out.
>
> You can replace the pushl ; jmp with an alternatives section (although
> there might be a lot of them). Even if gcc isn't smart enough to do that
> perl is.
So you say, that we finally need a perl interpreter in the kernel to do
alternative patching?
Thanks,
tglx
Powered by blists - more mailing lists