Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752064AbeAEOnq (ORCPT + 1 other); Fri, 5 Jan 2018 09:43:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3354 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751847AbeAEOno (ORCPT ); Fri, 5 Jan 2018 09:43:44 -0500 Date: Fri, 5 Jan 2018 15:43:40 +0100 From: Andrea Arcangeli To: "Van De Ven, Arjan" Cc: Linus Torvalds , David Woodhouse , Tim Chen , Thomas Gleixner , Andy Lutomirski , Greg KH , "Hansen, Dave" , Andi Kleen , Linux Kernel Mailing List Subject: Re: [PATCH 0/7] IBRS patch series Message-ID: <20180105144340.GF26807@redhat.com> References: <1515093549.29312.11.camel@infradead.org> <0575AF4FD06DD142AD198903C74E1CC87A56A873@ORSMSX103.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0575AF4FD06DD142AD198903C74E1CC87A56A873@ORSMSX103.amr.corp.intel.com> User-Agent: Mutt/1.9.2 (2017-12-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 05 Jan 2018 14:43:44 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 04, 2018 at 09:22:34PM +0000, Van De Ven, Arjan wrote: > personally I am comfortable with retpoline on Skylake, but I would >like to have IBRS as an opt in for the paranoid. I think this whole variant#2 issue has to be fixed mathematically or not at all, the reason is that it's already "near zero risk" to begin with. If we leave any theoretical issues open we can as well stick with the "near zero risk" wording on AMD website and not fix anything. Doing a huge amount of work with reptoline and then you find SMM is called reproducibly somehow and a new PoC could exist for it, not fun. Whatever solution should be total and guaranteed or there's huge amount of resources wasted. Again spectre variant#2 this is "near zero risk" to begin with, on all CPUs because of the complexity to mount an attack on any given kernel/CPU combination out there. I'm mostly thinking about the "guest mode"/"host kernel mod" isolation here but this should apply in general to all kernel protection for spectre variant#2. If we can do a 3 way alternative IBRS on skylake, repotline + IBRS around all BIOS, graphics firmware and pci firmware + kernel asm patched with a 2-way alternative between amd reptoline and intel reptoline emitted 2-way by same gcc build, and still guarantee this solution is as mathematically safe as a pure IBRS (which is obviously mathematically safe), ok. Otherwise it'd prefer to stick to pure IBRS and skip the reptoline complexity and fallouts here and there around bios asm firmware SMM etc.. not to tell the need to rebuild qemu with reptoline with 2-way amd/intel alternatives self modifying code in userland during qemu startup to achieve ibrs 1 ibpb 1 + prctl IBRS on qemu with repotline. Thanks, Andrea