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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 DC267C433ED for ; Fri, 9 Apr 2021 23:14:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5189F610A6 for ; Fri, 9 Apr 2021 23:14:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5189F610A6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 871C56B0036; Fri, 9 Apr 2021 19:14:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 822396B006E; Fri, 9 Apr 2021 19:14:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69C146B0070; Fri, 9 Apr 2021 19:14:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0042.hostedemail.com [216.40.44.42]) by kanga.kvack.org (Postfix) with ESMTP id 4D90A6B0036 for ; Fri, 9 Apr 2021 19:14:15 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id EA87D18045D01 for ; Fri, 9 Apr 2021 23:14:14 +0000 (UTC) X-FDA: 78014384028.15.9EF0670 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf25.hostedemail.com (Postfix) with ESMTP id E400E600010E for ; Fri, 9 Apr 2021 23:14:11 +0000 (UTC) IronPort-SDR: cfRLWvDW6HQ8T4RO1nXL24fH3aiCXhtLxXSV4fODV6dhs/dtvo0pDKpodSgNMm9NBuB96cvh/W GOQD9N37rUnQ== X-IronPort-AV: E=McAfee;i="6000,8403,9949"; a="191708955" X-IronPort-AV: E=Sophos;i="5.82,210,1613462400"; d="scan'208";a="191708955" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Apr 2021 16:14:11 -0700 IronPort-SDR: Rs7zQ8aB0ZMvUycmEhQuydYbL7lqQgBkA3wFN0NTzubAov5AhJqpP0n+EbiE6x11UCLPnEfnO5 PvrqU4zxc37A== X-IronPort-AV: E=Sophos;i="5.82,210,1613462400"; d="scan'208";a="416460352" Received: from yyu32-mobl1.amr.corp.intel.com (HELO [10.212.27.140]) ([10.212.27.140]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Apr 2021 16:14:10 -0700 Subject: Re: [PATCH v24 04/30] x86/cpufeatures: Introduce X86_FEATURE_CET and setup functions To: Borislav Petkov 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 References: <20210401221104.31584-1-yu-cheng.yu@intel.com> <20210401221104.31584-5-yu-cheng.yu@intel.com> <20210409101214.GC15567@zn.tnic> <20210409171408.GG15567@zn.tnic> From: "Yu, Yu-cheng" Message-ID: Date: Fri, 9 Apr 2021 16:14:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210409171408.GG15567@zn.tnic> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: E400E600010E X-Stat-Signature: ms61fqi4uub5yqcmhbb179trsb5myg4j Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf25; identity=mailfrom; envelope-from=""; helo=mga04.intel.com; client-ip=192.55.52.120 X-HE-DKIM-Result: none/none X-HE-Tag: 1618010051-837106 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: On 4/9/2021 10:14 AM, Borislav Petkov wrote: > On Fri, Apr 09, 2021 at 08:52:52AM -0700, Yu, Yu-cheng wrote: >> Recall we had complicated code for the XSAVES features detection in >> xstate.c. Dave Hansen proposed the solution and then the whole thing >> becomes simple. Because of this flag, even when only the shadow stack is >> available, the code handles it nicely. > > Is that what you mean? > > @@ -53,6 +55,8 @@ static short xsave_cpuid_features[] __initdata = { > X86_FEATURE_INTEL_PT, > X86_FEATURE_PKU, > X86_FEATURE_ENQCMD, > + X86_FEATURE_CET, /* XFEATURE_CET_USER */ > + X86_FEATURE_CET, /* XFEATURE_CET_KERNEL */ > > or what is the piece which becomes simpler? Yes, this is it. >> Would this equal to only CONFIG_X86_CET (one Kconfig option)? In fact, when >> you proposed only CONFIG_X86_CET, things became much simpler. > > When you use CONFIG_X86_SHADOW_STACK instead, it should remain same > simple no? > Signals, arch_prctl, and ELF header are three places that need to depend on either shadow stack or IBT is configured. To remain simple, we can make all three depend on CONFIG_X86_SHADOW_STACK, and in Kconfig, make CONFIG_X86_IBT depend on CONFIG_X86_SHADOW_STACK. Without shadow stack, IBT itself is not as useful anyway. >> Practically, IBT is not much in terms of code size. Since we have already >> separated the two, why don't we leave it as-is. When people start using it >> more, there will be more feedback, and we can decide if one Kconfig is >> better? > > Because when we add stuff to the kernel, we add the simplest and > cleanest version possible and later, when we determine that additional > functionality is needed, *then* we add it. Not the other way around. > > Our Kconfig symbol space is already an abomination so we can't just add > some more and decide later. > > What happens in such situations usually is stuff gets added, it bitrots > and some poor soul - very likely a maintainer who has to mop up after > everybody - comes and cleans it up. I'd like to save myself that > cleaning up. > > Thx. >