From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1516551707; cv=none; d=google.com; s=arc-20160816; b=F8O7zq2Wj5tLrjsj5NqMqjSCOF5tQyZR16tIbG256DxKfMyrgMewbjYpktlL7u52PQ 6R56GvVKt60qvLlm5UuGIcHsmG2XRx1ih7qdc4fMYPgyrotoTyXM/VVxYks2PsHZuDq2 3wZ/xJg0uSJqnUQFjXcAXgVRyuNK21PnLh94DidyADm0P/6WW4GrPhSY3XKdujCzMDSc tWIeEJDfmKj8wGC6ougKVCtO1eBtv9FBQEPXNkVyyhLkiZrBwO/noZpQ4Oj2qGRv9avA hBYaTXEK46gYL+aE7fPMlF2eOfeozVlrBZTPaxEjLdLVxfkwj/Pvzvis2HaSW9cgKSXE bASw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:sender:dkim-signature :arc-authentication-results; bh=KXzO8Dc9olaiayaRi5LBLIsI9aqZpM7rIf1l7f4xSsc=; b=kgdPTnfCc3U7c6csyC4Xkptr54NgFob7jQcmfSviK2VhwckddkjM90FJGXiMcchRjy ME0vCa2DE7VmLjX/idpSaNKcF62dcA03Ef6tf6Sts9e+iyS3N8fiKQcI0l1ED/opi6T5 IT48IPXxxf/m5+Q6/2GDZ3NfaVgvUqS69ZPdPbmOKqsbQ1MfuXs0Xo9E2ZyYfJ2bKtGS E4wPmB+zNL5C5Ij6SSf0LR7PU5etg4CVoSAitxrtSuQotUGrqbZMGHYA55nWa+SlddQ7 GNBmhQ6BOcUxAh1alCr/TdrvO1ozzsdQnBjKmPvTKZFgXFAw4u3czEy4yjfXV9fl+1KB RP3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NFte0gvO; spf=pass (google.com: domain of mingo.kernel.org@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NFte0gvO; spf=pass (google.com: domain of mingo.kernel.org@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com X-Google-Smtp-Source: AH8x227Zbs1Jmrb2AZUaWodHoQdMBoi6v562rqre6+THZXJve3RHR2ya3Xhd0UFjrDojZTOaV2Ucmw== Sender: Ingo Molnar 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) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140567714479425?= X-GMAIL-MSGID: =?utf-8?q?1590219722609263807?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: * 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