Received: by 10.223.176.46 with SMTP id f43csp1765430wra; Sun, 21 Jan 2018 04:05:19 -0800 (PST) X-Google-Smtp-Source: AH8x226fhJRuCcQ4i0FnIuzh13lOAg+K5d3lCUC5lWd+RDjC/QqbqvBMXyrAPLx9gyQoN1U6eZmJ X-Received: by 10.98.46.2 with SMTP id u2mr5143032pfu.30.1516536319139; Sun, 21 Jan 2018 04:05:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516536319; cv=none; d=google.com; s=arc-20160816; b=Nm8GB6flFZPgPjh5yIwK14AT7xQlnl7NuWLzagjlfOgppTJcmosOQu3Aw2gZ5vsAJH pVqtnPWLt+AWIrxG9TdWluw/h2LB8KIRSH89g8utiAVvS/ZGCdRlVPG99c8plqtaAN/H vbYvtqgu1tBdSb7bcN5cxVep8z5A+wI4Uf6DUFQmBn3vDdi+iQxs6kJyuSaWtxnTNEQW dKdFe04nF99zJ/aUohQ1ImWwRM8+XNXYpnhEqYkqPouWN8ZENxP5x3P1jmO9eTGKA/xB XHG/J9zBXU/fyhqZ/Sxbb/ktZ5BlwEvYojA73L02+ptdjKJ76kXX79pvdcpO4H8jtoUC vsqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:importance:content-transfer-encoding :mime-version:user-agent:cc:to:from:subject:date:references :in-reply-to:message-id:dkim-signature:arc-authentication-results; bh=n4qL0wkFUokv28LVCfjtRn4sS2fJvgjGgwUJwk1D3uk=; b=C8+UARCVHwor94finq6JC+wY+Zz/xsURBJOCbmADYvy6OW0R6XLVYvCq6liqLxlWyr 87oqm4Uv1Y5nv7ljeaU3+0O2KRbc+vwE2oGDqvWxiGUoQEckwA/mqyledlSojq9K0Oyx BHykKqxWrpyBlplwzNuZCNwl3V116Ox9q3vLjHCbx2W/ceYKbeBLhtPUdpVAM8IvEte+ +F/eZmZZIw5IPdN4JbFOPtGLLDOMntjsSGuqcHrbjFod06py/KBx1FzB1M5DftOt2DON Z2Lqd6x1yTE/+BJsG7OhbA4wiyKURbUjusKtispELR/uO+Ev5vhJHJEDRvmbNVK5voJ0 gpwQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=twosheds.20170209 header.b=nkljZgUD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w23si12271950pgc.569.2018.01.21.04.04.53; Sun, 21 Jan 2018 04:05:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=twosheds.20170209 header.b=nkljZgUD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751147AbeAUMES (ORCPT + 99 others); Sun, 21 Jan 2018 07:04:18 -0500 Received: from twosheds.infradead.org ([90.155.92.209]:40400 "EHLO twosheds.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750892AbeAUMEQ (ORCPT ); Sun, 21 Jan 2018 07:04:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=twosheds.20170209; h=Content-Transfer-Encoding: Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To: Message-ID:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=n4qL0wkFUokv28LVCfjtRn4sS2fJvgjGgwUJwk1D3uk=; b=nkljZgUDqjJqSS3qFSTi7V2hI 1kjbi/zjPHy2ql9ei/V5pOqf2EYPtgCzgt+AU2c9CapXw3wjUcIHPaJFvC9gT3TOaIQUNQZYQu1pa yBWGrI7u0di1Ekj9fCneFxKFP1k8Lhts1MOhhAeik9L7p1uHHjkDs9RPWe8bdP1+ZsCMY0Dsg/Q7Y 8Fh8YQyw1dcAcLCCgXnc+pUOwwQiCKs96KGEK8Ly//DCnSqDeiAmM5bWaCkeY1j6Utvrn0AvkQzSW 49HaN3LO7iEBueMcfvmiqqrPEnZIldF8txMfs1ZBXBt5zSNxvWXjN8MRcazwdZHf0u9TsGBtlWXPX BGQFTbung==; Received: from localhost ([127.0.0.1] helo=twosheds.infradead.org) by twosheds.infradead.org with esmtp (Exim 4.89 #1 (Red Hat Linux)) id 1edELy-0008VM-SK; Sun, 21 Jan 2018 12:04:03 +0000 Received: from 86.142.97.146 (SquirrelMail authenticated user dwmw2) by twosheds.infradead.org with HTTP; Sun, 21 Jan 2018 12:04:03 -0000 Message-ID: <477cc452f17665440978ae1e227861ca.squirrel@twosheds.infradead.org> In-Reply-To: <20180121112224.GH2269@hirez.programming.kicks-ass.net> References: <1516476182-5153-1-git-send-email-karahmed@amazon.de> <1516476182-5153-5-git-send-email-karahmed@amazon.de> <20180121112224.GH2269@hirez.programming.kicks-ass.net> Date: Sun, 21 Jan 2018 12:04:03 -0000 Subject: Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process From: "David Woodhouse" To: "Peter Zijlstra" , hjl.tools@gmail.com Cc: "KarimAllah Ahmed" , linux-kernel@vger.kernel.org, "Andi Kleen" , "Andrea Arcangeli" , "Andy Lutomirski" , "Arjan van de Ven" , "Ashok Raj" , "Asit Mallick" , "Borislav Petkov" , "Dan Williams" , "Dave Hansen" , "David Woodhouse" , "Greg Kroah-Hartman" , "H . Peter Anvin" , "Ingo Molnar" , "Janakarajan Natarajan" , "Joerg Roedel" , "Jun Nakajima" , "Laura Abbott" , "Linus Torvalds" , "Masami Hiramatsu" , "Paolo Bonzini" , =?utf-8?B?IlJhZGltIEtyxI1tw6HFmSI=?= , "Thomas Gleixner" , "Tim Chen" , "Tom Lendacky" , kvm@vger.kernel.org, x86@kernel.org User-Agent: SquirrelMail/1.4.22-21.fc27 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SRS-Rewrite: SMTP reverse-path rewritten from by twosheds.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Sat, Jan 20, 2018 at 08:22:55PM +0100, KarimAllah Ahmed wrote: >> From: Tim Chen >> >> Flush indirect branches when switching into a process that marked >> itself non dumpable. This protects high value processes like gpg >> better, without having too high performance overhead. > > So if I understand it right, this is only needed if the 'other' > executable itself is susceptible to spectre. If say someone audited gpg > for spectre-v1 and build it with retpoline, it would be safe to not > issue the IBPB, right? Spectre V2 not v1. V1 is separate. For V2 retpoline is enough... as long as all the libraries have it too. > So would it make sense to provide an ELF flag / personality thing such > that userspace can indicate its spectre-safe? Yes, Arjan and I were pondering that yesterday; it probably does make sense. Also for allowing a return to userspace after vmexit, if the army process itself is so marked. > I realize that this is all future work, because so far auditing for v1 > is a lot of pain (we need better tools), but would it be something that > makes sense in the longer term? It's *only* retpoline so it isn't actually that much. Although I'm wary of Cc'ing HJ on such thoughts because he seems to never sleep and always respond promptly with "OK I did that... " :) If we did systematically do this in userspace we'd probably want to do external thunks there too, and a flag in the auxvec to tell it not to bother (for IBRS_ALL etc.). -- dwmw2