Received: by 10.223.176.46 with SMTP id f43csp1972762wra; Sun, 21 Jan 2018 08:22:27 -0800 (PST) X-Google-Smtp-Source: AH8x225r9uOWM3SxNdEkbSExImRlAS+jqo7zL9VGzk5nvhOuKxuAZkakpjCY3AYr4IKhoU7R+ZFx X-Received: by 10.98.59.80 with SMTP id i77mr5724750pfa.146.1516551747592; Sun, 21 Jan 2018 08:22:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516551747; cv=none; d=google.com; s=arc-20160816; b=SNxjTM02vl2upIs8SU80Keq5GU9UXVuDGfJzJaLufWKhQxLsP/RVzz/ZegdNr/wiSD UyZHtOZ4unhbBASPrjUxzY4tcNzVUmd8Nt26uiFsnV5efqw0DtM8Vkpk7V6UxVnjsRqa BYy3hXfAgY1ZvIi39Vly7arILdhplHw6VeDGDnav8a6VedMYa+AHhIGyznvDe06eCjsc 5tGuI6FMI9rillf7nKnFC7Pgkw5lfDIKyAUJKpPWPtFNiViwW4FKvZ2/E22YDnQ6jefO Nh5LVtAyxDk0TVXsL7vbBL/HiCSpezskakjvXjUEJIIUh3V2DWDaigzJce6I2RLCREGt +eiQ== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=KXzO8Dc9olaiayaRi5LBLIsI9aqZpM7rIf1l7f4xSsc=; b=qbB/iaNp7kW2HkAszv4QO64R2guCpi9NyQdJB6qSd9B5jNpydRnyWPs8AXwscHWaB0 MW2tEiTQa7D/guo/k/FXGAEUKaNJhCGOtFXttFQBgFKceMaFKe+S3wP6nQms43ljCV1E lfDWBFp4bETe3K/n8EZS4tLVKB2WhwgHpvMa4q1cgA3W1wCxsoTxYHeRHFL7O6RS6jFB uBhIycqKREO7UhHVKgf6+UzvFDtEg6GGYDdVC51ImFDD5iLppCT1rL+oHL1pVBPY73fL bzLquMJVB361F2AQDrdv1crnncs0CKIVTxIvpl4CyFLwJa7eLe34Okc0avHWtEesS9lv UTjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=NFte0gvO; 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 k9-v6si2635896pli.404.2018.01.21.08.22.12; Sun, 21 Jan 2018 08:22:27 -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=@gmail.com header.s=20161025 header.b=NFte0gvO; 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 S1751125AbeAUQVt (ORCPT + 99 others); Sun, 21 Jan 2018 11:21:49 -0500 Received: from mail-wr0-f193.google.com ([209.85.128.193]:35060 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750793AbeAUQVr (ORCPT ); Sun, 21 Jan 2018 11:21:47 -0500 Received: by mail-wr0-f193.google.com with SMTP id g38so5977226wrd.2; Sun, 21 Jan 2018 08:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KXzO8Dc9olaiayaRi5LBLIsI9aqZpM7rIf1l7f4xSsc=; b=NFte0gvOnRLFSsKHlSdnKsYlr5EViwTC0HSr9PSmU+3fcCO3U7Lb/0+qqNY1wd9qQh SoXRY+/8dprtrKtY3iPXmJpEYbB1hhTBIadOG82SpJqRq5SRldLF8goHvvFEfU3Ai2Pl 2uxZKDC3Uq4Gy/8k2ltnqkv4vwi70qLWX8HyoVyR5OpOOx0JNCODUxaKkAFc829Gal6X 70xPKeGxmcQ3Sv56Jh453EA0aHVsFnBTUGWNkgFFVAbiu9wCT6UiXiK+CdsYDp2eWVDQ ToKU0mIaWFYywzT4YpZ6Nuu89wLqERuJxqAmSY6l8cC/b7Ls/vSI89kjgJPLIMkMl9yO zDCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=KXzO8Dc9olaiayaRi5LBLIsI9aqZpM7rIf1l7f4xSsc=; b=PDvjlnSRfXZX9DE6dGnTx+WW6iGQA9JN2E70ukYxVwXleTOrjiDcYA7nlCbYZvdg6i yUeru8lcuY0Q1129htKXhkbGdeRMEVkAqcMjSvemgHRHTaWjAeAUZb9wDzN7U1biVBnl TRoKxDCxJ7ROBD8U4cVnIirlGLqgHFDDFS/cW0WppNp+BHQoGI4wT5g79VCpZ4q8O4zb N/sTi68UGpmVO+flIb3kEkbqOyfXgJtJJ5tEDCQKZkhfJhqVKiPoyYVdmR8yUqua3MB8 /DE3ymF/8w61GGawe+Bf8ppZfNFfTR3LAHT0KmfzDcp8/zFE7hmLMvHnIezMg0zEfhQT A8Nw== X-Gm-Message-State: AKwxytcXQEHnl2AMCpnYz4O8Za+DWKiUDLEqikcV2DnLuU6CkZoLKyFU APRl2x3/QK3zPhmUfgJlEN0= X-Received: by 10.223.138.178 with SMTP id y47mr3820357wry.257.1516551706307; Sun, 21 Jan 2018 08:21:46 -0800 (PST) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id h200sm2703245wme.11.2018.01.21.08.21.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 21 Jan 2018 08:21:45 -0800 (PST) Date: Sun, 21 Jan 2018 17:21:42 +0100 From: Ingo Molnar To: Peter Zijlstra 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 , Radim =?utf-8?B?S3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , kvm@vger.kernel.org, x86@kernel.org, Dave Hansen Subject: Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process Message-ID: <20180121162142.yh366un2blsyiud4@gmail.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180121112224.GH2269@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Peter Zijlstra wrote: > 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? > > So would it make sense to provide an ELF flag / personality thing such > that userspace can indicate its spectre-safe? > > 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? So if it's only about the scheduler barrier, what cycle cost are we talking about here? Because putting something like this into an ELF flag raises the question of who is allowed to set the flag - does a user-compiled binary count? If yes then it would be a trivial thing for local exploits to set the flag and turn off the barrier. Yes, we could make a distinction based on the owner of the file, we could use security labels, etc. - but it gets somewhat awkward and fragile. So unless we are talking about measurably high scheduler costs here, I'd prefer to err on the side of caution (and simplicity) and issue the barrier unconditionally. Thanks, Ingo