Message ID | 20240111234142.2944934-1-jeffxu@chromium.org |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-24139-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2411:b0:101:2151:f287 with SMTP id m17csp1792437dyi; Thu, 11 Jan 2024 15:43:25 -0800 (PST) X-Google-Smtp-Source: AGHT+IHiWoMGGjef8U2FyLHV1Iqm4zLHxOe57D/lZ0if/LcqYsGkGcBUjzeVkJoBpV1kj2uCFS9p X-Received: by 2002:a17:903:646:b0:1d3:9857:aa93 with SMTP id kh6-20020a170903064600b001d39857aa93mr59792plb.93.1705016605247; Thu, 11 Jan 2024 15:43:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705016605; cv=none; d=google.com; s=arc-20160816; b=Qwmt2Av+Zv5nRMGixkz/+8lmsKtQl/+1exRTJJZd4M/MI7seK+VoJjH/qI2ymALAJ9 Qp3oQOjoxCqEEEGo2ggt6qH5iPF94iuVyzX6OcomdjvgkXymvZibflVN66sYRqiGGZNW ucdcQczi60Ue9Fl6cbD2fgy07FHi64f6gpnrkUr6R3edt8y2cmc1dmtg8oya/ek30apM IfguSCg7fjjQcZVJo9Lc6dmGDZneK6JTyJEPmWzbZzfYm7Q9FT1G4Zv+kPFMbSooyAsK MHLq4lpAl8URpVnSo6tTyf+gbhibJsK31mvJkzofJWz0EpIWuqRC01krttzfSF6zHhsa 6znA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=/u+JSCf5ktSfAo0PmCiPTAaEej2iWaOypJw3h5HUIEk=; fh=mD88SIJYeeePgeNI709tEsuVUB4rmIeFacIq7flyM7k=; b=OFXu5/fl80qxquzbCsWCQHWrgvf6OYhbMq/kSJoePsASGp2v6b9o4SI8YhYDT+5yTc KKxqXqIVKN/NE7wYO7sD9YOClRUPzKcYQS993kS9PAqeF0UaREUTHgU5Y/HnopPbdiSr C+s9hQiVilau5c1WKZXbuKdwROEmEC4CuZeu/eC+p/w4YY6yp0P9/h9oEMLyAK87s49Y B1vGmj4Zghm+H2xDDX6uQ57HU4voM4mG3aMwNGYLuPkZt28UCrT1exZNeMXK+GlPFoM+ /IQRP0FGjZZwB1wN+lhMnlBIl2CJxsUnnjiECe3kD2p6pX7s5rFRDj2fmVlxslbsMewx 7PLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@chromium.org header.s=google header.b=Y88TDU2q; spf=pass (google.com: domain of linux-kernel+bounces-24139-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-24139-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id o1-20020a170902d4c100b001d5a578df8csi8736plg.311.2024.01.11.15.43.24 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 15:43:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-24139-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@chromium.org header.s=google header.b=Y88TDU2q; spf=pass (google.com: domain of linux-kernel+bounces-24139-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-24139-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 9E436B21062 for <ouuuleilei@gmail.com>; Thu, 11 Jan 2024 23:43:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A29365A109; Thu, 11 Jan 2024 23:42:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Y88TDU2q" Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8205B5A0F6 for <linux-kernel@vger.kernel.org>; Thu, 11 Jan 2024 23:42:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Received: by mail-ot1-f54.google.com with SMTP id 46e09a7af769-6dddf12f280so2571505a34.0 for <linux-kernel@vger.kernel.org>; Thu, 11 Jan 2024 15:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1705016547; x=1705621347; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=nQ88mFK7sFkh1njhDonNomw1p3DChoUnv33VvGn+i0U=; b=Y88TDU2qLsyBHXrbxCt15SpxMKvQA95tSBYqW75K8tFF5AXm3PuLvdWuy54kYXLSiq rh5VZHzcFfnU0lyzglAZKgGcloT+fhbTvbC6X6NqE/uR4NvrE+5xJltd/ueRYFhdPJNx k1s5v7A9mDB9ct8f9pcj5DkYJTzM66D/e5M64= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705016547; x=1705621347; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nQ88mFK7sFkh1njhDonNomw1p3DChoUnv33VvGn+i0U=; b=iIIkPcMWQ2S1+8+82F2Itwwjj5UzC7gLOGFvRS8x218tmd5eHje3OK2EBvx5QVFmU6 BBoB3xzLt4Ed92ALGetMMcpcSNMRJs20gUb9qkk5eTHv/mjEiV1EHytbZ1BSkbE3fuk0 gu+EZQjHnBMZHThmxCS4jVqoHCzmRyCvzxghYG6+wDNGQC/2beg21ctXmovnQYsN7ErC Knh27VUntFEdb2+G0wTd4fmQWGwHFzSOIfyXNxuChkoB9AIhqhW77vrlLGT2Ppf4Gacv JmHE/UdmBfG6JK3ccUt3oqVY5qij3dpfGw1sG4MoEasiYngOftHNSqcbOS1D0/GXZih8 79WA== X-Gm-Message-State: AOJu0YzcchV6E+pxyViOwm1iBwix62psANcATnQx0b0avbdHQxAXWjIL yns5xQQzsMWdbgCOqBflc2Swh61kkjMn X-Received: by 2002:a05:6359:504a:b0:172:d476:3f33 with SMTP id om10-20020a056359504a00b00172d4763f33mr1097417rwb.53.1705016547235; Thu, 11 Jan 2024 15:42:27 -0800 (PST) Received: from localhost (34.85.168.34.bc.googleusercontent.com. [34.168.85.34]) by smtp.gmail.com with UTF8SMTPSA id c23-20020aa78817000000b006d96dc803b3sm1847158pfo.12.2024.01.11.15.42.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jan 2024 15:42:26 -0800 (PST) From: jeffxu@chromium.org To: akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, usama.anjum@collabora.com, rdunlap@infradead.org Cc: jeffxu@google.com, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, pedro.falcato@gmail.com, dave.hansen@intel.com, linux-hardening@vger.kernel.org, deraadt@openbsd.org Subject: [PATCH v6 0/4] Introduce mseal() Date: Thu, 11 Jan 2024 23:41:37 +0000 Message-ID: <20240111234142.2944934-1-jeffxu@chromium.org> X-Mailer: git-send-email 2.43.0.275.g3460e3d667-goog Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787839492286798185 X-GMAIL-MSGID: 1787839492286798185 |
Series | Introduce mseal() | |
Message
Jeff Xu
Jan. 11, 2024, 11:41 p.m. UTC
From: Jeff Xu <jeffxu@google.com>
This patchset proposes a new mseal() syscall for the Linux kernel.
In a nutshell, mseal() protects the VMAs of a given virtual memory
range against modifications, such as changes to their permission bits.
Modern CPUs support memory permissions, such as the read/write (RW)
and no-execute (NX) bits. Linux has supported NX since the release of
kernel version 2.6.8 in August 2004 [1]. The memory permission feature
improves the security stance on memory corruption bugs, as an attacker
cannot simply write to arbitrary memory and point the code to it. The
memory must be marked with the X bit, or else an exception will occur.
Internally, the kernel maintains the memory permissions in a data
structure called VMA (vm_area_struct). mseal() additionally protects
the VMA itself against modifications of the selected seal type.
Memory sealing is useful to mitigate memory corruption issues where a
corrupted pointer is passed to a memory management system. For
example, such an attacker primitive can break control-flow integrity
guarantees since read-only memory that is supposed to be trusted can
become writable or .text pages can get remapped. Memory sealing can
automatically be applied by the runtime loader to seal .text and
rodata pages and applications can additionally seal security critical
data at runtime. A similar feature already exists in the XNU kernel
with the VM_FLAGS_PERMANENT [3] flag and on OpenBSD with the
mimmutable syscall [4]. Also, Chrome wants to adopt this feature for
their CFI work [2] and this patchset has been designed to be
compatible with the Chrome use case.
Two system calls are involved in sealing the map: mmap() and mseal().
The new mseal() is an syscall on 64 bit CPU, and with
following signature:
int mseal(void addr, size_t len, unsigned long flags)
addr/len: memory range.
flags: reserved.
mseal() blocks following operations for the given memory range.
1> Unmapping, moving to another location, and shrinking the size,
via munmap() and mremap(), can leave an empty space, therefore can
be replaced with a VMA with a new set of attributes.
2> Moving or expanding a different VMA into the current location,
via mremap().
3> Modifying a VMA via mmap(MAP_FIXED).
4> Size expansion, via mremap(), does not appear to pose any specific
risks to sealed VMAs. It is included anyway because the use case is
unclear. In any case, users can rely on merging to expand a sealed VMA.
5> mprotect() and pkey_mprotect().
6> Some destructive madvice() behaviors (e.g. MADV_DONTNEED) for anonymous
memory, when users don't have write permission to the memory. Those
behaviors can alter region contents by discarding pages, effectively a
memset(0) for anonymous memory.
In addition: mmap() has two related changes.
The PROT_SEAL bit in prot field of mmap(). When present, it marks
the map sealed since creation.
The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks
the map as sealable. A map created without MAP_SEALABLE will not support
sealing, i.e. mseal() will fail.
Applications that don't care about sealing will expect their behavior
unchanged. For those that need sealing support, opt-in by adding
MAP_SEALABLE in mmap().
The idea that inspired this patch comes from Stephen Röttger’s work in
V8 CFI [5]. Chrome browser in ChromeOS will be the first user of this
API.
Indeed, the Chrome browser has very specific requirements for sealing,
which are distinct from those of most applications. For example, in
the case of libc, sealing is only applied to read-only (RO) or
read-execute (RX) memory segments (such as .text and .RELRO) to
prevent them from becoming writable, the lifetime of those mappings
are tied to the lifetime of the process.
Chrome wants to seal two large address space reservations that are
managed by different allocators. The memory is mapped RW- and RWX
respectively but write access to it is restricted using pkeys (or in
the future ARM permission overlay extensions). The lifetime of those
mappings are not tied to the lifetime of the process, therefore, while
the memory is sealed, the allocators still need to free or discard the
unused memory. For example, with madvise(DONTNEED).
However, always allowing madvise(DONTNEED) on this range poses a
security risk. For example if a jump instruction crosses a page
boundary and the second page gets discarded, it will overwrite the
target bytes with zeros and change the control flow. Checking
write-permission before the discard operation allows us to control
when the operation is valid. In this case, the madvise will only
succeed if the executing thread has PKEY write permissions and PKRU
changes are protected in software by control-flow integrity.
Although the initial version of this patch series is targeting the
Chrome browser as its first user, it became evident during upstream
discussions that we would also want to ensure that the patch set
eventually is a complete solution for memory sealing and compatible
with other use cases. The specific scenario currently in mind is
glibc's use case of loading and sealing ELF executables. To this end,
Stephen is working on a change to glibc to add sealing support to the
dynamic linker, which will seal all non-writable segments at startup.
Once this work is completed, all applications will be able to
automatically benefit from these new protections.
Change history:
===============
V6:
- Drop RFC from subject, Given Linus's general approval.
- Adjust syscall number for mseal (main Jan.11/2024)
- Code style fix (Matthew Wilcox)
- selftest: use ksft macros (Muhammad Usama Anjum)
- Document fix. (Randy Dunlap)
V5:
- fix build issue in mseal-Wire-up-mseal-syscall
(Suggested by Linus Torvalds, and Greg KH)
- updates on selftest.
https://lore.kernel.org/lkml/20240109154547.1839886-1-jeffxu@chromium.org/#r
V4:
(Suggested by Linus Torvalds)
- new signature: mseal(start,len,flags)
- 32 bit is not supported. vm_seal is removed, use vm_flags instead.
- single bit in vm_flags for sealed state.
- CONFIG_MSEAL kernel config is removed.
- single bit of PROT_SEAL in the "Prot" field of mmap().
Other changes:
- update selftest (Suggested by Muhammad Usama Anjum)
- update documentation.
https://lore.kernel.org/all/20240104185138.169307-1-jeffxu@chromium.org/
V3:
- Abandon per-syscall approach, (Suggested by Linus Torvalds).
- Organize sealing types around their functionality, such as
MM_SEAL_BASE, MM_SEAL_PROT_PKEY.
- Extend the scope of sealing from calls originated in userspace to
both kernel and userspace. (Suggested by Linus Torvalds)
- Add seal type support in mmap(). (Suggested by Pedro Falcato)
- Add a new sealing type: MM_SEAL_DISCARD_RO_ANON to prevent
destructive operations of madvise. (Suggested by Jann Horn and
Stephen Röttger)
- Make sealed VMAs mergeable. (Suggested by Jann Horn)
- Add MAP_SEALABLE to mmap()
- Add documentation - mseal.rst
https://lore.kernel.org/linux-mm/20231212231706.2680890-2-jeffxu@chromium.org/
v2:
Use _BITUL to define MM_SEAL_XX type.
Use unsigned long for seal type in sys_mseal() and other functions.
Remove internal VM_SEAL_XX type and convert_user_seal_type().
Remove MM_ACTION_XX type.
Remove caller_origin(ON_BEHALF_OF_XX) and replace with sealing bitmask.
Add more comments in code.
Add a detailed commit message.
https://lore.kernel.org/lkml/20231017090815.1067790-1-jeffxu@chromium.org/
v1:
https://lore.kernel.org/lkml/20231016143828.647848-1-jeffxu@chromium.org/
----------------------------------------------------------------
[1] https://kernelnewbies.org/Linux_2_6_8
[2] https://v8.dev/blog/control-flow-integrity
[3] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274
[4] https://man.openbsd.org/mimmutable.2
[5] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc
[6] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.com/
[7] https://lore.kernel.org/lkml/20230515130553.2311248-1-jeffxu@chromium.org/
Jeff Xu (4):
mseal: Wire up mseal syscall
mseal: add mseal syscall
selftest mm/mseal memory sealing
mseal:add documentation
Documentation/userspace-api/mseal.rst | 181 ++
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/m68k/kernel/syscalls/syscall.tbl | 1 +
arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n32.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n64.tbl | 1 +
arch/mips/kernel/syscalls/syscall_o32.tbl | 1 +
arch/parisc/kernel/syscalls/syscall.tbl | 1 +
arch/powerpc/kernel/syscalls/syscall.tbl | 1 +
arch/s390/kernel/syscalls/syscall.tbl | 1 +
arch/sh/kernel/syscalls/syscall.tbl | 1 +
arch/sparc/kernel/syscalls/syscall.tbl | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
include/linux/mm.h | 60 +
include/linux/syscalls.h | 1 +
include/uapi/asm-generic/mman-common.h | 8 +
include/uapi/asm-generic/unistd.h | 5 +-
kernel/sys_ni.c | 1 +
mm/Makefile | 4 +
mm/madvise.c | 12 +
mm/mmap.c | 27 +
mm/mprotect.c | 10 +
mm/mremap.c | 31 +
mm/mseal.c | 330 +++
tools/testing/selftests/mm/.gitignore | 1 +
tools/testing/selftests/mm/Makefile | 1 +
tools/testing/selftests/mm/mseal_test.c | 1997 +++++++++++++++++++
32 files changed, 2686 insertions(+), 2 deletions(-)
create mode 100644 Documentation/userspace-api/mseal.rst
create mode 100644 mm/mseal.c
create mode 100644 tools/testing/selftests/mm/mseal_test.c
Comments
On 1/11/24 15:41, jeffxu@chromium.org wrote: > From: Jeff Xu <jeffxu@google.com> > > This patchset proposes a new mseal() syscall for the Linux kernel. > Jeff, Building arm64 defconfig, on linux-next-20240112, I get: CC arch/arm64/kernel/asm-offsets.s In file included from ../include/uapi/linux/mman.h:5, from ../include/linux/mm.h:33, from ../include/linux/memblock.h:12, from ../arch/arm64/include/asm/acpi.h:14, from ../include/acpi/acpi_io.h:7, from ../include/linux/acpi.h:39, from ../include/acpi/apei.h:9, from ../include/acpi/ghes.h:5, from ../include/linux/arm_sdei.h:8, from ../arch/arm64/kernel/asm-offsets.c:10: ./arch/arm64/include/asm/mman.h: In function 'arch_calc_vm_prot_bits': ./arch/arm64/include/asm/mman.h:15:24: error: 'VM_ARM64_BTI' undeclared (first use in this function); did you mean 'ARM64_BTI'? 15 | ret |= VM_ARM64_BTI; | ^~~~~~~~~~~~ | ARM64_BTI ./arch/arm64/include/asm/mman.h:15:24: note: each undeclared identifier is reported only once for each function it appears in ./arch/arm64/include/asm/mman.h:18:24: error: 'VM_MTE' undeclared (first use in this function); did you mean 'VM_MAP'? 18 | ret |= VM_MTE; | ^~~~~~ | VM_MAP ./arch/arm64/include/asm/mman.h: In function 'arch_calc_vm_flag_bits': ./arch/arm64/include/asm/mman.h:32:24: error: 'VM_MTE_ALLOWED' undeclared (first use in this function) 32 | return VM_MTE_ALLOWED; | ^~~~~~~~~~~~~~ ./arch/arm64/include/asm/mman.h: In function 'arch_validate_flags': ./arch/arm64/include/asm/mman.h:59:29: error: 'VM_MTE' undeclared (first use in this function); did you mean 'VM_MAP'? 59 | return !(vm_flags & VM_MTE) || (vm_flags & VM_MTE_ALLOWED); | ^~~~~~ | VM_MAP ./arch/arm64/include/asm/mman.h:59:52: error: 'VM_MTE_ALLOWED' undeclared (first use in this function) 59 | return !(vm_flags & VM_MTE) || (vm_flags & VM_MTE_ALLOWED); | ^~~~~~~~~~~~~~
On Fri, Jan 12, 2024 at 6:20 PM Randy Dunlap <rdunlap@infradead.org> wrote: > > > > On 1/11/24 15:41, jeffxu@chromium.org wrote: > > From: Jeff Xu <jeffxu@google.com> > > > > This patchset proposes a new mseal() syscall for the Linux kernel. > > > > Jeff, > Building arm64 defconfig, on linux-next-20240112, I get: > I don't quite get how this is related to my change. Can you please send me the steps to reproduce ? I don't usually build arm. Thanks -Jeff > CC arch/arm64/kernel/asm-offsets.s > In file included from ../include/uapi/linux/mman.h:5, > from ../include/linux/mm.h:33, > from ../include/linux/memblock.h:12, > from ../arch/arm64/include/asm/acpi.h:14, > from ../include/acpi/acpi_io.h:7, > from ../include/linux/acpi.h:39, > from ../include/acpi/apei.h:9, > from ../include/acpi/ghes.h:5, > from ../include/linux/arm_sdei.h:8, > from ../arch/arm64/kernel/asm-offsets.c:10: > ../arch/arm64/include/asm/mman.h: In function 'arch_calc_vm_prot_bits': > ../arch/arm64/include/asm/mman.h:15:24: error: 'VM_ARM64_BTI' undeclared (first use in this function); did you mean 'ARM64_BTI'? > 15 | ret |= VM_ARM64_BTI; > | ^~~~~~~~~~~~ > | ARM64_BTI > ../arch/arm64/include/asm/mman.h:15:24: note: each undeclared identifier is reported only once for each function it appears in > ../arch/arm64/include/asm/mman.h:18:24: error: 'VM_MTE' undeclared (first use in this function); did you mean 'VM_MAP'? > 18 | ret |= VM_MTE; > | ^~~~~~ > | VM_MAP > ../arch/arm64/include/asm/mman.h: In function 'arch_calc_vm_flag_bits': > ../arch/arm64/include/asm/mman.h:32:24: error: 'VM_MTE_ALLOWED' undeclared (first use in this function) > 32 | return VM_MTE_ALLOWED; > | ^~~~~~~~~~~~~~ > ../arch/arm64/include/asm/mman.h: In function 'arch_validate_flags': > ../arch/arm64/include/asm/mman.h:59:29: error: 'VM_MTE' undeclared (first use in this function); did you mean 'VM_MAP'? > 59 | return !(vm_flags & VM_MTE) || (vm_flags & VM_MTE_ALLOWED); > | ^~~~~~ > | VM_MAP > ../arch/arm64/include/asm/mman.h:59:52: error: 'VM_MTE_ALLOWED' undeclared (first use in this function) > 59 | return !(vm_flags & VM_MTE) || (vm_flags & VM_MTE_ALLOWED); > | ^~~~~~~~~~~~~~ > > > -- > #Randy
On 1/12/24 20:53, Jeff Xu wrote: > On Fri, Jan 12, 2024 at 6:20 PM Randy Dunlap <rdunlap@infradead.org> wrote: >> >> >> >> On 1/11/24 15:41, jeffxu@chromium.org wrote: >>> From: Jeff Xu <jeffxu@google.com> >>> >>> This patchset proposes a new mseal() syscall for the Linux kernel. >>> >> >> Jeff, >> Building arm64 defconfig, on linux-next-20240112, I get: >> > I don't quite get how this is related to my change. > Can you please send me the steps to reproduce ? I don't usually build arm. I don't get how it's related either, but when I build arm64 defconfig without your patches, it builds without errors. After applying your patches, it has errors... I did it 2 times just to make sure. It may just be some difference between x86_64 headers (is that what you build?) and arm64 headers. Install the x86_64-hosted arm64 compiler from https://mirrors.edge.kernel.org/pub/tools/crosstool/ in e.g. /opt/crosstool . In the kernel source tree: mkdir ARM64 make ARCH=arm64 O=ARM64 defconfig make -j25 CROSS_COMPILE=/opt/crosstool/gcc-13.2.0-nolibc/aarch64-linux/bin/aarch64-linux- ARCH=arm64 O=ARM64 all 2>&1 | tee aa64defcon.lst make ARCH=arm64 O=ARM64 clean <apply your mseal patches> make -j25 CROSS_COMPILE=/opt/crosstool/gcc-13.2.0-nolibc/aarch64-linux/bin/aarch64-linux- ARCH=arm64 O=ARM64 all 2>&1 | tee aa64mseal.lst If that does not reproduce the problem, please let me know. (I use a script, but that's the essence of the script.) >> CC arch/arm64/kernel/asm-offsets.s >> In file included from ../include/uapi/linux/mman.h:5, >> from ../include/linux/mm.h:33, >> from ../include/linux/memblock.h:12, >> from ../arch/arm64/include/asm/acpi.h:14, >> from ../include/acpi/acpi_io.h:7, >> from ../include/linux/acpi.h:39, >> from ../include/acpi/apei.h:9, >> from ../include/acpi/ghes.h:5, >> from ../include/linux/arm_sdei.h:8, >> from ../arch/arm64/kernel/asm-offsets.c:10: >> ../arch/arm64/include/asm/mman.h: In function 'arch_calc_vm_prot_bits': >> ../arch/arm64/include/asm/mman.h:15:24: error: 'VM_ARM64_BTI' undeclared (first use in this function); did you mean 'ARM64_BTI'? >> 15 | ret |= VM_ARM64_BTI; >> | ^~~~~~~~~~~~ >> | ARM64_BTI >> ../arch/arm64/include/asm/mman.h:15:24: note: each undeclared identifier is reported only once for each function it appears in >> ../arch/arm64/include/asm/mman.h:18:24: error: 'VM_MTE' undeclared (first use in this function); did you mean 'VM_MAP'? >> 18 | ret |= VM_MTE; >> | ^~~~~~ >> | VM_MAP >> ../arch/arm64/include/asm/mman.h: In function 'arch_calc_vm_flag_bits': >> ../arch/arm64/include/asm/mman.h:32:24: error: 'VM_MTE_ALLOWED' undeclared (first use in this function) >> 32 | return VM_MTE_ALLOWED; >> | ^~~~~~~~~~~~~~ >> ../arch/arm64/include/asm/mman.h: In function 'arch_validate_flags': >> ../arch/arm64/include/asm/mman.h:59:29: error: 'VM_MTE' undeclared (first use in this function); did you mean 'VM_MAP'? >> 59 | return !(vm_flags & VM_MTE) || (vm_flags & VM_MTE_ALLOWED); >> | ^~~~~~ >> | VM_MAP >> ../arch/arm64/include/asm/mman.h:59:52: error: 'VM_MTE_ALLOWED' undeclared (first use in this function) >> 59 | return !(vm_flags & VM_MTE) || (vm_flags & VM_MTE_ALLOWED); >> | ^~~~~~~~~~~~~~ >> >> >> -- >> #Randy >