Received: by 10.223.176.5 with SMTP id f5csp1771591wra; Sun, 4 Feb 2018 11:42:26 -0800 (PST) X-Google-Smtp-Source: AH8x227nA3AjrT0MmQExSypIPUqFQWHCUAdv0QZE0rtkFqJXdJSp6ci2aEorheVo+8sb2Qfpfwrd X-Received: by 10.98.58.11 with SMTP id h11mr5712452pfa.65.1517773346502; Sun, 04 Feb 2018 11:42:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517773346; cv=none; d=google.com; s=arc-20160816; b=kMxvWj8P6+Wi3pyDNrsoTHxCsgnyCLPM96jXt5Cq8KA3y6Lsfv7QG8Idy9OVaJ5zor coVMElidRloQoheyd02Pz/M53Y9hQz1bXMt6CGoDVd5u5ODu7rH6dlLWpWTberM2IkIW yBkhGgZI2aqHCRbn2+O4AMI6jHLj8tpbk24jHcRF9cE/Up0uo0x5XUJWVEckOYrgp4qC M25rnKpJ0r7K8t26sqkcMmruIDNZ7Vt9Vp1V9gzWOcjmBXMSQo7mCwdxpe9aMy918P5z arLft1qz1N9/XyBDJf0H/ALIUBV0gMTO4rqUv+jGKw+T/n2SHikPd2BiuxVBiUEf2TU8 coUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :message-id:subject:cc:to:from:date:arc-authentication-results; bh=AkMIERttXWK4WNHNk0+Hqbq+aRESUgYMpYo8aqtPSBo=; b=VVH6Vx5aqY5AI0vDqkNn+I7KcQ9yQoQsLVO3ncn7ZRvKGHKhOkgN4drxOJJlm3prV0 mrRwZ7z3PLk0TCctuMF/b0iWXZW/6EI1SICcNdrvsY21fQqEag2uG8uJx7FsaB4Ez13B CJ/XWG9P7yODs0cSId8tUQwwHLqwNxiglxSwH1Vk63uo0LbOLjHVov0DULnu6ron0Tk0 BXv+xdMElSEljaVOZRhhyYsP0M28K0AkErC1BMGtbC/dGuT30LLqu9xrTr+u0vs9RDEN iTMOP+e57Lb75RY+Si9ASLQLLMrMsV2nF0zrLOTmHZpPoFDZz3P+5sN82gWIjvnGtIa6 njRg== ARC-Authentication-Results: i=1; mx.google.com; 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 s6si4530985pgr.775.2018.02.04.11.42.11; Sun, 04 Feb 2018 11:42:26 -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; 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 S1752485AbeBDTl2 (ORCPT + 99 others); Sun, 4 Feb 2018 14:41:28 -0500 Received: from isilmar-4.linta.de ([136.243.71.142]:32876 "EHLO isilmar-4.linta.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752241AbeBDTlW (ORCPT ); Sun, 4 Feb 2018 14:41:22 -0500 Received: from light.dominikbrodowski.net (isilmar.linta [10.0.0.1]) by isilmar-4.linta.de (Postfix) with ESMTPS id 390D52008F9; Sun, 4 Feb 2018 19:41:21 +0000 (UTC) Received: by light.dominikbrodowski.net (Postfix, from userid 1000) id 114B020745; Sun, 4 Feb 2018 20:39:02 +0100 (CET) Date: Sun, 4 Feb 2018 20:39:02 +0100 From: Dominik Brodowski To: David Woodhouse , Tim Chen Cc: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org, tglx@linutronix.de, jpoimboe@redhat.com, "Wieczorkiewicz, Pawel" , David Woodhouse , arjan@linux.intel.com, karahmed@amazon.de, x86@kernel.org, bp@alien8.de, peterz@infradead.org, pbonzini@redhat.com, ak@linux.intel.com, torvalds@linux-foundation.org, gregkh@linux-foundation.org, luto@kernel.org Subject: Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction Barrier in context switch Message-ID: <20180204193901.GA29757@light.dominikbrodowski.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2f5614a5-b7c4-52cf-a66f-6f62c2602bee@linux.intel.com> <1517473913.18619.281.camel@infradead.org> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 01, 2018 at 08:31:53AM +0000, David Woodhouse wrote: > On Wed, 2018-01-31 at 08:03 +0100, Dominik Brodowski wrote: > > Whether a process needs protection by IBPB on context switches is a > > different question to whether a process should be allowed to be dumped, > > though the former may be a superset of the latter. Enable IBPB on all > > context switches to a different userspace process, until we have a clear > > mitigation strategy for userspace against Spectre-v2 designed and > > implemented. > > > > ... > >                 if (tsk && tsk->mm && > > -                   tsk->mm->context.ctx_id != last_ctx_id && > > -                   get_dumpable(tsk->mm) != SUID_DUMP_USER) > > +                   tsk->mm->context.ctx_id != last_ctx_id) > >                         indirect_branch_prediction_barrier(); > > > I understand your argument and I sympathise. > > But that's going to hurt a *lot*, and we don't even have a viable > proof-of-concept for a user←→user Spectre v2 attack, do we? It's only > theoretical? Wasn't the PoC in the Spectre paper user←→user (though on a different OS)? And what makes KVM←→KVM so much more likely/dangerous/..., that IBPB will be done there unconditionally (AFAICS)? And, somewhat related, @Tim Chen: On Wed, Jan 31, 2018 at 03:25:44PM -0800, Tim Chen wrote: > For people who opt for more security, it is reasonable to consider > alternate policies to distinguish friend and foe so we know if we are coming > from a potentially hostile environment. Ptrace is one means to do so, and probably > there are other ways depending on usages. I hope we can have a discussion on what we should > use to determine if two processes are friend or foe. Say do all the processes > from the same containers are considered friends with each other? To my understanding, the concept of "containers" is meant to be kept outside of the kernel. What *namespaces* / *control groups* can be considered friends with each other? Thanks, Dominik