From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation Date: Tue, 23 Jan 2018 10:27:56 +0100 Message-ID: <20180123092756.iznzepwnolsviof7@gmail.com> References: <1516476182-5153-1-git-send-email-karahmed@amazon.de> <1516476182-5153-10-git-send-email-karahmed@amazon.de> <1516566497.9814.78.camel@infradead.org> <1516572013.9814.109.camel@infradead.org> <1516638426.9521.20.camel@infradead.org> <20180123072930.soz25cyky3u4hpgv@gmail.com> <20180123075358.nztpyxympwfkyi2a@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linus Torvalds , KarimAllah Ahmed , Linux Kernel Mailing List , Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Arjan van de Ven , Ashok Raj , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , Jun Nakajima , Laura Abbott , To: David Woodhouse Return-path: Received: from mail-wr0-f176.google.com ([209.85.128.176]:41074 "EHLO mail-wr0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750946AbeAWJ2B (ORCPT ); Tue, 23 Jan 2018 04:28:01 -0500 Content-Disposition: inline In-Reply-To: <20180123075358.nztpyxympwfkyi2a@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: * Ingo Molnar wrote: > Is there a testcase for the SkyLake 16-deep-call-stack problem that I could run? > Is there a description of the exact speculative execution vulnerability that has > to be addressed to begin with? Ok, so for now I'm assuming that this is the 16 entries return-stack-buffer underflow condition where SkyLake falls back to the branch predictor (while other CPUs wrap the buffer). > If this approach is workable I'd much prefer it to any MSR writes in the syscall > entry path not just because it's fast enough in practice to not be turned off by > everyone, but also because everyone would agree that per function call overhead > needs to go away on new CPUs. Both deployment and backporting is also _much_ more > flexible, simpler, faster and more complete than microcode/firmware or compiler > based solutions. > > Assuming the vulnerability can be addressed via this route that is, which is a big > assumption! So I talked this over with PeterZ, and I think it's all doable: - the CALL __fentry__ callbacks maintain the depth tracking (on the kernel stack, fast to access), and issue an "RSB-stuffing sequence" when depth reaches 16 entries. - "the RSB-stuffing sequence" is a return trampoline that pushes a CALL on the stack which is executed on the RET. - All asynchronous contexts (IRQs, NMIs, etc.) stuff the RSB before IRET. (The tracking could probably made IRQ and maybe even NMI safe, but the worst-case nesting scenarios make my head ache.) I.e. IBRS can be mostly replaced with a kernel based solution that is better than IBRS and which does not negatively impact any other non-SkyLake CPUs or general code quality. I.e. a full upstream Spectre solution. Thanks, Ingo