Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1515997pxf; Fri, 9 Apr 2021 10:14:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxC+LEi5Wo9xOfc4SiKDkVmi2XRzfB0dWA+w/DY3t7F6ICm0N+kK4Bu/4ULZFdJegPeKfVd X-Received: by 2002:a17:902:b598:b029:e7:147f:457 with SMTP id a24-20020a170902b598b02900e7147f0457mr13469526pls.68.1617988499124; Fri, 09 Apr 2021 10:14:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617988499; cv=none; d=google.com; s=arc-20160816; b=UobCcQJB3Sv5kSVYSSgd1FiXY9VuS5GS3vS4hLJynHPXRsZ3B2Ret54+f+Q3vsKSaQ M/nr2PFfz5p/l9DWCFNkEg3eg3ZcSyUoxeH60XZSPZIv0VTKB0lkBV/Q7NorfeA5/1yz d+ktca0DPkIfftgPtBGRh9d+tv+BdSx9f4OLaePmBjlztdS3nKXbjkZybUFqkJY7F7jX hdwZE17/zxjqtDiAAhruSpYfh3SLTBaRkDmd/Vbp5VJD6IvSWZAJUNtWduJb2BJQtaFY Up6eUTi79+4hcq1UtafZNkvMsG7zGUoclAoV/ZRr1jnFiXzf5l4cpd30PmRstPAS7Egv Sfkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=9AYjgxlvYEzX7lP0NtvpK9WeNVbzcrOcj1GyMO32N+8=; b=ClXEmsR1Q9wekNr0TZTRIaC3kIF0QBvtS6l/7sxEj9UCHSK4dF3f3A2E7uPY8uMCPa IuL5oJDWoHvizmiTDtLudsmra5reaQUDzQHTLowh8JEvUrXy3NZcCMQWH+qA51o6BAFl 9ntul2be9ctmATNaSbDJZNS2OAVx0w9OzVyRULXhwEHbLmJMMFQD4tvenZRoOms5y7nE d0OSiXeKfHUGhpnh6gyNpDhyaQKn3v3pcdqVnc0iMBWKeI06lD5b4yBdJHgH56h0N3Iv bMs+PuEQ4n5Y4F/VmmuQmFKBT14Ol0/Z+XwaLIJb33bJkgwkh7WHHVT24rdNnBOTND1n YuaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=BkI1zZKA; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m18si3233710pfk.210.2021.04.09.10.14.46; Fri, 09 Apr 2021 10:14:59 -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; dkim=pass header.i=@alien8.de header.s=dkim header.b=BkI1zZKA; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234067AbhDIROY (ORCPT + 99 others); Fri, 9 Apr 2021 13:14:24 -0400 Received: from mail.skyhub.de ([5.9.137.197]:39760 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234049AbhDIROX (ORCPT ); Fri, 9 Apr 2021 13:14:23 -0400 Received: from zn.tnic (p200300ec2f0be10039b183a609a7c35d.dip0.t-ipconnect.de [IPv6:2003:ec:2f0b:e100:39b1:83a6:9a7:c35d]) (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 E7A7A1EC04DA; Fri, 9 Apr 2021 19:14:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1617988449; 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=9AYjgxlvYEzX7lP0NtvpK9WeNVbzcrOcj1GyMO32N+8=; b=BkI1zZKAIOXGXVXDZmOJ5kTvnpvdEQxEu9hHsbEfqBXbmcLX9AbdpfXRpPq2jAtv2avPna 4L6A5qHTBqjwjIjHBREH2SQLJlAymZ23QG8Bn8+d324iG+C1FfGRkuLghB9fBaKVoM4V49 z7Nkq6Q70HYhsY4Wx435Y8ZpYd0sTuA= Date: Fri, 9 Apr 2021 19:14:08 +0200 From: Borislav Petkov To: "Yu, Yu-cheng" 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 v24 04/30] x86/cpufeatures: Introduce X86_FEATURE_CET and setup functions Message-ID: <20210409171408.GG15567@zn.tnic> References: <20210401221104.31584-1-yu-cheng.yu@intel.com> <20210401221104.31584-5-yu-cheng.yu@intel.com> <20210409101214.GC15567@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > 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? > 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. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette