Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751641AbeADAJb (ORCPT + 1 other); Wed, 3 Jan 2018 19:09:31 -0500 Received: from one.firstfloor.org ([193.170.194.197]:51166 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751311AbeADAJa (ORCPT ); Wed, 3 Jan 2018 19:09:30 -0500 Date: Wed, 3 Jan 2018 16:09:27 -0800 From: Andi Kleen To: Linus Torvalds Cc: Andi Kleen , tglx@linutronix.de, Greg Kroah-Hartman , dwmw@amazon.co.uk, Tim Chen , Linux Kernel Mailing List , Dave Hansen Subject: Re: Avoid speculative indirect calls in kernel Message-ID: <20180104000927.co5umvfzfwliqvqt@two.firstfloor.org> References: <20180103230934.15788-1-andi@firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hi Linus, On Wed, Jan 03, 2018 at 03:51:35PM -0800, Linus Torvalds wrote: > On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen wrote: > > 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. > > Why is this all done without any configuration options? I was thinking of a config option, but I was struggling with a name. CONFIG_INSECURE_KERNEL, CONFIG_LEAK_MEMORY? And should it be positive or negative? So I opted to be secure uncontionally. It would be simple to add however, all hooks are either in the Makefile or in asm/jump-asm.h > - these workarounds should have a way to disable them. > There will be soon patches to add other ways and they have a way to patch out most of the retpoline overhead at runtime (basically replace the trampoline with a pure ret) We just wanted to get the retpoline code out first because it's the most basic and widest applicable fix. -Andi