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 3D6B8D1F9C5 for ; Tue, 15 Oct 2024 20:00:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A40C46B007B; Tue, 15 Oct 2024 16:00:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F1536B0082; Tue, 15 Oct 2024 16:00:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B91B6B0083; Tue, 15 Oct 2024 16:00:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6A4756B007B for ; Tue, 15 Oct 2024 16:00:36 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 942CC1A188A for ; Tue, 15 Oct 2024 20:00:19 +0000 (UTC) X-FDA: 82676903736.19.9B77809 Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) by imf22.hostedemail.com (Postfix) with ESMTP id A493FC0024 for ; Tue, 15 Oct 2024 20:00:24 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=dEZWNJAs; spf=pass (imf22.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.45 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729022360; a=rsa-sha256; cv=none; b=QgOh0Fv108qg7LxEDDaUOZfPBX4Xpcw3KXEtwHOqjBnKMtUJjsKoEu6NHOrwKnYeW5za3K QCJwqWKZ2lyzQCkFun5UEYAuv9odpJL+Qd5grihbbWOmy6qgOdQiclIO/ld+8+yDvU5qzD Y8pfxKGFKqrZwebcnOfXFnPNXmA3t7o= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=dEZWNJAs; spf=pass (imf22.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.45 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729022360; 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=x+NFu9pFnYL/Wg5GSs6A+HFmdxihVVocbF37KmhdNV4=; b=d+F/F7u3TjWQZcJdkBDBUc9lQF0ORMKy0btiyeDmoOQhDv9mzbeyLASR/VZGuNTkxWrpky 2rKnZVSbAQokja5/jPqJsapv9B+U2EMdVmXtHFjWZxwajpFpgSUixHTm+TnMAwYkmh5Eam HqE87Bb3cze8IpZN0r35NrD/51lgQw0= Received: by mail-ot1-f45.google.com with SMTP id 46e09a7af769-718062c1989so11031a34.0 for ; Tue, 15 Oct 2024 13:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1729022432; x=1729627232; 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=x+NFu9pFnYL/Wg5GSs6A+HFmdxihVVocbF37KmhdNV4=; b=dEZWNJAsCgQ1LBpw+q13I6MefhnKNlyT1qoM5CExH3wxgCTStO7kFzzwPYVjjaUB7Y ZMAN/eBAHuiacn7WL9C78LLSf57ytHsZfKIztlB57PLRB5j/XZ+LTWCvEdby4ZXukrMN hrxRgGyIib0hF9BCpOLnqX5GvLy8WKCKFmDyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729022432; x=1729627232; 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=x+NFu9pFnYL/Wg5GSs6A+HFmdxihVVocbF37KmhdNV4=; b=vCubtX/o513YjNW8jzYMc8xs1Ty9j47+7VN3Iglf2otIFs4cRwfRcAAbd+obRvKKXO 3PwkN8Rr8weNpOV72j4dY+Wjwy/F9wlqP0XBNWCn4U8BkbOgAcHoR1i7nW3Tnmo0oVk7 QXow2MwF/iMQnndJjqqRKotgGrDhLu7yJqhFc6ZeSnAmECWExcdmvTJlmQvnPIrMxw/d 4bXbZ32MaNA51H0kCYsD8LeIh5U3eB4uZzIu5URW1jx+hXj0Y9BMQGoz9cFMaKQfUvEp ON/jtfyZmElfiIopnJUeFfhfUAo6w8Weezwodw2kzUXY1OCTLX1nT7NDZRUX2O3NhrOD sljw== X-Forwarded-Encrypted: i=1; AJvYcCU0teBRL15GlId6rEsbENUY7Q65PO82TfACRReWi7R1JTGPCcY8bCFTEfTC33ta9su2wbtfquuNxg==@kvack.org X-Gm-Message-State: AOJu0YxkOa1HgN1DB2ldyBlFlIdL8WVMXe4MjsM+apjryOwTYNoZ7ho5 X7vszWeHR5o8FFI1TSwYODl/hkzs0SeqzMiPFY45deieNrW7A1FSqI3E822f+8j61tByYFFLu/w +KLzi8h/lRRQzMU3f2IV7WpHuwcFNFDtBHCap X-Google-Smtp-Source: AGHT+IH1S5utfvwpODzfC9epIfrxTAxik14I4f/mxwMdg+isPf9IbBIwtTXGpJ6BejuAzx97/uTs8jGADawbLpFjPuM= X-Received: by 2002:a05:6870:b28a:b0:278:8f5:a567 with SMTP id 586e51a60fabf-288f40219f5mr128308fac.5.1729022432351; Tue, 15 Oct 2024 13:00:32 -0700 (PDT) MIME-Version: 1.0 References: <20241008040942.1478931-1-jeffxu@chromium.org> <20241008040942.1478931-2-jeffxu@chromium.org> In-Reply-To: <20241008040942.1478931-2-jeffxu@chromium.org> From: Jeff Xu Date: Tue, 15 Oct 2024 13:00:00 -0700 Message-ID: Subject: Re: [PATCH v3 1/1] mseal: update mseal.rst To: akpm@linux-foundation.org, keescook@chromium.org, corbet@lwn.net Cc: 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, rdunlap@infradead.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, enh@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: bxqopfoth58j8qiqqwmw1ryihx8c13de X-Rspamd-Queue-Id: A493FC0024 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1729022424-716299 X-HE-Meta: U2FsdGVkX1+OEyKPboImBJLa4DIe6915jkrPFpK/jYndi55CVULyH4DTJMA9YjbYazyk2yp2pXkThL+KAQP2pVxSO+d2ccpxHIgFgleqRHeDNJHVCHOrDT7tDSlQIi49raqSkT0oLAsK2NNT/8cGGHgzaIdSonVs+UWRWUf4tkMfyNYjltdaPshd7WHBsvq7dyIcRnJ2f85YJzozK38FHWi541wSU8CYM88Za5jizR23Lazy+L3NFJ8RR5brG4WUxVNPUZ30qbjSNSKI/y4XNW/a3Ae1wQA4rFrWw/uMiWotL0/Iz4FCstp1Do7j4SHx/kHmzL8PMd3JzgYWiDRVF9csNtK4F2jCIdETxAB7p1xBwsZOCw8gQGYbNg492TiljbTK4K7sYsebzZUbLPJtxgkpFoII3WI9ec8466QMOf5XCl9/zCfEmm2fqm4ItKejkm3wJ8B9qZe34quGTLwdjX6pTHaiL8NxPON3LtxzHp/vl8Q5MzPTK8M37EAtLQ5aUc0UNFSaOWFu1ILfNBbObKwTWHNlVcaEA9rxRe50ssjUS1w3ls6vpnxNNZjQm5HjW+Kz6zJWCgMT95zwEv0f7qhlavK1NmU9/Pku6MBanpQBM16CRkNMJkJ49CncvNjApjGECROjLT5aztCkjXTBMTU/k24azhdtglLd5StmNgziPYbMj0Em979je5Pg8fykPROUM2wY3AbxeX6TCO/FH4SVBNUBdBii/ZB34NfePi0Z7GWEVT0oydf39WZzzNJcrWTZVZTC0K9s9g7MVFpGGch/tYC2qizG8AxPULXXy8Nb0AIzdTopB3z1rxs+2ypdA7QbpXCyVchI1lkoJPWJObFwaMY8TTGrOHvc1o6jqiYWPu8W6vw6+bMYyhx9XSeqZDP+ydMOMazobOn3NF5NezhsCxZI3j7HiK+yHVolKJ0a0rzH42IIWfy81CKzQuye4vuNj1VYBw81q+hgxIT f/HyynAj 4r9JLuXhAz/u4XIBeNDVUeLU8ICmzM0XMwAz+FiJnI92I4PH0hzMK1UMGZiatSET1w3NgKtjjuNWwWzjbx2eAMbSwyhoXOY93OYej/26faHi79D3LYaZ04ztgpy8eJNNHPA6Rcwh6gzkoPil0s2sX5KPQWjKHOXMFUm9iNtFSUEbCC2zYhiDxFOe4OrDFdy0xyKeFXTRfyuYZrgtarWesMNz+m2UyQQ5+vu6OPmE1aukrNMHxnSTNJdDFljF2c+PmKvhFFwYe9OSFHHTt9WtQJ0R4gtp2cxHrQj8j7bkaB148HnAqGreYgm+sN9oFB7RdgyDokkpW/vaHh9y5C1wcI3sAqZvWGh+eq8dflYgTaBCxzn/p+Dfup0cdJfB3lqzSZEccKcNC6RIpGoyopN5S6x4Hl0fpwvuk/ULQbEzXtynbuT3wYYnvN+gxj9IYvJyqBYhI7tf3CqA5YquHWcMbSioQU8GhjyIAOhbv/BSFeX7Hm6iO7DX8sC6I/K2WqhlRNIpxgdwyjNBsvznlztr7SzXB+PVow/7EdNMc 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: Hi Andrew, If there is no objection, please pull this v3 patch to mm-unstable. I believe I already responded to all comments related to this patch. This will keep mseal.rst up-to-date with current implementation of memory sealing. Thanks -Jeff On Mon, Oct 7, 2024 at 9:09=E2=80=AFPM 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 > Fixes: df2a7df9a9aa ("mm/munmap: replace can_modify_mm with can_modify_vm= a") > Fixes: 4a2dd02b0916 ("mm/mprotect: replace can_modify_mm with can_modify_= vma") > Fixes: 38075679b5f1 ("mm/mremap: replace can_modify_mm with can_modify_vm= a") > Fixes: 23c57d1fa2b9 ("mseal: replace can_modify_mm_madv with a vma varian= t") > Reviewed-by: Randy Dunlap > --- > Documentation/userspace-api/mseal.rst | 307 +++++++++++++------------- > 1 file changed, 148 insertions(+), 159 deletions(-) > > diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/usersp= ace-api/mseal.rst > index 4132eec995a3..41102f74c5e2 100644 > --- a/Documentation/userspace-api/mseal.rst > +++ b/Documentation/userspace-api/mseal.rst > @@ -23,177 +23,166 @@ applications can additionally seal security critica= l 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 > -=3D=3D=3D=3D=3D=3D=3D=3D > -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 page= s, > - effectively a memset(0) for anonymous memory. > - > - Kernel will return -EPERM for blocked operations. > - > - For blocked operations, one can expect the given address is unmodifi= ed, > - 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 =3D mmap(null, 8192, PROT_NONE); > - - munmap(ptr + 4096, 4096); > - - ret1 =3D mprotect(ptr, 8192, PROT_READ); > - - mseal(ptr, 4096); > - - ret2 =3D 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 me= mory > - is a no-action (not error). > - > -- munseal() is not supported. > - > -Use cases: > -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +SYSCALL > +=3D=3D=3D=3D=3D=3D=3D > +mseal syscall 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 suppo= rted. > + > + **Note about error return**: > + - For above error cases, users can expect the given memory range i= s > + 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= maximum > + 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 CPUs. > + > + **Idempotent**: > + users can call mseal multiple times. mseal on an already sealed me= mory > + is a no-action (not error). > + > + **no munseal** > + Once mapping is sealed, it can't be unsealed. The kernel should ne= ver > + 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 important to note: **once the mapping is sealed, it will > + stay in the process's memory until the process terminates**. > + > + Example:: > + > + *ptr =3D mmap(0, 4096, PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, = 0, 0); > + rc =3D mseal(ptr, 4096, 0); > + /* munmap will fail */ > + rc =3D 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 syscalls to block is munmap, mremap, mmap. They can > + either leave an empty space in the address space, therefore allowing > + 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. > + > + Certain destructive madvise behaviors, specifically MADV_DONTNEED, > + MADV_FREE, MADV_DONTNEED_LOCKED, and MADV_WIPEONFORK, can introduce > + risks when applied to anonymous memory by threads lacking write > + permissions. Consequently, these operations are prohibited under such > + conditions. The aforementioned behaviors have the potential to modify > + region contents by discarding pages, effectively performing a memset(= 0) > + operation on the 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 begi= nning > + VMAs before reaching the sealed VMA and return -EPERM. > + - mmap and mremap: undefined behavior. > + > +Use cases > +=3D=3D=3D=3D=3D=3D=3D=3D=3D > - glibc: > The dynamic linker, during loading ELF executables, can apply sealing = to > - non-writable memory segments. > - > -- Chrome browser: protect some security sensitive data-structures. > + mapping segments. > > -Notes on which memory to seal: > -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > +- Chrome browser: protect some security sensitive data structures. > > -It might be important to note that sealing changes the lifetime of a map= ping, > -i.e. the sealed mapping won=E2=80=99t be unmapped till the process termi= nates or the > -exec system call is invoked. Applications can apply sealing to any virtu= al > -memory region from userspace, but it is crucial to thoroughly analyze th= e > -mapping's lifetime prior to apply the sealing. > +When not to use mseal > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +Applications can apply sealing to any virtual memory region from userspa= ce, > +but it is *crucial to thoroughly analyze the mapping's lifetime* prior t= o > +apply the sealing. This is because the sealed mapping *won=E2=80=99t be = unmapped* > +until the process terminates or the exec system call is invoked. > > For example: > + - aio/shm > + aio/shm can call mmap and munmap on behalf of userspace, e.g. > + ksys_shmdt() in shm.c. The lifetimes of those mapping are not tied = to > + the lifetime of the process. If those memories are sealed from user= space, > + then munmap will fail, causing leaks in VMA address space during th= e > + 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 m= ight > + allocate a ptr from brk or mapping created by mmap. > + If an app calls mseal on a ptr returned from malloc(), this can aff= ect > + the heap manager's ability to manage the mappings; the outcome is > + non-deterministic. > + > + Example:: > + > + ptr =3D 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 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +In a nutshell, mseal blocks certain mm syscall from modifying some of VM= A's > +attributes, such as protection bits (RWX). Sealed mappings doesn't mean = the > +memory is immutable. > > -- aio/shm > - > - aio/shm can call mmap()/munmap() on behalf of userspace, e.g. ksys_shm= dt() in > - shm.c. The lifetime of those mapping are not tied to the lifetime of t= he > - process. If those memories are sealed from userspace, then munmap() wi= ll 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 callin= g > - malloc() and mseal(). > - let's assume following calls from user space: > - > - - ptr =3D malloc(size); > - - mprotect(ptr, size, RO); > - - mseal(ptr, size); > - - free(ptr); > - > - Technically, before mseal() is added, the user can change the protecti= on of > - the heap by calling mprotect(RO). As long as the user changes the prot= ection > - back to RW before free(), the memory range can be reused. > - > - Adding mseal() into the picture, however, the heap is then sealed part= ially, > - the user can still free it, but the memory remains to be RO. If the ad= dress > - is re-used by the heap manager for another malloc, the process might c= rash > - soon after. Therefore, it is important not to apply sealing to any mem= ory > - that might get recycled. > - > - Furthermore, even if the application never calls the free() for the pt= r, > - 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: > -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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 (suc= h 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_FO= RCE). > + - Write to read-only memory through ptrace (such as PTRACE_POKETEXT). > + - userfaultfd. > > The idea that inspired this patch comes from Stephen R=C3=B6ttger=E2=80= =99s work in V8 > CFI [4]. Chrome browser in ChromeOS will be the first user of this API. > > -Reference: > -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > -[1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff= 177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274 > - > -[2] https://man.openbsd.org/mimmutable.2 > - > -[3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ42= 6FkcgnfUGLvA@mail.gmail.com > - > -[4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdv= xQMyXgeaRHo/edit#heading=3Dh.bvaojj9fu6hc > +Reference > +=3D=3D=3D=3D=3D=3D=3D=3D=3D > +- [1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37a= ff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274 > +- [2] https://man.openbsd.org/mimmutable.2 > +- [3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ= 426FkcgnfUGLvA@mail.gmail.com > +- [4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmw= dvxQMyXgeaRHo/edit#heading=3Dh.bvaojj9fu6hc > -- > 2.47.0.rc0.187.ge670bccf7e-goog >