From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42D9FC433DB for ; Thu, 18 Mar 2021 12:32:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AD39F64F45 for ; Thu, 18 Mar 2021 12:32:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD39F64F45 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=alien8.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 24F6D6B0072; Thu, 18 Mar 2021 08:32:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D7C36B0073; Thu, 18 Mar 2021 08:32:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 051046B0074; Thu, 18 Mar 2021 08:32:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id D983C6B0072 for ; Thu, 18 Mar 2021 08:32:19 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 91D13879E for ; Thu, 18 Mar 2021 12:32:19 +0000 (UTC) X-FDA: 77932932798.07.83E3DED Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf30.hostedemail.com (Postfix) with ESMTP id 8F280E0011C3 for ; Thu, 18 Mar 2021 12:32:18 +0000 (UTC) Received: from zn.tnic (p200300ec2f0fad00d75c69f143849f33.dip0.t-ipconnect.de [IPv6:2003:ec:2f0f:ad00:d75c:69f1:4384:9f33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 9860B1EC0588; Thu, 18 Mar 2021 13:32:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1616070736; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=KdZxGoW8E0Yb5R2XGKQeoZI3CfwvnJolse9Jj5h06wE=; b=VsgEwR4JlwvnISKDyXBK4k1m8sJNVs/L68IqL3bCPBrkf+EIhE+ttIW3o/P38FXupadupf CE8Tnk/w/6ekC2/AlPi0WMFZnmzeAvyF5fvJ95lzz9hclGDFVS1bY7sXdl8t7s0D006jnu ije1CeCZz37FiV3dDdTflsP+aw0Xgmo= Date: Thu, 18 Mar 2021 13:32:15 +0100 From: Borislav Petkov To: Yu-cheng Yu Cc: x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang , Pengfei Xu , Haitao Huang Subject: Re: [PATCH v23 22/28] x86/cet/shstk: User-mode shadow stack support Message-ID: <20210318123215.GE19570@zn.tnic> References: <20210316151054.5405-1-yu-cheng.yu@intel.com> <20210316151054.5405-23-yu-cheng.yu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210316151054.5405-23-yu-cheng.yu@intel.com> X-Stat-Signature: arxxs5i38dqq8f4xpzcoseojy9s73t5e X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8F280E0011C3 Received-SPF: none (alien8.de>: No applicable sender policy available) receiver=imf30; identity=mailfrom; envelope-from=""; helo=mail.skyhub.de; client-ip=5.9.137.197 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616070738-930159 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > Subject: Re: [PATCH v23 22/28] x86/cet/shstk: User-mode shadow stack support ^ Add On Tue, Mar 16, 2021 at 08:10:48AM -0700, Yu-cheng Yu wrote: > Introduce basic shadow stack enabling/disabling/allocation routines. > A task's shadow stack is allocated from memory with VM_SHSTK flag and has > a fixed size of min(RLIMIT_STACK, 4GB). > > Signed-off-by: Yu-cheng Yu > Reviewed-by: Kees Cook > --- > arch/x86/include/asm/cet.h | 28 ++++++ > arch/x86/include/asm/processor.h | 5 ++ > arch/x86/kernel/Makefile | 2 + > arch/x86/kernel/cet.c | 147 +++++++++++++++++++++++++++++++ Yeah, since Peter wants stuff split, let's call that shstk.c and the IBT stuff goes into a separate ibt.c please. > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h > index dc6d149bf851..3fce5062261b 100644 > --- a/arch/x86/include/asm/processor.h > +++ b/arch/x86/include/asm/processor.h > @@ -27,6 +27,7 @@ struct vm86; > #include > #include > #include > +#include > > #include > #include > @@ -535,6 +536,10 @@ struct thread_struct { > > unsigned int sig_on_uaccess_err:1; > > +#ifdef CONFIG_X86_CET > + struct cet_status cet; struct shstk_desc shstk; or so. > +int cet_setup_shstk(void) > +{ > + unsigned long addr, size; > + struct cet_status *cet = ¤t->thread.cet; > + > + if (!static_cpu_has(X86_FEATURE_SHSTK)) cpu_feature_enabled > + return -EOPNOTSUPP; > + > + size = round_up(min(rlimit(RLIMIT_STACK), 1UL << 32), PAGE_SIZE); ^ SZ_4G > + addr = alloc_shstk(size, 0); > + ^ Superfluous newline. > + if (IS_ERR_VALUE(addr)) > + return PTR_ERR((void *)addr); > + > + cet->shstk_base = addr; > + cet->shstk_size = size; > + > + start_update_msrs(); > + wrmsrl(MSR_IA32_PL3_SSP, addr + size); > + wrmsrl(MSR_IA32_U_CET, CET_SHSTK_EN); > + end_update_msrs(); > + return 0; > +} > + > +void cet_disable_shstk(void) > +{ > + struct cet_status *cet = ¤t->thread.cet; > + u64 msr_val; > + > + if (!static_cpu_has(X86_FEATURE_SHSTK) || cpu_feature_enabled And put the || on the end of each line: if (!cpu_feature_enabled() || !cet->shstk_size || ... ) > + !cet->shstk_size || !cet->shstk_base) > + return; > + > + start_update_msrs(); > + rdmsrl(MSR_IA32_U_CET, msr_val); > + wrmsrl(MSR_IA32_U_CET, msr_val & ~CET_SHSTK_EN); > + wrmsrl(MSR_IA32_PL3_SSP, 0); > + end_update_msrs(); > + > + cet_free_shstk(current); > +} Put that function under cet_free_shstk(). > +void cet_free_shstk(struct task_struct *tsk) > +{ > + struct cet_status *cet = &tsk->thread.cet; > + > + if (!static_cpu_has(X86_FEATURE_SHSTK) || cpu_feature_enabled and as above. > + !cet->shstk_size || !cet->shstk_base) > + return; > + > + if (!tsk->mm || tsk->mm != current->mm) > + return; You're operating on current here merrily but what's protecting all those paths operating on current from getting current changed underneath them due to scheduling? IOW, is preemption safely disabled in all those paths ending up here? > + > + while (1) { Uuh, an endless loop. What guarantees we'll exit it relatively timely... > + int r; > + > + r = vm_munmap(cet->shstk_base, cet->shstk_size); > + > + /* > + * Retry if mmap_lock is not available. > + */ > + if (r == -EINTR) { > + cond_resched(); ... that thing? > + continue; > + } > + > + WARN_ON_ONCE(r); > + break; > + } > + > + cet->shstk_base = 0; > + cet->shstk_size = 0; > +} > -- > 2.21.0 > -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette