Message ID | 20230706190217.371721-1-thuth@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp2791486vqx; Thu, 6 Jul 2023 12:38:36 -0700 (PDT) X-Google-Smtp-Source: APBJJlF44FQ4/HGULXOJkXC3bLaiwwy3m9xSdWAKfdW0267zmw2X+ustZUhKgM0txBD5NrQFnxpR X-Received: by 2002:a05:6830:1195:b0:6b8:6bd1:f097 with SMTP id u21-20020a056830119500b006b86bd1f097mr2830186otq.11.1688672316623; Thu, 06 Jul 2023 12:38:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688672316; cv=none; d=google.com; s=arc-20160816; b=FovPNJcLwIWTYRq1EPGA4iAkRBlNcrqV29BqRcAxxrCR9EuZzDnS2qrC5G2EXM7EA9 pvuNigW2UdyIYNWxio4gxNRr+fBCuRUVJ8q5HFp9DCXeki0xs0XPhUDAM7GlPTqkK9Px d4keFd2TK1Fhgfhra7pZTYIpeJ6OsrOMEy9IhPPfUJ7dNZRChGBtkegJYh62meXiJcs+ wIJpbXicYG8X9t1PTyvI/wIhIL2MXxHtIO+K6SRKFMn5vlHqJMW35NoxeoFmVClUyvnT XyDsQgLkyLvXlwfqmztxYBWqN53q9sj2sviuSiW/5f1TeUYnhBz3OVkG8DIbhLn9yLaU P5Hw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=xrVOfhoIMemGGmfQntaPU0HXJfwvQLEazh/5eyulSkk=; fh=DXYdotrnjW1pKWlmWnd3Pb1MQJgFS7lPpXuIZyISewo=; b=JRue7Gu5Ah4QEsQd6kfHz9yhksE+qliYOJiaM2+u272uTzBhkygwO0lHOmViIdLg7E VAgmUOJhEhTzeS3Qu+MGovNvETd1X4vkxz2iZrs+OtUAwFlmoFl23inXQDqO4ZvsSL7c twpfT0y6lFSLGfujh5vtlWa9mIfkZjpvOXfI9gq2i3RY0kaU1qGmwJCnNasRBrPv9Dp+ C3r9ffa6OCyuJ5YxRsT8HBO+kuSFsyFl9Z/CuYExPtptEkYEyDqBWJPFtKP/p/TpsnVP jPaU56aq7NKCyqlWowEGa3QYHwxkQy/UKQz1X7Jo7TurfNay/gwJ6GgopiwHy4nJ8dwH 2W2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hmQ3XMdh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r132-20020a632b8a000000b00553b783ad97si2054063pgr.228.2023.07.06.12.38.21; Thu, 06 Jul 2023 12:38:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hmQ3XMdh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231889AbjGFTDW (ORCPT <rfc822;hadasmailinglist@gmail.com> + 99 others); Thu, 6 Jul 2023 15:03:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231136AbjGFTDU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 6 Jul 2023 15:03:20 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67F721BFF for <linux-kernel@vger.kernel.org>; Thu, 6 Jul 2023 12:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688670147; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=xrVOfhoIMemGGmfQntaPU0HXJfwvQLEazh/5eyulSkk=; b=hmQ3XMdhaWWftg8yPQU+ffe46w61wnxOGOyXnH4y/HuIBATfUtJmeY7Fa83B0XttydLVEz 1GokC2yZYjPvk16JzcIkEE8lQnuVg4eBqDkOPFy8lEKR8MCDHLXiU5TE5dPQhOWJQ2GGKc OwY3rhFHuHrKK7boqUcST5EGWPTvce0= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-304-8siB-6IjN5arBNq_acKDHA-1; Thu, 06 Jul 2023 15:02:23 -0400 X-MC-Unique: 8siB-6IjN5arBNq_acKDHA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C35F238008A2; Thu, 6 Jul 2023 19:02:22 +0000 (UTC) Received: from thuth.com (unknown [10.39.192.45]) by smtp.corp.redhat.com (Postfix) with ESMTP id D27DA492B01; Thu, 6 Jul 2023 19:02:19 +0000 (UTC) From: Thomas Huth <thuth@redhat.com> To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com> Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>, Nicolas Schier <nicolas@fjasle.eu>, Masahiro Yamada <masahiroy@kernel.org>, linux-kernel@vger.kernel.org Subject: [PATCH] x86: Remove the arch_calc_vm_prot_bits() macro from the uapi Date: Thu, 6 Jul 2023 21:02:17 +0200 Message-Id: <20230706190217.371721-1-thuth@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770701263135086536?= X-GMAIL-MSGID: =?utf-8?q?1770701263135086536?= |
Series |
x86: Remove the arch_calc_vm_prot_bits() macro from the uapi
|
|
Commit Message
Thomas Huth
July 6, 2023, 7:02 p.m. UTC
The arch_calc_vm_prot_bits() macro uses VM_PKEY_BIT0 etc. which are
not part of the uapi, so the macro is completely useless for userspace.
It is also hidden behind the CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
config switch which we shouldn't expose to userspace. Thus let's move
this macro into a new internal header instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
arch/x86/include/asm/mman.h | 15 +++++++++++++++
arch/x86/include/uapi/asm/mman.h | 8 --------
scripts/headers_install.sh | 1 -
3 files changed, 15 insertions(+), 9 deletions(-)
create mode 100644 arch/x86/include/asm/mman.h
Comments
On Thu, Jul 6, 2023, at 21:02, Thomas Huth wrote: > The arch_calc_vm_prot_bits() macro uses VM_PKEY_BIT0 etc. which are > not part of the uapi, so the macro is completely useless for userspace. > It is also hidden behind the CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS > config switch which we shouldn't expose to userspace. Thus let's move > this macro into a new internal header instead. > > Signed-off-by: Thomas Huth <thuth@redhat.com> Fixes: 8f62c883222c9 ("x86/mm/pkeys: Add arch-specific VMA protection bits") Reviewed-by: Arnd Bergmann <arnd@arndb.de> It looks like this was introduced right after the uapi split, and probably is the result of an incorrect rebase. Arnd
On 7/6/23 13:22, Arnd Bergmann wrote: > On Thu, Jul 6, 2023, at 21:02, Thomas Huth wrote: >> The arch_calc_vm_prot_bits() macro uses VM_PKEY_BIT0 etc. which are >> not part of the uapi, so the macro is completely useless for userspace. >> It is also hidden behind the CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS >> config switch which we shouldn't expose to userspace. Thus let's move >> this macro into a new internal header instead. >> >> Signed-off-by: Thomas Huth <thuth@redhat.com> > Fixes: 8f62c883222c9 ("x86/mm/pkeys: Add arch-specific VMA protection bits") > Reviewed-by: Arnd Bergmann <arnd@arndb.de> > > It looks like this was introduced right after the uapi split, > and probably is the result of an incorrect rebase. Yeah, I bet I just glossed over the "uapi" in the path. Is this causing any real problems? Or is it OK to just send it along during the next merge window with other random cleanups?
On Thu, Jul 6, 2023, at 22:30, Dave Hansen wrote: > On 7/6/23 13:22, Arnd Bergmann wrote: >> On Thu, Jul 6, 2023, at 21:02, Thomas Huth wrote: >>> The arch_calc_vm_prot_bits() macro uses VM_PKEY_BIT0 etc. which are >>> not part of the uapi, so the macro is completely useless for userspace. >>> It is also hidden behind the CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS >>> config switch which we shouldn't expose to userspace. Thus let's move >>> this macro into a new internal header instead. >>> >>> Signed-off-by: Thomas Huth <thuth@redhat.com> >> Fixes: 8f62c883222c9 ("x86/mm/pkeys: Add arch-specific VMA protection bits") >> Reviewed-by: Arnd Bergmann <arnd@arndb.de> >> >> It looks like this was introduced right after the uapi split, >> and probably is the result of an incorrect rebase. > > Yeah, I bet I just glossed over the "uapi" in the path. > > Is this causing any real problems? Or is it OK to just send it along > during the next merge window with other random cleanups? It's pretty harmless, there are currently 12 remaining CONFIG_* #ifdef checks in uapi headers, which scripts/headers_install.sh has an exception for, and unlike some of the others, this one has no relevance for the actual uapi. Ultimately, the goal is to remove the list of known instances from the script and just warn about all of them when new ones get added, but it only becomes urgent when we get to everything else. Arnd
On 06/07/2023 22.30, Dave Hansen wrote: > On 7/6/23 13:22, Arnd Bergmann wrote: >> On Thu, Jul 6, 2023, at 21:02, Thomas Huth wrote: >>> The arch_calc_vm_prot_bits() macro uses VM_PKEY_BIT0 etc. which are >>> not part of the uapi, so the macro is completely useless for userspace. >>> It is also hidden behind the CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS >>> config switch which we shouldn't expose to userspace. Thus let's move >>> this macro into a new internal header instead. >>> >>> Signed-off-by: Thomas Huth <thuth@redhat.com> >> Fixes: 8f62c883222c9 ("x86/mm/pkeys: Add arch-specific VMA protection bits") >> Reviewed-by: Arnd Bergmann <arnd@arndb.de> >> >> It looks like this was introduced right after the uapi split, >> and probably is the result of an incorrect rebase. > > Yeah, I bet I just glossed over the "uapi" in the path. > > Is this causing any real problems? Or is it OK to just send it along > during the next merge window with other random cleanups? As Arnd already said, it's not a real problem - I just came across this file while looking at the list in scripts/headers_install.sh. Thomas
On Thu, Jul 06, 2023 at 09:02:17PM +0200 Thomas Huth wrote: > The arch_calc_vm_prot_bits() macro uses VM_PKEY_BIT0 etc. which are > not part of the uapi, so the macro is completely useless for userspace. > It is also hidden behind the CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS > config switch which we shouldn't expose to userspace. Thus let's move > this macro into a new internal header instead. > > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- Thanks for fixing this config leakage. Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> > arch/x86/include/asm/mman.h | 15 +++++++++++++++ > arch/x86/include/uapi/asm/mman.h | 8 -------- > scripts/headers_install.sh | 1 - > 3 files changed, 15 insertions(+), 9 deletions(-) > create mode 100644 arch/x86/include/asm/mman.h > > diff --git a/arch/x86/include/asm/mman.h b/arch/x86/include/asm/mman.h > new file mode 100644 > index 0000000000000..12b820259b9f3 > --- /dev/null > +++ b/arch/x86/include/asm/mman.h > @@ -0,0 +1,15 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __ASM_MMAN_H__ > +#define __ASM_MMAN_H__ > + > +#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS > +#define arch_calc_vm_prot_bits(prot, key) ( \ > + ((key) & 0x1 ? VM_PKEY_BIT0 : 0) | \ > + ((key) & 0x2 ? VM_PKEY_BIT1 : 0) | \ > + ((key) & 0x4 ? VM_PKEY_BIT2 : 0) | \ > + ((key) & 0x8 ? VM_PKEY_BIT3 : 0)) > +#endif > + > +#include <uapi/asm/mman.h> > + > +#endif /* __ASM_MMAN_H__ */ > diff --git a/arch/x86/include/uapi/asm/mman.h b/arch/x86/include/uapi/asm/mman.h > index 775dbd3aff736..a72e4f3e13b17 100644 > --- a/arch/x86/include/uapi/asm/mman.h > +++ b/arch/x86/include/uapi/asm/mman.h > @@ -4,14 +4,6 @@ > > #define MAP_32BIT 0x40 /* only give out 32bit addresses */ > > -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS > -#define arch_calc_vm_prot_bits(prot, key) ( \ > - ((key) & 0x1 ? VM_PKEY_BIT0 : 0) | \ > - ((key) & 0x2 ? VM_PKEY_BIT1 : 0) | \ > - ((key) & 0x4 ? VM_PKEY_BIT2 : 0) | \ > - ((key) & 0x8 ? VM_PKEY_BIT3 : 0)) > -#endif > - > #include <asm-generic/mman.h> > > #endif /* _ASM_X86_MMAN_H */ > diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh > index afdddc82f02b3..56d3c338d91d7 100755 > --- a/scripts/headers_install.sh > +++ b/scripts/headers_install.sh > @@ -81,7 +81,6 @@ arch/nios2/include/uapi/asm/swab.h:CONFIG_NIOS2_CI_SWAB_NO > arch/nios2/include/uapi/asm/swab.h:CONFIG_NIOS2_CI_SWAB_SUPPORT > arch/x86/include/uapi/asm/auxvec.h:CONFIG_IA32_EMULATION > arch/x86/include/uapi/asm/auxvec.h:CONFIG_X86_64 > -arch/x86/include/uapi/asm/mman.h:CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS > " > > for c in $configs > -- > 2.39.3
diff --git a/arch/x86/include/asm/mman.h b/arch/x86/include/asm/mman.h new file mode 100644 index 0000000000000..12b820259b9f3 --- /dev/null +++ b/arch/x86/include/asm/mman.h @@ -0,0 +1,15 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __ASM_MMAN_H__ +#define __ASM_MMAN_H__ + +#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS +#define arch_calc_vm_prot_bits(prot, key) ( \ + ((key) & 0x1 ? VM_PKEY_BIT0 : 0) | \ + ((key) & 0x2 ? VM_PKEY_BIT1 : 0) | \ + ((key) & 0x4 ? VM_PKEY_BIT2 : 0) | \ + ((key) & 0x8 ? VM_PKEY_BIT3 : 0)) +#endif + +#include <uapi/asm/mman.h> + +#endif /* __ASM_MMAN_H__ */ diff --git a/arch/x86/include/uapi/asm/mman.h b/arch/x86/include/uapi/asm/mman.h index 775dbd3aff736..a72e4f3e13b17 100644 --- a/arch/x86/include/uapi/asm/mman.h +++ b/arch/x86/include/uapi/asm/mman.h @@ -4,14 +4,6 @@ #define MAP_32BIT 0x40 /* only give out 32bit addresses */ -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS -#define arch_calc_vm_prot_bits(prot, key) ( \ - ((key) & 0x1 ? VM_PKEY_BIT0 : 0) | \ - ((key) & 0x2 ? VM_PKEY_BIT1 : 0) | \ - ((key) & 0x4 ? VM_PKEY_BIT2 : 0) | \ - ((key) & 0x8 ? VM_PKEY_BIT3 : 0)) -#endif - #include <asm-generic/mman.h> #endif /* _ASM_X86_MMAN_H */ diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh index afdddc82f02b3..56d3c338d91d7 100755 --- a/scripts/headers_install.sh +++ b/scripts/headers_install.sh @@ -81,7 +81,6 @@ arch/nios2/include/uapi/asm/swab.h:CONFIG_NIOS2_CI_SWAB_NO arch/nios2/include/uapi/asm/swab.h:CONFIG_NIOS2_CI_SWAB_SUPPORT arch/x86/include/uapi/asm/auxvec.h:CONFIG_IA32_EMULATION arch/x86/include/uapi/asm/auxvec.h:CONFIG_X86_64 -arch/x86/include/uapi/asm/mman.h:CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS " for c in $configs