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 12185C282DE for ; Wed, 5 Mar 2025 19:09:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2655728000B; Wed, 5 Mar 2025 14:09:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EFF1280004; Wed, 5 Mar 2025 14:09:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0901E28000B; Wed, 5 Mar 2025 14:09:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D79FD280004 for ; Wed, 5 Mar 2025 14:09:10 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8DDCCC0678 for ; Wed, 5 Mar 2025 15:30:14 +0000 (UTC) X-FDA: 83187883548.16.A7CF19C Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by imf17.hostedemail.com (Postfix) with ESMTP id 9601940019 for ; Wed, 5 Mar 2025 15:30:12 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=DuUS6e7G; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf17.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.169 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741188612; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UEdRnbd6ElHaf0cylSreE5si0Xhw1DFHYyknOm0Ao9g=; b=NXJpufOEBewNTtdbZGGzL0n+/FWLUNmtE/1+OIuda/DEDAdejEC/+FCNg8WeucV+HlDaBl FPjgFL6Np8oUC+UUYiROSgEPyIueTktnznbmIiBwMZpqbjuCAhB/wNOkffRs/+HtBII2JP HAwwjhc1LLM+ILEDBwxncM6uItuciE8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741188612; a=rsa-sha256; cv=none; b=0fmTr+vkOw0gAqWoAM2AS5v70oZM+q5NfTvWkQDR8sliAs3dZIqXgYdHpUw1Qxd9AY97Rn 25A9zMwBePNehjqbftxtUXwAArmorkL8DWwRP0YOZCcDVbA8Wh9+oKhcFPMQ12WViBHPtc CjNeLQt/2RjlM7XV8NNJiIk74jjy4fs= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=DuUS6e7G; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf17.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.169 as permitted sender) smtp.mailfrom=jeffxu@chromium.org Received: by mail-oi1-f169.google.com with SMTP id 5614622812f47-3f6740cd43aso58404b6e.0 for ; Wed, 05 Mar 2025 07:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1741188611; x=1741793411; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UEdRnbd6ElHaf0cylSreE5si0Xhw1DFHYyknOm0Ao9g=; b=DuUS6e7Gi3iITGzf9og8u1fUt3lrsY+EDL397no27T58p48GySXdL89sfc2H3U5nut W+6p3F06SuJD69vucXJYjL72X7Wcpf2NokV590+7CP2cx9TZow1yV7Os/VNab+6PNTyw RQbsPXpudE4OvNdPdPVudGIHy/Vd4IBTrZRMg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741188611; x=1741793411; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UEdRnbd6ElHaf0cylSreE5si0Xhw1DFHYyknOm0Ao9g=; b=X4f61w29vIWmYh97RdHew7k3iw8WvzesgXli4QAdNUdgyJXvLIGlIKwoDhgHHmNy52 GWs9aiXkgZwGaBYd+GtvYk+F6es5Ip36NNY0b1d8OdRiB5B+K+ubCZmR7Nlp/dKPmxoy zPDt7IPD6ZwpYFxID+eZbWp8/wX1sB42wngAuo+GORlKj5bYy/8GgSDREzRUPyH+E7O5 QLMYQYlsW4oY3GM5UdNrDBeVzxPtiz0DIz6DDen6m4XDlVD5uJmxqP4GHh/jRH4r+QKM 9huLDJGqhEu2LM7rtA7UxnylamURiyYvhLGegLyqYX05o9kH8lj9LVh974y5KnHtpnna 7NsA== X-Forwarded-Encrypted: i=1; AJvYcCXc3IRiYq4S6SBSAJToiA9c8epkVNk1IT1znJVG2kyb+ktXWS2DDPymWkE4S0zuaYTjOhOKic55gg==@kvack.org X-Gm-Message-State: AOJu0Yx8pTluiw+qHNdknSZTWJnGJh87hKzsGA2NrS1h4kQNZ13Ijm42 U/HCWYKuUpZUr0WNjBFJjceD67mrU6CiYdCw6LPl/ybjIBvBYnJtsZvkx2tslKpYcFCcf5Ovl1C 8AQHeZxyvRCpy1FCTrXMAIoA4+WIaUtfMqP0W X-Gm-Gg: ASbGncuFFiVL5QWo9ahlKxGqx9AUebHBES5fAoiu5rszRepN3kWPpuQdgQALFezbBgM y31wcVAyFSXfOk/NdLNemoUQ6BPCbWkdGzAYFt5gOS8gLKlBGYD/mMtK71vipdIBWZ0Gkh1FC/x 0c7F6pjIGdOzZpHTDloh8ST7bqQJntdLhQmz0/w1OaY0PeklW6uwR2CWENHno= X-Google-Smtp-Source: AGHT+IHSB04tBSW+Z7KYy5xTLyH1se2r+v919O73Ygx407YmZX9n7zbmBy8DtITaRXN/cqKLUXbKwVYEidOnAMnJqKE= X-Received: by 2002:a05:6808:181c:b0:3f6:769b:56e8 with SMTP id 5614622812f47-3f6831fe2a2mr745572b6e.7.1741188611147; Wed, 05 Mar 2025 07:30:11 -0800 (PST) MIME-Version: 1.0 References: <20250305021711.3867874-1-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Wed, 5 Mar 2025 07:29:59 -0800 X-Gm-Features: AQ5f1JpmPA1PDfBWtfjrkZLUmrQFxsJpyVBNI69QbozoCWMZFvLED0uZhWOGskk Message-ID: Subject: Re: [PATCH v9 0/7] mseal system mappings To: Lorenzo Stoakes Cc: akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, torvalds@linux-foundation.org, vbabka@suse.cz, Liam.Howlett@oracle.com, adhemerval.zanella@linaro.org, oleg@redhat.com, avagin@gmail.com, benjamin@sipsolutions.net, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, jorgelo@chromium.org, sroettger@google.com, hch@lst.de, ojeda@kernel.org, thomas.weissschuh@linutronix.de, adobriyan@gmail.com, johannes@sipsolutions.net, pedro.falcato@gmail.com, hca@linux.ibm.com, willy@infradead.org, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, peterx@redhat.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, enh@google.com, rientjes@google.com, groeck@chromium.org, mpe@ellerman.id.au, aleksandr.mikhalitsyn@canonical.com, mike.rapoport@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 9601940019 X-Stat-Signature: pixjun6649x8srh3pqpsdoye91icf9o8 X-HE-Tag: 1741188612-521870 X-HE-Meta: U2FsdGVkX1/PixlQkeJVx6dY+bWlbeyXiXklQe4tjuq2hw3yL3GBdXvFSzQ20mxeSYpBdswuOTmyNDWQqVKlpPOOuXx00g/9LywNzFtlrzNTiM5PJc+JZK4cNhiftgFN2J2WDE5xbVI/rk0ZZwnJ/Yem2h1jRrZuXSNQi0IX1IvoPdEVsA+z6whZPnZLK8trmYkt60+8OpOJgxBTDDPJhd1ZGBBHntyQIa121viylZMV18uosLisf8iBwQ2RBwiXij9O/WAiUnDx2QsiXd0CzpTXpueSoYurb7CXddZsAj33cjsq5J51mfBebejlG2AhRlsBcM+THAf61Oyo2bAALn8p8JBSvJJO1V9Ze5PJsrlhTJMHt616xgMzTWj1OZxMh+1wZUyehRVGu5fQ0aFfIVoRb/jrFKvWp7YLCsZKB6JohUGfOCBChsxC74C85Dg/JlpagMPZ6gH8gW1T9GDJWiKPhLsj8Qss08mwDn/7ps6oBH1rUPpN0SnHoBOn4Td4ouKpW2f4yjXokUKRlgeoYavpKSxMUO6T29wMN6maeWhMGAb6Sm7l/h5IsjBHPCSKLBJYiuHl6Wo5L/94nVfAvP2N5QAx17fMOiFYjipGwFH1pM2ME4d3RLy7my0rDrhMdN/MmBkdd6dof1oent+uhSvxfYB3ZF6A4t3EaqM/gtdHJjGcGjKSzQeK8PSIACaIApFTX4UQjvwSoclwIvydmE3qA6ONapRiffN74FwTAeb0b2LMkjCvz7vpfenwK7Kp4OCRBZaJUVd0FR5fla01GF83Un3z2phbdF7hIrrfSUUDzvsZtawZ3VVXAnRzTRbgqns3SNhUrKF7RRpNJntlCWkBWZNXtsepRXrtA9CMcOOkuQlQqkNmoyDVeV7gVJcdiWwoEQ5MUytdtTZRU8h9Q0rReVunwF+0rHBVruTBV8evPzlUjWSmEfXQfaNFeAQJu5OiqRNm395ZhVUCwkz pP3SzYrs kkXJNzyJK6LxNEDVxpNraq77894oZddc6CRUN9rbUd073bz2Po1xL69Q+s7yfR/VwAE6KGKCWhHJ67vvzN7Qfi8ucT3jXDxmL/CwEVb1SPJexl9NIyjAf5oJklc8NNC0sRAEpPW53CToUqQOrfEN4Y89AVEYG5aZC05TbRZ9HSEVymUeQNTyfFnG5TaKwLSRUheD1Dvfp2ObWamiW6xIczYbmz4P2iTDb0hFxnbYEOlg3MVjCI4Zu9zeVQT1kOwi9DQ6xkbA/FqC8LIAXfK4o/dq+tY5k0HwbOL3v4Ld13D3LvwS+7SVVjZ2RRTaifDVvx3ew4B6jlm3tL5qnrUthDVHX8CeLUEK2OPhohljeM/odqEtoxyR9J6qDmcuu39aKZSDe 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: List-Subscribe: List-Unsubscribe: On Tue, Mar 4, 2025 at 9:51=E2=80=AFPM Lorenzo Stoakes wrote: > > On Wed, Mar 05, 2025 at 02:17:04AM +0000, jeffxu@chromium.org wrote: > > From: Jeff Xu > > > > This is V9 version, addressing comments from V8, without code logic > > change. > > > > ------------------------------------------------------------------- > > As discussed during mseal() upstream process [1], mseal() protects > > the VMAs of a given virtual memory range against modifications, such > > as the read/write (RW) and no-execute (NX) bits. For complete > > descriptions of memory sealing, please see mseal.rst [2]. > > > > The mseal() 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. > > > > The system mappings are readonly only, memory sealing can protect > > them from ever changing to writable or unmmap/remapped as different > > attributes. > > > > System mappings such as vdso, vvar, vvar_vclock, > > vectors (arm compat-mode), sigpage (arm compat-mode), > > are created by the kernel during program initialization, and could > > be sealed after creation. > > > > Unlike the aforementioned mappings, the uprobe mapping is not > > established during program startup. However, its lifetime is the same > > as the process's lifetime [3]. It could be sealed from creation. > > > > The vsyscall on x86-64 uses a special address (0xffffffffff600000), > > which is outside the mm managed range. This means mprotect, munmap, and > > mremap won't work on the vsyscall. Since sealing doesn't enhance > > the vsyscall's security, it is skipped in this patch. If we ever seal > > the vsyscall, it is probably only for decorative purpose, i.e. showing > > the 'sl' flag in the /proc/pid/smaps. For this patch, it is ignored. > > > > It is important to note that the CHECKPOINT_RESTORE feature (CRIU) may > > alter the system mappings during restore operations. UML(User Mode Linu= x) > > and gVisor, rr are also known to change the vdso/vvar mappings. > > Consequently, this feature cannot be universally enabled across all > > systems. As such, CONFIG_MSEAL_SYSTEM_MAPPINGS is disabled by default. > > > > To support mseal of system mappings, architectures must define > > CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS and update their special > > mappings calls to pass mseal flag. Additionally, architectures must > > confirm they do not unmap/remap system mappings during the process > > lifetime. The existence of this flag for an architecture implies that > > it does not require the remapping of thest system mappings during > > process lifetime, so sealing these mappings is safe from a kernel > > perspective. > > > > This version covers x86-64 and arm64 archiecture as minimum viable feat= ure. > > > > While no specific CPU hardware features are required for enable this > > feature on an archiecture, memory sealing requires a 64-bit kernel. Oth= er > > architectures can choose whether or not to adopt this feature. Currentl= y, > > I'm not aware of any instances in the kernel code that actively > > munmap/mremap a system mapping without a request from userspace. The PP= C > > does call munmap when _install_special_mapping fails for vdso; however, > > it's uncertain if this will ever fail for PPC - this needs to be > > investigated by PPC in the future [4]. The UML kernel can add this supp= ort > > when KUnit tests require it [5]. > > > > In this version, we've improved the handling of system mapping sealing = from > > previous versions, instead of modifying the _install_special_mapping > > function itself, which would affect all architectures, we now call > > _install_special_mapping with a sealing flag only within the specific > > architecture that requires it. This targeted approach offers two key > > advantages: 1) It limits the code change's impact to the necessary > > architectures, and 2) It aligns with the software architecture by keepi= ng > > the core memory management within the mm layer, while delegating the > > decision of sealing system mappings to the individual architecture, whi= ch > > is particularly relevant since 32-bit architectures never require seali= ng. > > > > Prior to this patch series, we explored sealing special mappings from > > userspace using glibc's dynamic linker. This approach revealed several > > issues: > > - The PT_LOAD header may report an incorrect length for vdso, (smaller > > than its actual size). The dynamic linker, which relies on PT_LOAD > > information to determine mapping size, would then split and partially > > seal the vdso mapping. Since each architecture has its own vdso/vvar > > code, fixing this in the kernel would require going through each > > archiecture. Our initial goal was to enable sealing readonly mappings= , > > e.g. .text, across all architectures, sealing vdso from kernel since > > creation appears to be simpler than sealing vdso at glibc. > > - The [vvar] mapping header only contains address information, not leng= th > > information. Similar issues might exist for other special mappings. > > - Mappings like uprobe are not covered by the dynamic linker, > > and there is no effective solution for them. > > > > This feature's security enhancements will benefit ChromeOS, Android, > > and other high security systems. > > > > Testing: > > This feature was tested on ChromeOS and Android for both x86-64 and ARM= 64. > > - Enable sealing and verify vdso/vvar, sigpage, vector are sealed prope= rly, > > i.e. "sl" shown in the smaps for those mappings, and mremap is blocke= d. > > - Passing various automation tests (e.g. pre-checkin) on ChromeOS and > > Android to ensure the sealing doesn't affect the functionality of > > Chromebook and Android phone. > > > > I also tested the feature on Ubuntu on x86-64: > > - With config disabled, vdso/vvar is not sealed, > > - with config enabled, vdso/vvar is sealed, and booting up Ubuntu is OK= , > > normal operations such as browsing the web, open/edit doc are OK. > > > > Link: https://lore.kernel.org/all/20240415163527.626541-1-jeffxu@chromi= um.org/ [1] > > Link: Documentation/userspace-api/mseal.rst [2] > > Link: https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM4X= kRkL-NrCZxYAyg@mail.gmail.com/ [3] > > Link: https://lore.kernel.org/all/CABi2SkV6JJwJeviDLsq9N4ONvQ=3DEFANsiW= kgiEOjyT9TQSt+HA@mail.gmail.com/ [4] > > Link: https://lore.kernel.org/all/202502251035.239B85A93@keescook/ [5] > > > > ------------------------------------------- > > History: > > > > V9: > > - Add negative test in selftest (Kees Cook) > > - fx typos in text (Kees Cook) > > You have a bad habit of missing stuff off these logs. Usually I don't > comment, as it's trivial, but while we're here :) > > Please try to keep an accurate log of changes requested so you can popula= te > these properly. > > Obviously this is not going to block anything. But for future reference..= . > > - Add selftest to main selftest Makefile (Lorenzo Stoakes) > > > > > V8: > > Nit, but no lore link? https://lore.kernel.org/all/20250303050921.3033083-1-jeffxu@google.com/ Thanks for noticing this. > > > - Change ARCH_SUPPORTS_MSEAL_X to ARCH_SUPPORTS_MSEAL_X (Liam R. Howl= ett) > > - Update comments in Kconfig and mseal.rst (Lorenzo Stoakes, Liam R. = Howlett) > > - Change patch header perfix to "mseal sysmap" (Lorenzo Stoakes) > > - Remove "vm_flags =3D" (Kees Cook, Liam R. Howlett, Oleg Nesterov) > > - Drop uml architecture (Lorenzo Stoakes, Kees Cook) > > - Add a selftest to verify system mappings are sealed (Lorenzo Stoake= s) > > > > V7: > > https://lore.kernel.org/all/20250224225246.3712295-1-jeffxu@google.co= m/ > > - Remove cover letter from the first patch (Liam R. Howlett) > > - Change macro name to VM_SEALED_SYSMAP (Liam R. Howlett) > > - logging and fclose() in selftest (Liam R. Howlett) > > > > V6: > > https://lore.kernel.org/all/20250224174513.3600914-1-jeffxu@google.co= m/ > > - mseal.rst: fix a typo (Randy Dunlap) > > - security/Kconfig: add rr into note (Liam R. Howlett) > > - remove mseal_system_mappings() and use macro instead (Liam R. Howle= tt) > > - mseal.rst: add incompatible userland software (Lorenzo Stoakes) > > - remove RFC from title (Kees Cook) > > > > V5 > > https://lore.kernel.org/all/20250212032155.1276806-1-jeffxu@google.co= m/ > > - Remove kernel cmd line (Lorenzo Stoakes) > > - Add test info (Lorenzo Stoakes) > > - Add threat model info (Lorenzo Stoakes) > > - Fix x86 selftest: test_mremap_vdso > > - Restrict code change to ARM64/x86-64/UM arch only. > > - Add userprocess.h to include seal_system_mapping(). > > - Remove sealing vsyscall. > > - Split the patch. > > > > V4: > > https://lore.kernel.org/all/20241125202021.3684919-1-jeffxu@google.co= m/ > > - ARCH_HAS_SEAL_SYSTEM_MAPPINGS (Lorenzo Stoakes) > > - test info (Lorenzo Stoakes) > > - Update mseal.rst (Liam R. Howlett) > > - Update test_mremap_vdso.c (Liam R. Howlett) > > - Misc. style, comments, doc update (Liam R. Howlett) > > > > V3: > > https://lore.kernel.org/all/20241113191602.3541870-1-jeffxu@google.co= m/ > > - Revert uprobe to v1 logic (Oleg Nesterov) > > - use CONFIG_SEAL_SYSTEM_MAPPINGS instead of _ALWAYS/_NEVER (Kees Coo= k) > > - Move kernel cmd line from fs/exec.c to mm/mseal.c and > > misc. (Liam R. Howlett) > > > > V2: > > https://lore.kernel.org/all/20241014215022.68530-1-jeffxu@google.com/ > > - Seal uprobe always (Oleg Nesterov) > > - Update comments and description (Randy Dunlap, Liam R.Howlett, Oleg= Nesterov) > > - Rebase to linux_main > > > > V1: > > - https://lore.kernel.org/all/20241004163155.3493183-1-jeffxu@google.c= om/ > > > > -------------------------------------------------- > > > > > > > > Jeff Xu (7): > > mseal sysmap: kernel config and header change > > selftests: x86: test_mremap_vdso: skip if vdso is msealed > > mseal sysmap: enable x86-64 > > mseal sysmap: enable arm64 > > mseal sysmap: uprobe mapping > > mseal sysmap: update mseal.rst > > selftest: test system mappings are sealed. > > > > Documentation/userspace-api/mseal.rst | 20 +++ > > arch/arm64/Kconfig | 1 + > > arch/arm64/kernel/vdso.c | 12 +- > > arch/x86/Kconfig | 1 + > > arch/x86/entry/vdso/vma.c | 7 +- > > include/linux/mm.h | 10 ++ > > init/Kconfig | 22 ++++ > > kernel/events/uprobes.c | 3 +- > > security/Kconfig | 21 ++++ > > tools/testing/selftests/Makefile | 1 + > > .../mseal_system_mappings/.gitignore | 2 + > > .../selftests/mseal_system_mappings/Makefile | 6 + > > .../selftests/mseal_system_mappings/config | 1 + > > .../mseal_system_mappings/sysmap_is_sealed.c | 119 ++++++++++++++++++ > > .../testing/selftests/x86/test_mremap_vdso.c | 43 +++++++ > > 15 files changed, 261 insertions(+), 8 deletions(-) > > create mode 100644 tools/testing/selftests/mseal_system_mappings/.giti= gnore > > create mode 100644 tools/testing/selftests/mseal_system_mappings/Makef= ile > > create mode 100644 tools/testing/selftests/mseal_system_mappings/confi= g > > create mode 100644 tools/testing/selftests/mseal_system_mappings/sysma= p_is_sealed.c > > > > -- > > 2.48.1.711.g2feabab25a-goog > >