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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8202C4332F for ; Wed, 4 Jan 2023 12:50:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A6FF8E0002; Wed, 4 Jan 2023 07:50:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 456978E0001; Wed, 4 Jan 2023 07:50:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31F388E0002; Wed, 4 Jan 2023 07:50:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 20EBF8E0001 for ; Wed, 4 Jan 2023 07:50:26 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id DC8691C63F6 for ; Wed, 4 Jan 2023 12:50:25 +0000 (UTC) X-FDA: 80317100010.10.B7C9148 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf27.hostedemail.com (Postfix) with ESMTP id 3E44F40011 for ; Wed, 4 Jan 2023 12:50:18 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=aETOzOZv; spf=temperror (imf27.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672836623; a=rsa-sha256; cv=none; b=d1ulbAAb/OYjUPrPI3eJe3JfQmG1946bS1FL47W3LbpEkCY2OQCXhnmF7n0R6YNdiZhW26 iOCuvOCtmLPCu7TRoCpXY6V4SsGc5LSEReJA2h16pRjesHSlrdfMPKemktzVMtlcpeU8eT YHG1AoZNbTxraEhKjkr4qZmfNJ5K4Yc= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=alien8.de header.s=dkim header.b=aETOzOZv; spf=temperror (imf27.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="SPF/DKIM temp error" header.from=alien8.de (policy=temperror) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672836623; h=from:from:sender: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:dkim-signature; bh=2QcybxR9ZjqVi2pA+cenn1kHGCAZq3Ei7zS8JekyCcI=; b=S0eJlKJGI0p5RJpoc13By2rLa2pudLxiBZ/rHfa5cCwnMionQi2U0biZtzXjH3saBt2Lcr fri+p17fSLQ7fqHN54Y1delnoXzSv/2GWripQU9vbebDu4Sjj8gFGX2EOQSS14VyLzGh5V E//U+sCKtHk5HfM/Y2QprWA7R0EdG7k= Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (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 E1EFD1EC02DD; Wed, 4 Jan 2023 13:50:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1672836615; 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=2QcybxR9ZjqVi2pA+cenn1kHGCAZq3Ei7zS8JekyCcI=; b=aETOzOZvJlnJF8PfQBrcbuWt6IltMqy9vcCU1WOK+/7n/uCZUVIUBT4bisySQHxERCl0mf OST8S8/arWL4feZYPq4MxP06osGgTxi6YtCg/VuOMT4bTM8pc7chrrT1jm0zzHC5aDr6Pw lLQisN7O9IRC95JCUYxfent3UOPuUXg= Date: Wed, 4 Jan 2023 13:50:10 +0100 From: Borislav Petkov To: "Edgecombe, Rick P" Cc: "tglx@linutronix.de" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "Lutomirski, Andy" , "nadav.amit@gmail.com" , "kirill.shutemov@linux.intel.com" , "Schimpe, Christina" , "peterz@infradead.org" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "dethoma@microsoft.com" , "jannh@google.com" , "x86@kernel.org" , "pavel@ucw.cz" , "rdunlap@infradead.org" , "linux-api@vger.kernel.org" , "rppt@kernel.org" , "jamorris@linux.microsoft.com" , "arnd@arndb.de" , "john.allen@amd.com" , "bsingharora@gmail.com" , "mike.kravetz@oracle.com" , "oleg@redhat.com" , "andrew.cooper3@citrix.com" , "Yu, Yu-cheng" , "gorcunov@gmail.com" , "fweimer@redhat.com" , "keescook@chromium.org" , "hpa@zytor.com" , "mingo@redhat.com" , "mtk.manpages@gmail.com" , "hjl.tools@gmail.com" , "linux-mm@kvack.org" , "Syromiatnikov, Eugene" , "akpm@linux-foundation.org" , "Yang, Weijiang" , "dave.hansen@linux.intel.com" , "linux-doc@vger.kernel.org" , "Eranian, Stephane" Subject: Re: [PATCH v4 07/39] x86: Add user control-protection fault handler Message-ID: References: <20221203003606.6838-1-rick.p.edgecombe@intel.com> <20221203003606.6838-8-rick.p.edgecombe@intel.com> <3aaf1b0d67492415acb9b3d06bb97e916cb7b77a.camel@intel.com> <0e529db5f814ef7af7b197962c752a1454510a49.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0e529db5f814ef7af7b197962c752a1454510a49.camel@intel.com> X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3E44F40011 X-Stat-Signature: ecn6s1nsq8m7y7yqy738eguiz8a5r51z X-HE-Tag: 1672836618-66190 X-HE-Meta: U2FsdGVkX18wFvmeddFeYXiwkVBRpHhM79NXE2lq4l5C3ROPvbnL6VJzcB7Fno06VYred0TAmlgdJXGChmek+AlP5WRfbmfekuOqy2XJvZeZ8mTih5UMqF5wGMhV//8YHyOWv6KKRb3cq7G6Jqv+JZhm+FNsyPlFmoUHxxcx1RSPrCIbtZY4a5Ol5B6WBmDUu+LVs0lgjaP5Hv00EoNI+stsaVqYTW4aKzvjJlWsMU8hvHg4wwL+ZJliNpGqZkNcC2MQrf6sAUJv0X7o+UkynHiRaFiv/X9i1eyVHutq/7gp8JmyuDQtzNtE27jcV4nC5zwirjMr4eG89lehA4kD3VPOD1Q8QSzdzXkVAXuksCe/4EemtbGCrBngZMBjKnHmy0D5GRTrHH+m95FodyKivcoCwCMb6FaDHOki28J5Ncq8vqPyhylg6H1wxKLUn6+3HgzhkJ1sncTmXDjmGs7rSQYuuldl0PNgI4reJBrxpi6asWalhc7uppJsJZ/O8bBvk4ClDmViD7LfxqOwBnBq1yBiYDrzEhyuxK8eddxns5pvUz6eYZ4ZkHPPiccMhLz4VowFEOEGLQuV36Qu4vU1tD+np9w/4er31VmBnuvzVDuTSPC4kgjoC+s6IY+kyJPii4mahp1Do4BQZJKz12WlFaVHXAvkfDvkP3P/o9ftu8sOk2du2dmRadJQ99Gz1kkI3z5Q5g5y+ewQ7Sij4iYtfEWcmUG8YskGE6z+Ko9NgwJJXP0ipShQDFOzl5F5+sx7E2SiZzCYZFyi2ASyd7Bk1KjY+uSaEvy8EwER8WyCw/WTi6zmoKySqd7HsOjS0eztLF8GG8o61oaraEdi2OaWvysNmfNlWp9QYW1eaoMDdOEv9040BkbmOqJ3FKZfPl/yNaDUsiWjgyrAuQDq3NvXwa64cclDjsBe9TltFlaC+aRZgj25xsvD+sbJx6GJajB8S31oKdJwV6BDflKtmW3 nDsFg/kZ Dl0np32mw10BauA4eK7jhqJ+sVSBCiyywXhfKuW7nZaAvwiGK17NHY4jeIr1rRzqai8eNFDelwhf4HO8K/SbY+lmWiF4d+7BOl/SXIkgMjVGDPd5QQfR2AtPWqa0G43RgdfaAsAbojIgEK9K28YE62iKGdFFMAQ9um0dokkktvs9X2TiNMcX9BbbGBifSxkLSwa6DKUinoEVr8bRriglspF4+ZQRJwFc6N1cY 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 Wed, Dec 21, 2022 at 09:42:50PM +0000, Edgecombe, Rick P wrote: > Oh, you mean the whole Kconfig thing. Yea, I mean I see the point about > typical configs. But at least CONFIG_X86_CET seems consistent with > CONFIG_INTEL_TDX_GUEST, CONFIG_IOMMU_SVA, etc. > > What about moving it out of traps.c to a cet.c, like > exc_vmm_communication for CONFIG_AMD_MEM_ENCRT? Then the inclusion > logic lives in the build files, instead of an ifdef. Yeah, that definitely sounds cleaner. Another example would be the #MC handler being in mce code and not in traps.c. So yeah, the reason why I'm even mentioning this is that I get an allergic reaction when I see unwieldy ifdeffery in one screen worth of code. But this is just me. :) > One aspect that has come up a couple of times, is how closely related > all these CET features are (or aren't). Shadow stack and IBT are mostly > separate, but do share an xfeature and an exception type. Similarly for > supervisor and user mode support for either of the CET features. So > maybe that is what is unusual here. There are some aspects that make > them look like separate features, which leads people to think they > should be separate in the code. But actually separating them leads to > excess ifdefery. Yeah, I think you solved that correctly by having the common X86_CET symbol selected by the two. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette