Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1788563pxb; Wed, 9 Feb 2022 04:38:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJzVqy5LlrtIaunlmUsQnVTc1lR+2kQKUD69Zv+QBTXhWbG3CkgRmlSrj23BhHsXuW+3MVY6 X-Received: by 2002:a17:902:c702:: with SMTP id p2mr1995361plp.37.1644410335843; Wed, 09 Feb 2022 04:38:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644410335; cv=none; d=google.com; s=arc-20160816; b=xSNEfxEbZ+IleECt9W+R34BqVSjFIfeqUritslMF8kMwl/LK9at5qEHDfBXGF3jB0/ zVG4FRJBMB/ZWbNxqDG6haBAftKxdNzBDCGAumr2m5JoUeuz1PUhQZu7sDEwv6upC/SR FHOihnhHZFz/9OCClHBCEV8xVQ5C6aaEb3/QPERRoeCgQDTwZT7KmaZ5k8M4dsbMDJDu 5GACnEQhGk917OZOnfrDuJafQ3FPvsvJW130kSlwovun4Y6InGzGNMwNUN8qiBT4RORH +dRXgEs0T58LdzcVXRVNfw3UyzOhM5S0uk+s5AsgyVHwwB7Eo6GUyllMv2Y2vp59Nkoi iRYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=rxVPFqr94S7w98oNpN91dByC+cGNRTTY6lWxDMjWeAk=; b=KVjz5nrnjRFi6uhRydT1UiGdqG7Jf1Va3YSBCYVvDlxWbPBqJW/tR8zWsLsdUv6xcg p3ByucCoJsc3q+f93RiubuEhDSEJe5LrFY7+lh9z9M82p1UxgILPTfcnFzfHRoRvWGPX OB90+6uAu2AuS78ubPs7ztgpI/E6ssSVxfMMKzta5lmgXBjkFVHi/zz49zWw8Ah9HP5K xmzs1dU/Q/+stOYadyJG8UrnY6VoE+rfRoKD2Uzbs0ajVNp/fpzKNnum6cQm4rDTUvd6 qztEFjlORkxqf8Z2aGyzxA9OcuLhtjWdYqolYKrCeG6sUcO32lbVgtVnxyWT1pF7xfDg 9Atw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=lkAd10fm; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id s84si16375716pgs.644.2022.02.09.04.38.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 04:38:55 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=lkAd10fm; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 44FDAE04FF30; Wed, 9 Feb 2022 02:24:43 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232153AbiBIFoC (ORCPT + 99 others); Wed, 9 Feb 2022 00:44:02 -0500 Received: from gmail-smtp-in.l.google.com ([23.128.96.19]:49594 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233777AbiBIFfU (ORCPT ); Wed, 9 Feb 2022 00:35:20 -0500 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D2C9C004589 for ; Tue, 8 Feb 2022 21:35:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644384924; x=1675920924; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=KE6xfqngCfvzZJKMLOkMX94zaj2SFyiEC9rCfOFqENM=; b=lkAd10fmMC0/H6g0Nk5x/yiSTWjh28NZpZeqH8TixmBotEFfEtWDLFhB C+RmHLnVJOgoOQIAF40JMokj2xO5gdztW42OiTu8EwPbybkky9eAJ6mXY 5UZCuvDUB5DS0LJE6iw5/2816wGXv8zwlD7d0PwtxNrHdiIpTgskB0oSV PuMYnviMyd48gFSMyeYH2ujMVcLfL9jTGFOQVtgrjSoePGxPEN2+mU6ca TSU0DRPF+ufpnEwYPDpXwWB8TUM1OUmH+mINUDf3v6T96yteTdsxlTl5A dcJbFcXGZr5FYaF9esG+YYa/Pei4qUwDpvhf1G1tgMM3gOs2yNxwE0+we A==; X-IronPort-AV: E=McAfee;i="6200,9189,10252"; a="249331348" X-IronPort-AV: E=Sophos;i="5.88,354,1635231600"; d="scan'208";a="249331348" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2022 21:34:30 -0800 X-IronPort-AV: E=Sophos;i="5.88,354,1635231600"; d="scan'208";a="525844931" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.147]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2022 21:34:30 -0800 Date: Tue, 8 Feb 2022 21:34:30 -0800 From: Ira Weiny To: Dave Hansen Cc: Dave Hansen , "H. Peter Anvin" , Dan Williams , Fenghua Yu , Rick Edgecombe , linux-kernel@vger.kernel.org Subject: Re: [PATCH V8 06/44] mm/pkeys: Add Kconfig options for PKS Message-ID: <20220209053430.GL785175@iweiny-DESK2.sc.intel.com> References: <20220127175505.851391-1-ira.weiny@intel.com> <20220127175505.851391-7-ira.weiny@intel.com> <9c4a8275-236d-67b6-07f9-5e46f66396c0@intel.com> <20220128231015.GK785175@iweiny-DESK2.sc.intel.com> <20220204190851.GY785175@iweiny-DESK2.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220204190851.GY785175@iweiny-DESK2.sc.intel.com> User-Agent: Mutt/1.11.1 (2018-12-01) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 04, 2022 at 11:08:51AM -0800, 'Ira Weiny' wrote: > On Fri, Jan 28, 2022 at 03:51:56PM -0800, Dave Hansen wrote: > > On 1/28/22 15:10, Ira Weiny wrote: > > > This issue is that because PKS users are in kernel only and are not part of the > > > architecture specific code there needs to be 2 mechanisms within the Kconfig > > > structure. One to communicate an architectures support PKS such that the user > > > who needs it can depend on that config as well as a second to allow that user > > > to communicate back to the architecture to enable PKS. > > > > I *think* the point here is to ensure that PKS isn't compiled in unless > > it is supported *AND* needed. > > Yes. > > > You have to have architecture support > > (ARCH_HAS_SUPERVISOR_PKEYS) to permit features that depend on PKS to be > > enabled. Then, once one ore more of *THOSE* is enabled, > > ARCH_ENABLE_SUPERVISOR_PKEYS comes into play and actually compiles the > > feature in. > > > > In other words, there are two things that must happen before the code > > gets compiled in: > > > > 1. Arch support > > 2. One or more features to use the arch support > > Yes. I really think we are both say the same thing with different words. Is the following more clear? PKS is only useful to kernel consumers and is only available on some architectures. If no kernel consumers are configured or PKS support is not available the PKS code can be eliminated from the compile. Define a Kconfig structure which allows kernel consumers to detect architecture support (ARCH_HAS_SUPERVISOR_PKEYS) and, if available, indicate that PKS should be compiled in (ARCH_ENABLE_SUPERVISOR_PKEYS). In this patch ARCH_ENABLE_SUPERVISOR_PKEYS remains off until the first kernel consumer sets it. Thanks, Ira