From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBouyBy9grTRoWW+xpkVyWpPP828536LEbZVdbtFcNMrswHBs/XONfEL0gKL9b10HOKBg67oC ARC-Seal: i=1; a=rsa-sha256; t=1516302526; cv=none; d=google.com; s=arc-20160816; b=DPXvUZr+h+1W0hcYUTzQkeCBGzkCU093sRm9Wp3L0WCPKZMtklhcB4gakm9eZX8E7Z /xgHTnwT1U6GTy7Ii6mzY/6Xn+DbB/O+UJ3zEX6cBhlbmNATpqmOa4T9ulH025FQAMmk Xnd35hKzwi82KmRrc5NZ0DCjpsBW5eFmdEGGop6PyGvqdAffAG61xxRk68D+Te4J7Edk Sy4ZgDmQz5NLMsJ/l+Ry0+FabCrT4HoJO0QM36DFiwt0u+/cVR6p4p9CAF7GpN6UdF8Q y04egqIeNCxKvTWbQoBbx1SOH9oJqxIGJl0GYZI0y9cop89VzfWFuOtZcefhXigQzWwT WgQQ== 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:arc-authentication-results; bh=LAHzu4RT45cMLJ5vmAmmxiEH/HPN+VAbsgaU7JoJY2M=; b=K9kSYG12jA6L5ECgl6E7RRZIyc7dIb7EXKalIrDVLgssGXVessALaQksdHEXAbMO8M /Z/TTP5rfJUHqx3KbUDrDgwbKh1VFc6yjkcn8phqLY8mGjpF3Br7guWqDFc7NJWdNN3O kQM4G3ADR1XJGnNDP9ISnN1EILfikJVbLmlRm1ymU4lxrPbtMAXQcGFXhgrLBhrWWEHF YCCXc0rdgGX34wdcAs5zkQcG3qF9auCyVWh9xEV/1bjxK7ReJvw7jxTXLi7sn+kvM317 DLHOJCb8PdlHKnH41C8BR/IWJFotQz0FFON1Sw5yiax+JGH2LKxegVgmdMs/TG8b9OXe 5uOA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of aarcange@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=aarcange@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of aarcange@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=aarcange@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Date: Thu, 18 Jan 2018 20:08:42 +0100 From: Andrea Arcangeli To: Josh Poimboeuf Cc: Paolo Bonzini , Dave Hansen , Peter Zijlstra , David Woodhouse , Thomas Gleixner , linux-kernel@vger.kernel.org, Ashok Raj , Tim Chen , Andy Lutomirski , Linus Torvalds , Greg KH , Andi Kleen , Arjan Van De Ven , Dan Williams , Jun Nakajima , Asit Mallick , Jason Baron Subject: Re: [PATCH 23/35] x86/speculation: Add basic speculation control code Message-ID: <20180118190842.GA14136@redhat.com> References: <20180118134800.711245485@infradead.org> <20180118140152.830682032@infradead.org> <20180118163745.t5nmwdr53wjsl7o5@treble> <73a5735a-6a5b-0e0f-1f0b-e7cd955880d2@intel.com> <20180118182431.xvmk6kzxpzu43b43@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180118182431.xvmk6kzxpzu43b43@treble> User-Agent: Mutt/1.9.2 (2017-12-15) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-LABELS: =?utf-8?b?IlxcSW1wb3J0YW50Ig==?= X-GMAIL-THRID: =?utf-8?q?1589948948566960870?= X-GMAIL-MSGID: =?utf-8?q?1589958438441079486?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Thu, Jan 18, 2018 at 12:24:31PM -0600, Josh Poimboeuf wrote: > On Thu, Jan 18, 2018 at 06:12:36PM +0100, Paolo Bonzini wrote: > > On 18/01/2018 18:08, Dave Hansen wrote: > > > On 01/18/2018 08:37 AM, Josh Poimboeuf wrote: > > >>> > > >>> --- a/Documentation/admin-guide/kernel-parameters.txt > > >>> +++ b/Documentation/admin-guide/kernel-parameters.txt > > >>> @@ -3932,6 +3932,7 @@ > > >>> retpoline - replace indirect branches > > >>> retpoline,generic - google's original retpoline > > >>> retpoline,amd - AMD-specific minimal thunk > > >>> + ibrs - Intel: Indirect Branch Restricted Speculation > > >> Are there plans to add spectre_v2=ibrs_always to prevent SMT-based > > >> attacks? > > > > > > What does "ibrs_always" mean to you? > > Maybe ibrs_always isn't the best name. Basically we need an option to > protect user-user attacks via SMT. > > It could be implemented with IBRS=1, or STIBP, or as part of the > mythical IBRS_ATT. User stibp or user ibrs would be different things, both would be valid for different use cases, and the user stibp should perform better. Leaving ibrs on when returning from kernel to userland (or setting ibrs if kernel used retpolines instead of ibrs) achieves stronger semantics than just setting SPEC_CTRL with stibp when returning to userland. That is true no matter if kernel is using retpolines or ibrs. IBRS is semantically equivalent to "STIBP; IBPB", so user_ibrs is always inclusive of user_stibp. Said that the CPU should better achieve such semantics without really internally issuing an IBPB of course, but you can think at the current IBRS as "STIBP; IBPB". That IBPB immediately after the STIBP makes a difference to the non HT attacks possible on host userland. user_smt wouldn't solve all cases that user_ibrs solves, but it'd be ideal if critical user apps are built with retpolines and the only concern left is a HT/SMT attack on those only need to care about HT/SMT. To begin with, user_ibrs would be more important than user_stibp. On a side note: stibp isn't always available, it requires a new cpuid check on bit 27 too, you can still write to it but it won't #gp, on some CPUs it's simply implicit and you can write to it, but it's a noop. I haven't figured exactly to differentiate when it's disabled or implicitly enabled when not enumerated in cpuid.