Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp613729ybk; Wed, 13 May 2020 08:32:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyTqKMCw5FbhGIlfENhlHXfuhS+C76BCeqYI7VFAhg6786cV7mDvJbTyzxL/kP97bZMIwcQ X-Received: by 2002:a05:6402:22d9:: with SMTP id dm25mr200089edb.380.1589383932678; Wed, 13 May 2020 08:32:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589383932; cv=none; d=google.com; s=arc-20160816; b=xlxcMWB5bAiTJaKT/2UcyDEJPzhQW/uDl7FAy3RnVME2N5ETZnlVFRBT5DP+I6q0W/ y1Gs6IGjTJ6qmedUmPtPrKH/54op8HsJWNbfGMHSZmp92pbza8740H+GvVW3Shc/N25N G6sD0YwOWXT9aCBapG/29QvmSgv1Ir2bwEnQVe3tDnTlO+yGUAdUfAUteXqgDEC7GEYR WaD/FpGc0EWx5nZyn/4Ec+ic1JO8k/LeeaWMaIIQr/sw4guwIHGIUXHzvqDQb2BTkMX9 IpBRN+f8/Xclt9QyM1jPbl4QQXmX0Bu2qXLtb4kUDwlKb2VFPSjbKXfFfYXZLGWut/Tp wl5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=RGGuIpb+EhzJC2FtJOaLaY15svV998FS41Wf609FNQk=; b=KbewQF2xKirJii1Z0QNBd/ZFQUdzOpQ7jAf65GM4P5jadm1g31eQBIRflm0mTtBoYV fladPlwV0tkezVTvV+ikjBPGcJY3hUxSBaMGBWydOeqnoqHPoPVny37WDiBZ8uYXrBPS z/YbEzmi4CK6G/vbsnFWBLSI+MFNjyDg1IKQXt8AoYbmxoJfJR1umY38Htyqsyzro6Zz GyCpUUns5m92jLl9CrnhHXrazBpfxb6RPNkgZmXitOhlNfsOPHyGUheNxFIEVlVu7jVw WCxtQn7jyoW2OnJBrCVaRYftg6sW5DD1xH+lYLsYP38L1UdcZqJVKNvVlO7Vo6xvsvGq ltow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r22si1068769edm.199.2020.05.13.08.31.49; Wed, 13 May 2020 08:32:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731154AbgEMP2H (ORCPT + 99 others); Wed, 13 May 2020 11:28:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729257AbgEMP2G (ORCPT ); Wed, 13 May 2020 11:28:06 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BFD42C061A0C for ; Wed, 13 May 2020 08:28:06 -0700 (PDT) Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jYtIX-0007C3-Pu; Wed, 13 May 2020 17:27:53 +0200 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 3D63D100605; Wed, 13 May 2020 17:27:53 +0200 (CEST) From: Thomas Gleixner To: Balbir Singh , linux-kernel@vger.kernel.org Cc: jpoimboe@redhat.com, tony.luck@intel.com, keescook@chromium.org, benh@kernel.crashing.org, x86@kernel.org, dave.hansen@intel.com, thomas.lendacky@amd.com, Balbir Singh Subject: Re: [PATCH v6 5/6] Optionally flush L1D on context switch In-Reply-To: <20200510014803.12190-6-sblbir@amazon.com> References: <20200510014803.12190-1-sblbir@amazon.com> <20200510014803.12190-6-sblbir@amazon.com> Date: Wed, 13 May 2020 17:27:53 +0200 Message-ID: <878shv3ldy.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Balbir Singh writes: > Implement a mechanism to selectively flush the L1D cache. The goal is to > allow tasks that are paranoid due to the recent snoop assisted data sampling > vulnerabilites, to flush their L1D on being switched out. This protects > their data from being snooped or leaked via side channels after the task > has context switched out. > > There are two scenarios we might want to protect against, a task leaving > the CPU with data still in L1D (which is the main concern of this patch), > the second scenario is a malicious task coming in (not so well trusted) > for which we want to clean up the cache before it starts. Only the case > for the former is addressed. > > A new thread_info flag TIF_SPEC_FLUSH_L1D is added to track tasks which > opt-into L1D flushing. cpu_tlbstate.last_user_mm_spec is used to convert > the TIF flags into mm state (per cpu via last_user_mm_spec) in > cond_mitigation(), which then used to do decide when to call flush_l1d(). > > Add prctl()'s to opt-in to the L1D cache on context switch out, the > existing mechanisms of tracking prev_mm via cpu_tlbstate is > reused to track state of the tasks and to flush the L1D cache. > The prctl interface is generic and can be ported over to other > architectures. > > Suggested-by: Thomas Gleixner > Signed-off-by: Balbir Singh > Reviewed-by: Kees Cook > --- > arch/x86/include/asm/thread_info.h | 7 ++++- > arch/x86/mm/tlb.c | 44 ++++++++++++++++++++++++++++-- > include/uapi/linux/prctl.h | 4 +++ > kernel/sys.c | 20 ++++++++++++++ > 4 files changed, 72 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thread_info.h > index 8de8ceccb8bc..67de693d9ba1 100644 > --- a/arch/x86/include/asm/thread_info.h > +++ b/arch/x86/include/asm/thread_info.h > @@ -84,7 +84,7 @@ struct thread_info { > #define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */ > #define TIF_SECCOMP 8 /* secure computing */ > #define TIF_SPEC_IB 9 /* Indirect branch speculation mitigation */ > -#define TIF_SPEC_FORCE_UPDATE 10 /* Force speculation MSR update in context switch */ > +#define TIF_SPEC_FLUSH_L1D 10 /* Flush L1D on mm switches (processes) */ > #define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return */ > #define TIF_UPROBE 12 /* breakpointed or singlestepping */ > #define TIF_PATCH_PENDING 13 /* pending live patching update */ > @@ -96,6 +96,7 @@ struct thread_info { > #define TIF_MEMDIE 20 /* is terminating due to OOM killer */ > #define TIF_POLLING_NRFLAG 21 /* idle is polling for TIF_NEED_RESCHED */ > #define TIF_IO_BITMAP 22 /* uses I/O bitmap */ > +#define TIF_SPEC_FORCE_UPDATE 23 /* Force speculation MSR update in context switch */ > #define TIF_FORCED_TF 24 /* true if TF in eflags artificially */ > #define TIF_BLOCKSTEP 25 /* set when we want DEBUGCTLMSR_BTF */ > #define TIF_LAZY_MMU_UPDATES 27 /* task is updating the mmu lazily */ > @@ -132,6 +133,7 @@ struct thread_info { > #define _TIF_ADDR32 (1 << TIF_ADDR32) > #define _TIF_X32 (1 << TIF_X32) > #define _TIF_FSCHECK (1 << TIF_FSCHECK) > +#define _TIF_SPEC_FLUSH_L1D (1 << TIF_SPEC_FLUSH_L1D) Bah. These defines are ordered in the same way as the TIF defines.... > /* > - * Bits to mangle the TIF_SPEC_IB state into the mm pointer which is > + * Bits to mangle the TIF_SPEC_* state into the mm pointer which is > * stored in cpu_tlb_state.last_user_mm_spec. > */ > #define LAST_USER_MM_IBPB 0x1UL > -#define LAST_USER_MM_SPEC_MASK (LAST_USER_MM_IBPB) > +#define LAST_USER_MM_L1D_FLUSH 0x2UL > +#define LAST_USER_MM_SPEC_MASK (LAST_USER_MM_IBPB | LAST_USER_MM_L1D_FLUSH) You lost + BUILD_BUG_ON(TIF_SPEC_FLUSH_L1D != TIF_SPEC_IB + 1); from patch I gave you.