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 C202CC43462 for ; Fri, 9 Apr 2021 23:14:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 93C6861074 for ; Fri, 9 Apr 2021 23:14:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235104AbhDIXO0 (ORCPT ); Fri, 9 Apr 2021 19:14:26 -0400 Received: from mga04.intel.com ([192.55.52.120]:31333 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234880AbhDIXOZ (ORCPT ); Fri, 9 Apr 2021 19:14:25 -0400 IronPort-SDR: 8FOQqofsNKjTpM0K517Jcfxc3KzuY1CThC/x+Z2quemPgcz9nj0ZV64O7HC7YFRWp9ffysRaHs cC8kQ2Cfc6tw== X-IronPort-AV: E=McAfee;i="6000,8403,9949"; a="191708954" X-IronPort-AV: E=Sophos;i="5.82,210,1613462400"; d="scan'208";a="191708954" 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. >