From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E6DD21770C for ; Tue, 1 Apr 2025 22:18:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743545916; cv=none; b=rWrbpv3rtx8DjB6tFxenRp+BOfQ7xTmDw5eNHBTVRZs7pebSGLEACp8wp4bEpUH5xGHT9Sb4ErDhQgJ9ekMZDHjYIqrze/lcFejYyYiGzboqnitW/5YVGNPfVq2HotNBuniW+XV83f2C0waNCxjpX//NAzCB7EdsfmOf61WFmJs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743545916; c=relaxed/simple; bh=GloQlUqlW2mINh2uSfaiWjs1iPQAHUALCBlXk2r2Qic=; h=Date:To:From:Subject:Message-Id; b=FkK13RbK43pmU8NPMKk8lkOQm1WwMI9ddHkaBgxOkBprov5PfhmSUA9tQRbjkpC+PoLvsfgP0LWY9NyHZrj4M5GSJLkLPLvP+BLiksY8Oiy1ni84vBaj07Ac6ujuWJMRm+fEXZRTH3UB5uF634U6twoBX9EIp3HIA3u8ij2sGO8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=MW080pPb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="MW080pPb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DC34C4CEE4; Tue, 1 Apr 2025 22:18:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1743545916; bh=GloQlUqlW2mINh2uSfaiWjs1iPQAHUALCBlXk2r2Qic=; h=Date:To:From:Subject:From; b=MW080pPbNDegv/RGSKIK3+BfmahUXzE5z1ewpCiZVZCeoWzHI+C0dJjWxiTWiynyI ETcwLOlbBW3BzlqdHWQ/RlPQfp7BzvjHvrZpcmb3HYPgi8zsWYwxdiUKldb8YmmwKd MNzU9Yf0ezjSv9dGCVUz3XrEwMasoVSyaA5X27ps= Date: Tue, 01 Apr 2025 15:18:35 -0700 To: mm-commits@vger.kernel.org,willy@infradead.org,vbabka@suse.cz,thomas.weissschuh@linutronix.de,sroettger@google.com,rientjes@google.com,rdunlap@infradead.org,peterx@redhat.com,pedro.falcato@gmail.com,oleg@redhat.com,ojeda@kernel.org,mpe@ellerman.id.au,mingo@kernel.org,mike.rapoport@gmail.com,mhocko@suse.com,mark.rutland@arm.com,lorenzo.stoakes@oracle.com,linus.walleij@linaro.org,Liam.Howlett@oracle.com,kees@kernel.org,jorgelo@chromium.org,johannes@sipsolutions.net,jason@zx2c4.com,jannh@google.com,hch@lst.de,hca@linux.ibm.com,groeck@chromium.org,gerg@kernel.org,f.fainelli@gmail.com,enh@google.com,deller@gmx.de,davem@davemloft.net,dave.hansen@linux.intel.com,benjamin@sipsolutions.net,avagin@gmail.com,ardb@kernel.org,anna-maria@linutronix.de,aleksandr.mikhalitsyn@canonical.com,adobriyan@gmail.com,adhemerval.zanella@linaro.org,42.hyeyoo@gmail.com,jeffxu@chromium.org,akpm@linux-foundation.org From: Andrew Morton Subject: [merged mm-stable] mseal-sysmap-update-msealrst.patch removed from -mm tree Message-Id: <20250401221836.5DC34C4CEE4@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The quilt patch titled Subject: mseal sysmap: update mseal.rst has been removed from the -mm tree. Its filename was mseal-sysmap-update-msealrst.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Jeff Xu Subject: mseal sysmap: update mseal.rst Date: Wed, 5 Mar 2025 02:17:10 +0000 Update memory sealing documentation to include details about system mappings. Link: https://lkml.kernel.org/r/20250305021711.3867874-7-jeffxu@google.com Signed-off-by: Jeff Xu Reviewed-by: Kees Cook Reviewed-by: Lorenzo Stoakes Reviewed-by: Liam R. Howlett Cc: Adhemerval Zanella Cc: Alexander Mikhalitsyn Cc: Alexey Dobriyan Cc: Andrei Vagin Cc: Anna-Maria Behnsen Cc: Ard Biesheuvel Cc: Benjamin Berg Cc: Christoph Hellwig Cc: Dave Hansen Cc: David Rientjes Cc: David S. Miller Cc: Elliot Hughes Cc: Florian Faineli Cc: Greg Ungerer Cc: Guenter Roeck Cc: Heiko Carstens Cc: Helge Deller Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Ingo Molnar Cc: Jann Horn Cc: Jason A. Donenfeld Cc: Johannes Berg Cc: Jorge Lucangeli Obes Cc: Linus Waleij Cc: Mark Rutland Cc: Matthew Wilcow (Oracle) Cc: Michael Ellerman Cc: Michal Hocko Cc: Miguel Ojeda Cc: Mike Rapoport Cc: Oleg Nesterov Cc: Pedro Falcato Cc: Peter Xu Cc: Randy Dunlap Cc: Stephen Röttger Cc: Thomas Weißschuh Cc: Vlastimil Babka Signed-off-by: Andrew Morton --- Documentation/userspace-api/mseal.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) --- a/Documentation/userspace-api/mseal.rst~mseal-sysmap-update-msealrst +++ a/Documentation/userspace-api/mseal.rst @@ -130,6 +130,26 @@ Use cases - Chrome browser: protect some security sensitive data structures. +- System mappings: + The system mappings are created by the kernel and includes vdso, vvar, + vvar_vclock, vectors (arm compat-mode), sigpage (arm compat-mode), uprobes. + + Those system mappings are readonly only or execute only, memory sealing can + protect them from ever changing to writable or unmmap/remapped as different + attributes. This is useful to mitigate memory corruption issues where a + corrupted pointer is passed to a memory management system. + + If supported by an architecture (CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS), + the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this + architecture. + + The following architectures currently support this feature: x86-64 and arm64. + + WARNING: This feature breaks programs which rely on relocating + or unmapping system mappings. Known broken software at the time + of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore + this config can't be enabled universally. + When not to use mseal ===================== Applications can apply sealing to any virtual memory region from userspace, _ Patches currently in -mm which might be from jeffxu@chromium.org are