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 811ACCF6491 for ; Sat, 28 Sep 2024 18:28:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C4E366B0256; Sat, 28 Sep 2024 14:28:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BFE1B6B0257; Sat, 28 Sep 2024 14:28:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9EA26B0258; Sat, 28 Sep 2024 14:28:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 827C06B0256 for ; Sat, 28 Sep 2024 14:28:37 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EA4F1A0686 for ; Sat, 28 Sep 2024 18:28:36 +0000 (UTC) X-FDA: 82614982632.23.2082B9B Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by imf24.hostedemail.com (Postfix) with ESMTP id 6E27F180004 for ; Sat, 28 Sep 2024 18:28:32 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=UNsLitGK; dmarc=none; spf=none (imf24.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=rdunlap@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727547977; 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=V+9LfybIwIck4AhikQa6dEmZGnSm3uZ83KznMUGroo8=; b=jBEmFyN5+7MHkx81j1Qw4XzikEN+pdb4r+AOPg8BgJE60psIY9/RVwRxTB6FnGIkLcy5pb M58Yq5YHddDng4CRGYY3UZz/NvdJnhQ//ymhbuaiQRzjCVF19r+L8PT/M2qa16nBugqOcT bznbIBRwR/fXuNAxGgH6P2pALnCYpGI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727547977; a=rsa-sha256; cv=none; b=iLcPUKuPrdU0ASxsKZPtsEeBbyhNKuMOCB5DJfEUrV4LRaoleWS5L8dv2nMHpSUzl9mnbH MuI592jYi0ZpvrjpmqQmA+xCdRBtS+F1ejYb2Tro1xcXYextlxa3tu8M2TTwu6f7B8j8Zr xT3AlWZ0CZbX/SWzhO0xWrcwiMHFkdE= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=UNsLitGK; dmarc=none; spf=none (imf24.hostedemail.com: domain of rdunlap@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=rdunlap@infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:Content-Type :In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID: Sender:Reply-To:Content-ID:Content-Description; bh=V+9LfybIwIck4AhikQa6dEmZGnSm3uZ83KznMUGroo8=; b=UNsLitGKp/pQ1/xxaZpIZO0FUN jD0Ol6wAoGd1v0c2uQe+I0sqmrbYYnodPbcL+rP/WUs9pFCFWLqp/hw+/F4gqLQoppwwnWehinu25 ql1nwPXp6lwcmBj1CBQHUyahHRykL2MwvGbYj/zwK1FQUMbO4jK1r/T2ONYphJTubxXOi8h7BMD6n e1LoONQhLB/kEO5dNsg3hw4PwyX0O9h9hb4zyOXX7yaGAYykufFZreKVckbJ43BG5gvS/zt7aaW4E YcR51xjg+ye/PmHBdqevSLiMuw2zegNoqy0sDkI6f8LigMUk1h7FUCoCj+PaPzit/x/9U48HqHw+G NiGQrfqw==; Received: from [50.53.2.24] (helo=[192.168.254.17]) by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1sucB1-00000002XxV-3koC; Sat, 28 Sep 2024 18:28:20 +0000 Message-ID: Date: Sat, 28 Sep 2024 11:28:10 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/1] mseal: update mseal.rst To: jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, corbet@lwn.net Cc: jeffxu@google.com, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jannh@google.com, sroettger@google.com, pedro.falcato@gmail.com, linux-hardening@vger.kernel.org, willy@infradead.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, deraadt@openbsd.org, usama.anjum@collabora.com, surenb@google.com, merimus@google.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, enh@google.com References: <20240927185211.729207-1-jeffxu@chromium.org> <20240927185211.729207-2-jeffxu@chromium.org> Content-Language: en-US From: Randy Dunlap In-Reply-To: <20240927185211.729207-2-jeffxu@chromium.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6E27F180004 X-Stat-Signature: pc7z851i15dj1yb7ac6jwiqcj98a949p X-Rspam-User: X-HE-Tag: 1727548112-352212 X-HE-Meta: U2FsdGVkX1+69hSufkXus8zNbl3QSFwEMztrNkl4wFifPrYVMUKfjm/GdAXJ6Y9EdnQYY0EMKLGNB+1BkcnMMwQVX//hrDpAmxvQZS/IIl86uirkNDwDES+0iebVTTYsvwKw3fgh+1Q2tX7BupGczLxmk8Y+dQdROT6SfTVCQvNUeTHyCVNL0Q+zlTuFsTXjhp4WqhE7bQlZ/oYI6IZin31+mI/BwDyjGxA57fgw+3yZq6h9nm3YOX7DapzBqgq3rmdkcQMGyrzzNGl5Ybvj1ydnoBe6bGuvqc2tQz55sC4n3+Y7IXW20iTwtJYYc12mvNQw29B387/scmXF91X+KlE7TbfPsd9W6/4PgFb9I58jGz7SkF71UTUEzFUmnLTy9djX8BfCdOpNKUJw0cs+Ko/A2IRxbsaEMgPED1qXfKbittRkXnrrQ/AVaGAghOF634+RoJmvCm/fkRPQE/gU0FDTRvRQh+AylaRro5AiYIyNhIbhXeMT+aKuC9q8c9hH01gVFi6a9VRKgEdGa44+Uz8m4NphDa4TJZrw8cJypXGfYSaIJznBgCs4FehzPGRwHBsZJ3F25wIeuwdaj5f12Ib9aIEnsJFT7E9ZVZkUO6mq0AeHu8DqvJoPMRuBjTmBJmuLFIGx82tt/IICrr2irouTusu0t690EpCJpCun8LcquXDht2YVZvftdIH//BVXTg6Q6OYZsICy2pPhi2pbi5gBsG0a+FFoydmev47IoO1x9A/dcZ+Z7M4Q6MRiH7CSUW3jtXrOPFXlGXPd1iiB7oFK6EHCDx9ArqI8DeHFRBn57CiKZgLu5gQ9u18c+Acx0EMYhPSe32OMD5Kx3A0zakxocgyM4ssCxW2/ELv6TF7AqN5o87W8GK9TX92GFJK8XCLQpYRz5o8/rTXZlbwStibgBQpvWfsKGt9uTuQVXMGOddTLMlNOI5yHLeZ+/NCP0+IoII/JMXkyQwBzrbm A84COP27 y+hX2x+gNEy6TfG//O/LKouDldVqUyY/Io6KQfH2qv+3yDK/RtGyt+//NJyjuozbzZXqe3Vupis72UVMHtGPuYNXY09eyB9BN1FDJ9rqhajXA1JDe4OAY1PODd70IyJTWbe0qEmo2I6Kw6yvCDgprg4xRgrGqEIgldhsRPFMOvErBd2j2gtrWaKhHEOFgfAbwNKGHTIL/kJzQhE40RFFvkDdUmqVCfXpGU3aN1EWpg0xCOkScyco7plT5Xx5txcwMuubUB4Vp1+gkPkpabZyo2HhKG4JnQFjrQ9T3GhFJF/VQbFbIC647VuVXOc8eWyQXuK7DboVlc65W7g7HeAIzQ0BoA4Crmhst1Ok8O+3CjwrP/yOSagQKbyMDJdwWRzYho+TjuKnPls/KVhksDvu+x0SXS32+z+tLg6gyDmJ/oQgpnNpeBu6qESUBVv7gq1ZgrECqxMOKqWVPo2Jkf1aGBvAN7kU1t+5n7O/Xm3AYlYVgfuQVOHAjX90PMbEjkFkHLeK5dsMmW4v38NoYiPTJlgtW3fWPuCgZQmIxZ4zsodT8zRONgPcQoOoM55/HDn1iawTM 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 9/27/24 11:52 AM, jeffxu@chromium.org wrote: > From: Jeff Xu > > Update doc after in-loop change: mprotect/madvise can have > partially updated and munmap is atomic. > > Fix indentation and clarify some sections to improve readability. > > Signed-off-by: Jeff Xu > --- > Documentation/userspace-api/mseal.rst | 290 ++++++++++++-------------- > 1 file changed, 136 insertions(+), 154 deletions(-) > > diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst > index 4132eec995a3..68986084e191 100644 > --- a/Documentation/userspace-api/mseal.rst > +++ b/Documentation/userspace-api/mseal.rst > @@ -23,177 +23,159 @@ applications can additionally seal security critical data at runtime. > A similar feature already exists in the XNU kernel with the > VM_FLAGS_PERMANENT flag [1] and on OpenBSD with the mimmutable syscall [2]. > > -User API > -======== > -mseal() > ------------ > -The mseal() syscall has the following signature: > - > -``int mseal(void addr, size_t len, unsigned long flags)`` > - > -**addr/len**: virtual memory address range. > - > -The address range set by ``addr``/``len`` must meet: > - - The start address must be in an allocated VMA. > - - The start address must be page aligned. > - - The end address (``addr`` + ``len``) must be in an allocated VMA. > - - no gap (unallocated memory) between start and end address. > - > -The ``len`` will be paged aligned implicitly by the kernel. > - > -**flags**: reserved for future use. > - > -**return values**: > - > -- ``0``: Success. > - > -- ``-EINVAL``: > - - Invalid input ``flags``. > - - The start address (``addr``) is not page aligned. > - - Address range (``addr`` + ``len``) overflow. > - > -- ``-ENOMEM``: > - - The start address (``addr``) is not allocated. > - - The end address (``addr`` + ``len``) is not allocated. > - - A gap (unallocated memory) between start and end address. > - > -- ``-EPERM``: > - - sealing is supported only on 64-bit CPUs, 32-bit is not supported. > - > -- For above error cases, users can expect the given memory range is > - unmodified, i.e. no partial update. > - > -- There might be other internal errors/cases not listed here, e.g. > - error during merging/splitting VMAs, or the process reaching the max > - number of supported VMAs. In those cases, partial updates to the given > - memory range could happen. However, those cases should be rare. > - > -**Blocked operations after sealing**: > - 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. > - > - Moving or expanding a different VMA into the current location, > - via mremap(). > - > - Modifying a VMA via mmap(MAP_FIXED). > - > - 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. > - > - mprotect() and pkey_mprotect(). > - > - 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. > - > - Kernel will return -EPERM for blocked operations. > - > - For blocked operations, one can expect the given address is unmodified, > - i.e. no partial update. Note, this is different from existing mm > - system call behaviors, where partial updates are made till an error is > - found and returned to userspace. To give an example: > - > - Assume following code sequence: > - > - - ptr = mmap(null, 8192, PROT_NONE); > - - munmap(ptr + 4096, 4096); > - - ret1 = mprotect(ptr, 8192, PROT_READ); > - - mseal(ptr, 4096); > - - ret2 = mprotect(ptr, 8192, PROT_NONE); > - > - ret1 will be -ENOMEM, the page from ptr is updated to PROT_READ. > - > - ret2 will be -EPERM, the page remains to be PROT_READ. > - > -**Note**: > - > -- mseal() only works on 64-bit CPUs, not 32-bit CPU. > - > -- users can call mseal() multiple times, mseal() on an already sealed memory > - is a no-action (not error). > - > -- munseal() is not supported. > +SYSCALL > +======= > +mseal syscall signature > +----------------------- > + **int** mseal(**void \*** addr, **size_t** len, **unsigned long** flags) ugh. totally unreadable for people who just look at .rst files. Does other documentation go to this extreme? > + > + **addr**/**len**: virtual memory address range. > + The address range set by **addr**/**len** must meet: > + - The start address must be in an allocated VMA. > + - The start address must be page aligned. > + - The end address (**addr** + **len**) must be in an allocated VMA. > + - no gap (unallocated memory) between start and end address. > + > + The ``len`` will be paged aligned implicitly by the kernel. > + > + **flags**: reserved for future use. > + > + **Return values**: > + - **0**: Success. > + - **-EINVAL**: > + * Invalid input ``flags``. > + * The start address (``addr``) is not page aligned. > + * Address range (``addr`` + ``len``) overflow. > + - **-ENOMEM**: > + * The start address (``addr``) is not allocated. > + * The end address (``addr`` + ``len``) is not allocated. > + * A gap (unallocated memory) between start and end address. > + - **-EPERM**: > + * sealing is supported only on 64-bit CPUs, 32-bit is not supported. > + > + **Note about error return**: > + - For above error cases, users can expect the given memory range is > + unmodified, i.e. no partial update. > + - There might be other internal errors/cases not listed here, e.g. > + error during merging/splitting VMAs, or the process reaching the max > + number of supported VMAs. In those cases, partial updates to the given > + memory range could happen. However, those cases should be rare. > + > + **Architecture support**: > + mseal only works on 64-bit CPUs, not 32-bit CPU. CPUs. > + > + **Idempotent**: > + users can call mseal multiple times, mseal on an already sealed memory times. mseal > + is a no-action (not error). > + > + **no munseal** > + Once mapping is sealed, it can't be unsealed. kernel should never > + have munseal, this is consistent with other sealing feature, e.g. > + F_SEAL_SEAL for file. > + > +Blocked mm syscall for sealed mapping > +------------------------------------- > + It might be imporant to note: **once the mapping is sealed, it will important > + stay in the process's memory till the process terminates**. > + > + Example:: > + > + *ptr = mmap(0, 4096, PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, 0, 0); > + rc = mseal(ptr, 4096, 0); > + /* munmap will fail */ > + rc = munmap(ptr, 4096); > + assert(rc < 0); > + > + Blocked mm syscall: > + - munmap > + - mmap > + - mremap > + - mprotect and pkey_mprotect > + - some destructive madvise behaviors: MADV_DONTNEED, MADV_FREE, > + MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, MADV_WIPEONFORK > + > + The first set of syscall to block is munmap, mremap, mmap. They can > + either leave an empty space in the address space, therefore allow > + replacement with a new mapping with new set of attributes, or can > + overwrite the existing mapping with another mapping. > + > + mprotect and pkey_mprotect are blocked because they changes the > + protection bits (rwx) of the mapping. preferably (RWX) > + > + Some destructive madvice behaviors (MADV_DONTNEED, MADV_FREE, madvise > + MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, MADV_WIPEONFORK) > + 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. > + > + Kernel will return -EPERM for blocked syscalls. > + > + When blocked syscall return -EPERM due to sealing, the memory regions may or may not be changed, depends on the syscall being blocked: > + - munmap: munmap is atomic. If one of VMAs in the given range is > + sealed, none of VMAs are updated. > + - mprotect, pkey_mprotect, madvise: partial update might happen, e.g. > + when mprotect over multiple VMAs, mprotect might update the beginning > + VMAs before reaching the sealed VMA and return -EPERM. > + - mmap and mremap: undefined behavior. > > Use cases: > ========== > - glibc: > The dynamic linker, during loading ELF executables, can apply sealing to > - non-writable memory segments. > + mapping segments. > > - Chrome browser: protect some security sensitive data-structures. data structures. > > -Notes on which memory to seal: > -============================== > - > -It might be important to note that sealing changes the lifetime of a mapping, > -i.e. the sealed mapping won’t be unmapped till the process terminates or the > -exec system call is invoked. Applications can apply sealing to any virtual > -memory region from userspace, but it is crucial to thoroughly analyze the > -mapping's lifetime prior to apply the sealing. > +Don't use mseal on: Drop the ':'. Headings should not uses trailing colons. (throughout this file) Maybe change the heading to "When not to use mseal". > +=================== > +Applications can apply sealing to any virtual memory region from userspace, > +but it is *crucial to thoroughly analyze the mapping's lifetime* prior to > +apply the sealing. This is because the sealed mapping *won’t be unmapped* > +till the process terminates or the exec system call is invoked. s/till/until/ preferably. > > For example: > + - aio/shm > + aio/shm can call mmap and munmap on behalf of userspace, e.g. > + ksys_shmdt() in shm.c. The lifetime of those mapping are not tied to > + the lifetime of the process. If those memories are sealed from userspace, > + then munmap will fail, causing leaks in VMA address space during the > + lifetime of the process. > + > + - ptr allocated by malloc (heap) > + Don't use mseal on the memory ptr return from malloc(). > + malloc() is implemented by allocator, e.g. by glibc. Heap manager might > + allocate a ptr from brk or mapping created by mmap. > + If app calls mseal on ptr returned from malloc(), this can affect the heap If an app calls mseal on a ptr > + manager's ability to manage the mappings, the outcome is non-deterministic. mappings; the outcome > + Example:: > + > + ptr = malloc(size); > + /* don't call mseal on ptr return from malloc. */ > + mseal(ptr, size); > + /* free will success, allocator can't shrink heap lower than ptr */ > + free(ptr); > + > +mseal doesn't block: > +==================== > +In a nutshell, mseal blocks certain mm syscall from modifying some of VMA's > +attributes, such as protection bits (rwx). Sealed mappings doesn't mean the preferably (RWX). > +memory is immutable. > > -- aio/shm > - > - aio/shm can call mmap()/munmap() on behalf of userspace, e.g. ksys_shmdt() in > - shm.c. The lifetime of those mapping are not tied to the lifetime of the lifetimes ? > - process. If those memories are sealed from userspace, then munmap() will fail, > - causing leaks in VMA address space during the lifetime of the process. > - > -- Brk (heap) > - > - Currently, userspace applications can seal parts of the heap by calling > - malloc() and mseal(). > - let's assume following calls from user space: > - > - - ptr = malloc(size); > - - mprotect(ptr, size, RO); > - - mseal(ptr, size); > - - free(ptr); > - > - Technically, before mseal() is added, the user can change the protection of > - the heap by calling mprotect(RO). As long as the user changes the protection > - back to RW before free(), the memory range can be reused. > - > - Adding mseal() into the picture, however, the heap is then sealed partially, > - the user can still free it, but the memory remains to be RO. If the address > - is re-used by the heap manager for another malloc, the process might crash > - soon after. Therefore, it is important not to apply sealing to any memory > - that might get recycled. > - > - Furthermore, even if the application never calls the free() for the ptr, > - the heap manager may invoke the brk system call to shrink the size of the > - heap. In the kernel, the brk-shrink will call munmap(). Consequently, > - depending on the location of the ptr, the outcome of brk-shrink is > - nondeterministic. > - > - > -Additional notes: > -================= > As Jann Horn pointed out in [3], there are still a few ways to write > -to RO memory, which is, in a way, by design. Those cases are not covered > -by mseal(). If applications want to block such cases, sandbox tools (such as > -seccomp, LSM, etc) might be considered. > +to RO memory, which is, in a way, by design. And those could be blocked > +by different security measures. > > Those cases are: > - > -- Write to read-only memory through /proc/self/mem interface. > -- Write to read-only memory through ptrace (such as PTRACE_POKETEXT). > -- userfaultfd. > + - Write to read-only memory through /proc/self/mem interface (FOLL_FORCE). > + - Write to read-only memory through ptrace (such as PTRACE_POKETEXT). > + - userfaultfd. > > The idea that inspired this patch comes from Stephen Röttger’s work in V8 > CFI [4]. Chrome browser in ChromeOS will be the first user of this API. > > Reference: > ========== > -[1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274 > - > -[2] https://man.openbsd.org/mimmutable.2 > - > -[3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.com > - > -[4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc > +- [1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274 > +- [2] https://man.openbsd.org/mimmutable.2 > +- [3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.com > +- [4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc