From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753044AbeADMJe (ORCPT + 1 other); Thu, 4 Jan 2018 07:09:34 -0500 Received: from www.llwyncelyn.cymru ([82.70.14.225]:44442 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752996AbeADMJc (ORCPT ); Thu, 4 Jan 2018 07:09:32 -0500 Date: Thu, 4 Jan 2018 12:09:14 +0000 From: Alan Cox To: Pavel Machek Cc: Andi Kleen , tglx@linutronix.de, torvalds@linux-foundation.org, gregkh@linux-foundation.org, linux-kernel@vger.kernel.org, tim.c.chen@linux.intel.com Subject: Re: Avoid speculative indirect calls in kernel Message-ID: <20180104120914.322fa95e@alans-desktop> In-Reply-To: <20180104114917.GC1702@amd> References: <20180104020019.1173-1-andi@firstfloor.org> <20180104114917.GC1702@amd> Organization: Intel Corporation X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, 4 Jan 2018 12:49:17 +0100 Pavel Machek wrote: > Hi! > > > This is a fix for Variant 2 in > > https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html > > > > Any speculative indirect calls in the kernel can be tricked > > to execute any kernel code, which may allow side channel > > attacks that can leak arbitrary kernel data. > > Ok. > > > So we want to avoid speculative indirect calls in the kernel. > > > > There's a special code sequence called a retpoline that can > > do indirect calls without speculation. We use a new compiler > > option -mindirect-branch=thunk-extern (gcc patch will be released > > separately) to recompile the kernel with this new sequence. > > So... this "retpoline" code is quite tricky; I guess it does the right > on recent Intel CPUs. Does it also do the right thing on all the AMD, > Cyrix, ... variants? > > Is it neccessary on all the CPUs? I guess 486 does not need this? It's architecturally valid x86 code so it should work on any x86-32 processor. You are correct older processors and some of the newer ones don't need it. AMD and VIA I don't know about but for Intel we can probably avoid it on older Atom, on Quark, and the really old CPUs nobody actually runs any more. That's all an optimization once we have correctness. Alan