From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1516764326; cv=none; d=google.com; s=arc-20160816; b=XnDSVAIwNGqr0EHtaA81xog4rJbj74PxnRTjDK9q6G1xnIUsfhIAPH9qeBmtaBepal NQU3kB1RFBMY/5GRi9wfa8963DemwFzZCAYC82aqXxrJfmbLSCN7gJQuMjc20IkCeicx DZD0Ph4OTXYAZYaNJGPbDM2H46VblviDyWrlQGoIddUpqbcTL911tDqQH8ImaX+traxR TVRdxwUX6LaC7hAUiwI6C2H32kY4MmtHGAQuPOqfMIFwlqi7ckL9hpucyjuTmjPo7+6W xwOvQBNl22RMeEXvCDlS7Fyd+x+T3z1agBaYN6HvpndzJrEX3/wSf3/CzWKjGrPe0Ina N0xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:dkim-signature :arc-authentication-results; bh=yROzYF2uM1OOdD/kE130jwgU8KbkunESIOykxpLgrbU=; b=Ehkb//6d4kemQFpcOtCaTWBa57mbzMpu+sOsIo0owR3bCJqizwOCwRoTqcVS1oZAmI B5IjbfHEuiKzDm1f/Z5GSQMc3/PAvhO3wo1aCRreA251xQcRQ3cwXmmEF68+40t9nvd6 owVyygsRWWdZxyahcD4JptfqtUzD8V8l2jB9EV6XkEfg9faDPyXGewYJ7zkmkDXu7ChN qDUR5xhCFfP2obAgIAlPSQCqVX4LfaUjj3LJVMWC9577tyxQYvUIJpPN/v7M1zyTgBAX JCBvYFYo52jtk/t3WiAPhIl/8vbRyhlgjZtm+KPXl93yjr+lrMQym95/i19ZpiGIYaWs c7jw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=FCIoL8Bh; spf=pass (google.com: domain of luto@amacapital.net designates 209.85.220.41 as permitted sender) smtp.mailfrom=luto@amacapital.net Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=FCIoL8Bh; spf=pass (google.com: domain of luto@amacapital.net designates 209.85.220.41 as permitted sender) smtp.mailfrom=luto@amacapital.net X-Google-Smtp-Source: AH8x226keCZw/1FN/rLGeKKIK6M4IBv0EUktBn2mDjIYB0LQL2zrWaBEEGLNszqI6smaNrMWRwP6cw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation From: Andy Lutomirski X-Mailer: iPhone Mail (15C202) In-Reply-To: <0575AF4FD06DD142AD198903C74E1CC87A5F0AC5@ORSMSX103.amr.corp.intel.com> Date: Tue, 23 Jan 2018 19:25:23 -0800 Cc: Andy Lutomirski , Tim Chen , "Woodhouse, David" , Andi Kleen , Tom Lendacky , KarimAllah Ahmed , LKML , Andrea Arcangeli , Arjan van de Ven , "Raj, Ashok" , "Mallick, Asit K" , Borislav Petkov , "Williams, Dan J" , "Hansen, Dave" , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , "Nakajima, Jun" , Laura Abbott , Linus Torvalds , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , =?utf-8?Q?Radim_Krcm=C3=A1r?= , Thomas Gleixner , kvm list , X86 ML Content-Transfer-Encoding: quoted-printable Message-Id: 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> <0575AF4FD06DD142AD198903C74E1CC87A5F0AC5@ORSMSX103.amr.corp.intel.com> To: "Van De Ven, Arjan" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140582166248265?= X-GMAIL-MSGID: =?utf-8?q?1590442670014407954?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: > On Jan 23, 2018, at 5:59 PM, Van De Ven, Arjan wrote: >=20 >=20 >>> 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 befor= e >>> starting to run, and have STIBP set while running. >>>=20 >>=20 >> 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. >=20 > eventually we need something better. Probably in addition. > dumpable is used today for things that want this. >=20 >>=20 >> Also, what's the performance hit of STIBP? >=20 > pretty steep, but it depends on the CPU generation, for some it's cheaper t= han others. (yes I realize this is a vague answer, but the range is really f= rom just about zero to oh my god) >=20 > I'm not a fan of doing this right now to be honest. We really need to not p= iece meal some of this, and come up with a better concept of protection on a= higher level. > For example, you mention web browsers, but the threat model for browsers i= s generally internet content. For V2 to work you need to get some "evil poin= ter" into the app from the observer and browsers usually aren't doing that. > The most likely user would be some software-TPM-like service that has magi= c keys. >=20 > And for keys we want something else... we want an madvice() sort of thing t= hat does a few things, like equivalent of mlock (so the key does not end up i= n swap), I'd love to see a slight variant: encrypt that page against some ephemeral k= ey if it gets swapped. > not having the page (but potentially the rest) end up in core dumps, and t= he kernel making sure that if the program exits (say for segv) that the key p= age gets zeroed before going into the free pool. Once you do that as feature= , making the key speculation safe is not too hard (intel and arm have cpu op= tions to mark pages for that) >=20 >=20 How do we do that on Intel? Make it UC?=