From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226wSodMSHDqXRSPKb/SE9wZcpY3EYhzithYShDApXMDjvmZsf4HHFYObEdE/CuH/ohScgdE ARC-Seal: i=1; a=rsa-sha256; t=1516755671; cv=none; d=google.com; s=arc-20160816; b=d5VS1KsxYLwGDo02t7po2LfzyZFiuJFu11nSAS5eL94G61a1pFyGN5kIPjxpvhsM/W 3BCEvVny2MLcZ2kvROHSuwyoQ6rfmzYHRGHlEmsjhQUI6z2JsWqVu9c6zDdFN0emavdu 4EHAjV8wa16KezNG8WuuIdUM7W2g5Scvd5ySiObflgGDiY5a+2IBQGVM9Pm9LK/do3ZD x63vBiz1vCyISQlcMQdjxwDnIqVtI9FBbuMl/DjsWoofytCMZLiBHx1tsf2ADh9Dy05o U2h8eWKDiVs8EbxGuv2UkixjPdALWrH4WC0ALysVTmGQip6eKqGzTJpPG2RmNkP9Zbs/ trfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dmarc-filter:arc-authentication-results; bh=Hf1/tALYn7B2gp7FpWsIQ8tazl1Sr3gcHAP2/YduOaU=; b=n1uEvj9SxGSXvYLQgdJXBGHld14LURVeqNPEv5NY7pqXSN9zGzaxaMtydGkQm5BASu 7FhD4e6SzIEJOA0wqfivmcsvkZOahk42T4HWP0YGJYq1xNZG8yYk8E3YMZpAmnT0JCkK bjzL9JwML5MmUydfFWY3/t32wkoiBfxHHr9Y3Q5kYJMWMJjydE5RHSFIuvwHLHmmlP5m qYueOlsl4Q/h9SFnHtFMaWJgJRDrZ3vy4T9UKQUo6D4Wit8qui4m1JCYf5wSOJL7oRJd JClJAZwhOG7h6xbhfTv+Bby0uDPezQ91yMV5K1VTzx+jAfUj8FZlOMXUCvJWpH8NlBjO k8HQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3D732178E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org MIME-Version: 1.0 In-Reply-To: References: <1516476182-5153-1-git-send-email-karahmed@amazon.de> <1516476182-5153-10-git-send-email-karahmed@amazon.de> <243BE571-AF73-44B3-8D17-193F9E07686A@amacapital.net> <4e01a7a9-29e4-adcc-3f53-550fb7f3d370@amd.com> <1516724457.9521.156.camel@amazon.co.uk> <20180123224956.GQ7844@tassilo.jf.intel.com> <1516749276.13558.25.camel@amazon.co.uk> From: Andy Lutomirski Date: Tue, 23 Jan 2018 17:00:49 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation To: Tim Chen Cc: "Woodhouse, David" , Andi Kleen , Tom Lendacky , KarimAllah Ahmed , LKML , 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 , Linus Torvalds , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Thomas Gleixner , kvm list , X86 ML , Arjan Van De Ven Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140582166248265?= X-GMAIL-MSGID: =?utf-8?q?1590433594821971791?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Tue, Jan 23, 2018 at 4:47 PM, Tim Chen wrote: > On 01/23/2018 03:14 PM, Woodhouse, David wrote: >> On Tue, 2018-01-23 at 14:49 -0800, Andi Kleen wrote: >>>> Not sure. Maybe to start, the answer might be to allow it to be set for >>>> the ultra-paranoid, but in general don't enable it by default. Having it >>>> enabled would be an alternative to someone deciding to disable SMT, since >>>> that would have even more of a performance impact. >>> >>> I agree. A reasonable strategy would be to only enable it for >>> processes that have dumpable disabled. This should be already set for >>> high value processes like GPG, and allows others to opt-in if >>> they need to. >> >> That seems to make sense, and I think was the solution we were >> approaching for IBPB on context switch too, right? >> >> Are we generally agreed on dumpable as the criterion for both of those? >> > > It is a reasonable approach. Let a process who needs max security > opt in with disabled dumpable. It can have a flush with IBPB clear before > starting to run, and have STIBP set while running. > Do we maybe want a separate opt in? I can easily imagine things like web browsers that *don't* want to be non-dumpable but do want this opt-in. Also, what's the performance hit of STIBP?