From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1516699680; cv=none; d=google.com; s=arc-20160816; b=xn6mglDC4H1YZeURtTxhgIa4LCvQXMPQB6i/2yBv49MlLZJ2pSInyt7F8Y1QrMHQca uTDDEjm9s/eSFw/Nk7Qmp+MGBaQDvTz1FyOjTkyn1ld5rle+v+bOOw7WcgDAXRckGT9s RDS3l7XJqEo5kgdGBy5Vkhwfd4IwZ2ISEqhIFQnjQBSlQ6HvaDCn7V/ZO0YsPsiK5ugg cV33ox7cUtv6WiJIKI46xuiwA7inysdud9d0JiXYUfC2am4pO7cYYkXC/yPj0eT46Ja/ 2q8JDTDQrcEirJ9h8JBRSOCrRaX19DZKflkhDHgNl6wqDnhV39DHyr9u/gu1PQ5Tt1Zy HPQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:sender:dkim-signature :arc-authentication-results; bh=bHHulpTIfFVDhbvbT07lOeBZglMs5RupZNUhqXmKkl4=; b=TsEXUPd93lFvfDvm80XrbAWmMG4ULHjludPoo+29gY0YueWwAmqZImBcJPsStQE/0s wa4Kx9zibP9cj/jBuFbyIineynCPd6y1wD80f0fw9gibKxXwY4SZ3R7HbykyP66eXRhL eUUmOpgVpdFO6KvzF8WwvViq6+257JDsdur+6ujlbHCaZjGH7Z/baMR0SvWuHcejvVf7 wuJW6p1eehtZkWQKxV+ZpOuhVVBo6rdQCTDCeqiq242oHaIKjj6ksoat18Qa5lLRCY/F u1CmWQL748nVANenoP3Mq+BKbQWb9Mr/72SBGmZQhrVwT4+SNeg4GdJMZ8zWYxsPQSGA fD9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ovJvuzYj; spf=pass (google.com: domain of mingo.kernel.org@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ovJvuzYj; spf=pass (google.com: domain of mingo.kernel.org@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com X-Google-Smtp-Source: AH8x225+2RgQ0Sx/rqledjdnpcrDb/FMtf60RyLMCUBkMpAoGyJxACXEFKasUJDeyPIc/puAnUqcQA== Sender: Ingo Molnar Date: Tue, 23 Jan 2018 10:27:56 +0100 From: Ingo Molnar To: David Woodhouse 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 , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , Radim =?utf-8?B?S3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , KVM list , the arch/x86 maintainers , Arjan Van De Ven Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation 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 Content-Disposition: inline In-Reply-To: <20180123075358.nztpyxympwfkyi2a@gmail.com> User-Agent: NeoMutt/20170609 (1.8.3) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140582166248265?= X-GMAIL-MSGID: =?utf-8?q?1590374883757771142?= X-Mailing-List: linux-kernel@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