From nobody Sun Aug 16 13:31:22 2026 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4hNH1B0C23z6p54m; Sun, 16 Aug 2026 13:31:26 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "YR2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hNH1964ZKz40yk; Sun, 16 Aug 2026 13:31:25 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1786887085; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ngCt5NoNvk/QF0l8f9ukxKcBU6IzDQNSQxj3CtLq+yM=; b=MxhNou/NhTkOWvVoDJHrM5hHNOe3m8NmTIwjmP/pHxukcQjns5MUuRniFA4rDs1le9LLFU 8GeJveJbqOXiK6hJqVAtJCxgPZTxBjvqHCGYBZZn7+yvD5HEB3OGVEMcAcZIB+r8GZGLS6 dzGF3o6qMxslJHCePxEXOl5G1kVxMoHzt8ljkNQBJdNa26KcadUj0f6BPhmWIow2D2zn5u yr2Dnm+up0eUb7qIT802ZS5yr/1BaqsGi9fj1U/cba0HpFTAnmLQ50FG1jXGQ2fTmpbQmN c7Ne+/mGB02AreOZHD/M7qzjQ8tFXijll6kqPwxCPwoJnxjA+Ni1sOD1oBfyDg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1786887085; a=rsa-sha256; cv=none; b=xcyEVipzekL1VVs4Hm0s8FrpIZA9hA6HrSQncLIAPg5XHW8eY/zEM2IAns4zECOKVSJXSh c5TQX76SgkasgMUB+2HTCzucJTHYHhM1xwgO+dr3/Pdvf4DSrWrr4FGSprbifCO01itIsC /6i2ZiCTL7JIkqu/XAOeHts9WU6ifTnKFJ1jgEdDRjQ2Ujq/wwjPXSHQ18rhFxXY61jsyO +UCc7rOu21d8Gr0v6gDAhVaWZWdR5uQIrT9iS725gKlX6IgqkNi+dUWjMeLVLRGvfVwmeb lwteQQi4MyUd/rkHJueGuqmzjXBCPD8dWZyu+GDOGeB7Tj5JdUI4MjXUcqfWOg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1786887085; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ngCt5NoNvk/QF0l8f9ukxKcBU6IzDQNSQxj3CtLq+yM=; b=jILfvr0lDlepXgPexGlUf/8BpsNu8bIILZ63AGHLxFSl2vB/P/EUxV65JHq8yrKDYSVjqx CHgMvJ2nzkemG225h6n9N6wAKKhDZnmPo3f0B+i0KZNQcYuWTG/YKxMXP1kMhVp1i+CbIu /5x9PufTH2o2AkLFHumfMG2zC5a18TIMgQ4Q+VAOJJ9pxUXptB2RZMepvaILWC5BeNpf5o hfm+O6LHt/T1gkjOvBEBuuOE6EMuaB0aiK8e0aH9G49qrn2sdCX1kp8tSHbSU3HbrZC6Uf fyiYtC0NVXNg5Q3rF+RMjPW3euCKLr0RMmvJFRhvGN07WSAo7ksVMe/53aOUhw== Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:6cc3:10f9:cd29:4aa5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: tuexen) by smtp.freebsd.org (Postfix) with ESMTPSA id 4hNH190kYPz4p7; Sun, 16 Aug 2026 13:31:24 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) Content-Type: text/plain; charset=us-ascii List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.1\)) Subject: Re: git: bdb561843e86 - main - linux: implement pkey_alloc, pkey_free and pkey_mprotect From: Michael Tuexen In-Reply-To: <6a810bcc.3ab17.312eef3@gitrepo.freebsd.org> Date: Sun, 16 Aug 2026 15:31:22 +0200 Cc: "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6a810bcc.3ab17.312eef3@gitrepo.freebsd.org> To: Devin Teske X-Mailer: Apple Mail (2.3864.700.51.1.1) > On 16. Aug 2026, at 03:01, Devin Teske wrote: >=20 > The branch main has been updated by dteske: >=20 > URL: = https://cgit.FreeBSD.org/src/commit/?id=3Dbdb561843e865eaa5bbdc5394ed9d9c9= 1136240c >=20 > commit bdb561843e865eaa5bbdc5394ed9d9c91136240c > Author: Devin Teske > AuthorDate: 2026-08-16 00:58:19 +0000 > Commit: Devin Teske > CommitDate: 2026-08-16 00:58:43 +0000 >=20 > linux: implement pkey_alloc, pkey_free and pkey_mprotect >=20 > Bridge the Linux memory protection key syscalls to FreeBSD's native > MPK support instead of returning ENOSYS. Modern Linux software > probes these at startup: Chromium-based browsers (found via > www/linux-brave) use protection keys for V8's heap and JIT > sandboxing, and glibc >=3D 2.27 exposes the full API. >=20 > pkey_alloc() allocates from a per-process bitmap kept in the = process > emuldata (key 0 implicitly allocated, matching Linux's > mm_pkey_allocation_map; ENOSPC once keys 1..15 are exhausted or = when > PKU is absent, as Linux returns on such hardware) and applies the > requested initial access rights to the calling thread's PKRU, = located > in the XSAVE area via xsave_area_offset(). pkey_free() is > bookkeeping only: as on Linux, freeing neither untags pages nor > updates PKRU. pkey_mprotect() performs the protection change and > tags the range through amd64_pkru_update(), factored out of > sysarch(2)'s AMD64_SET_PKRU/AMD64_CLEAR_PKRU implementation so that > both share the same argument checking and map read lock > synchronization with a parallel pmap_vmspace_copy() on fork; tags = die > with the mapping, matching Linux VMA semantics. A pkey of -1 > degrades to plain mprotect. >=20 > The allocation map is inherited on fork and reset on exec. At exec > the Linux sysvecs initialize PKRU to 0x55555554, Linux's init_pkru > default (access disabled for keys 1..15), so memory tagged with a > not yet allocated key is inaccessible to threads that were never > granted rights -- the property V8's thread isolation relies on. > Setting PKRU at exec initializes the user FPU state slightly = earlier > than the lazy first-use path; the state would be initialized = moments > later in rtld/libc startup regardless. Protection key faults > already deliver SEGV_PKUERR through the existing siginfo > translation. >=20 > The common code carries no architecture ifdefs. Machine-dependent > state lives in struct linux_pemuldata_md, embedded in the process > emuldata in the manner of struct mdthread, and common code calls > per-arch lifecycle hooks (linux_pemuldata_init_md/_exec_md) and = pkey > back ends after performing the parameter validation Linux applies > regardless of hardware support. On amd64 the implementation lives > in sys/amd64/linux/linux_pkru.c, compiled into linux_common and > serving both the 64-bit and 32-bit Linux ABIs. Elsewhere (arm64, > i386) linux_emul_md.c provides stubs returning what Linux returns = on > hardware without protection keys (ENOSPC from pkey_alloc; > pkey_mprotect with a pkey of -1 acts as plain mprotect), so > applications take their normal no-PKU fallback instead of the = ENOSYS > path. >=20 > PR: 297427 > MFC after: 1 month > Reviewed by: kib > Differential Revision: https://reviews.freebsd.org/D58782 Hi Devin, This breaks compilation for me on arm64. In = sys/arm64/linux/linux_emul_md.c the file compat/linux/linux_emul.h is included which needs an inclusion of sys/imgact.h. So diff --git a/sys/arm64/linux/linux_emul_md.c = b/sys/arm64/linux/linux_emul_md.c index 9dd507ad4f49..e55d3b712056 100644 --- a/sys/arm64/linux/linux_emul_md.c +++ b/sys/arm64/linux/linux_emul_md.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include fixes compilation for me. Best regards Michael