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 AE156CF648A for ; Fri, 27 Sep 2024 22:59:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B6416B0152; Fri, 27 Sep 2024 18:59:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 33E6C6B0153; Fri, 27 Sep 2024 18:59:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 191D96B0154; Fri, 27 Sep 2024 18:59:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E464D6B0152 for ; Fri, 27 Sep 2024 18:59:33 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 92ED740F74 for ; Fri, 27 Sep 2024 22:59:33 +0000 (UTC) X-FDA: 82612036626.16.18B087B Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf28.hostedemail.com (Postfix) with ESMTP id A08E8C0004 for ; Fri, 27 Sep 2024 22:59:31 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WPIKtEij; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727477934; a=rsa-sha256; cv=none; b=vVa/0P5yy1+F2k2x66jgYW45fCTf+viLeTwHbYh0SgbinaOyf6d/gq4awSxgBrZ/8vZ7cr wm0HXQSiHHQ8kfe85wRMxVTi3GZknUU95OQKI+3k4kga7Os7tfUEvYy/lzoSMbZPkCSDAz s2Ur5MH7GCi7m0DfGE6ll9cOBOT7Cp8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WPIKtEij; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727477934; 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=9IqvAfv1WChqsnSxf6qk/OUoO+gjURXmnUlf+mo6cUY=; b=sSRDeaTCcT22mR9g9N6EAy+OQabbnZwckg/0loWqx/0Xw01kk+seO61t7Hg7zEA9WGxqJ3 w192nhhbe6v3/ieiQWb2xjsbtu1a6lsirDCddWk+Z8HdHAkyxqfdB1EAqk5ARWECRymgg7 2AVBEKvzsRHWXvW+N9jpxwoDcPpB+uo= Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-42cb2191107so22242645e9.1 for ; Fri, 27 Sep 2024 15:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727477970; x=1728082770; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=9IqvAfv1WChqsnSxf6qk/OUoO+gjURXmnUlf+mo6cUY=; b=WPIKtEijoupFqRDJM3RL7QacvE3jgnJyJ8P2t0+evwORA8EbKyrJZv6LOkGdD6s7QJ cK2xi4Jiorkj0YZnG670DciYpeGncub9nog1V49NYSHcbnFLiqKhrOPM6JW7iA1/usGp 83nmwcpywWiCXidrQPdVn4Z94GmWyxhHKBsEJEmYN0/ecxqVbDjAslQMULAUedhQM6mZ wzl4HhG5W1Exx//nbXrudXeUT7Aijg+6K7RgxX7D/vCnkL0Cyc0OQJNoZcavsdpiLtky /+wqL0UEvmiV46ywHsbvGdK3nIFWMUtfIYsiAAd07vJfvK9laf/p38hnl+hu3NqZnycC 6y+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727477970; x=1728082770; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9IqvAfv1WChqsnSxf6qk/OUoO+gjURXmnUlf+mo6cUY=; b=g01+MQc9JQ+K16r1TnrbWpYi6DwV2mz9iTmEjrY5VBN578tgsCjGFXNcEsFERfXWfn RyT/ZCiUyUOONckuD3v+tbAc63nV5oDHt7oWGp2n2FzgJqptIbfcaIYqMH+eIrX+U66K 6DfEcqiGxDG1zpYoC9joQNCyKWIzq3uT1f7Bmw62O696fQHNp8FH19axoK9SqwtgkyHd 2NDoCY+6xvoc889ydygOcqTbgHd4jImfhLLQaZELqaZCECzYYC/4ZSVu6xu0qvSmZorf tfugODwvp7w59MnCTGxCChjxYDCS2/R9h0RoNZF86sWsscCNPNOs1Z/IAY/mq7j05rV7 bEpQ== X-Forwarded-Encrypted: i=1; AJvYcCWhQXwgfnK7mTZ4UqK4Xqf7wVqPlJsUkklFOTHSy2qWpR6yiFTM1oyBWhuFdfLc6w988993xXagEQ==@kvack.org X-Gm-Message-State: AOJu0YyBkqaP6LMB15qziytzbIN1sG1nNx/L0P6tbYqeEQMWUkSIUNRf e5lzyUCS5KPMro3ZTtY+NR8sjUqihiHaVAzdayrfZJbBQC+S+xF6 X-Google-Smtp-Source: AGHT+IGXhQLBp+2IDSoNG/6a4mJ3jnJ1ET1yK4zMuulZ6WQEcJDYas3gjDFnxnMYDAzFnDSEVyIc9w== X-Received: by 2002:a05:600c:46c5:b0:428:150e:4f13 with SMTP id 5b1f17b1804b1-42f5849c3b5mr35343625e9.33.1727477969641; Fri, 27 Sep 2024 15:59:29 -0700 (PDT) Received: from PC-PEDRO-ARCH ([2001:818:e92f:6400:a118:25f3:b27f:9f34]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37cd56e8822sm3522902f8f.50.2024.09.27.15.59.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Sep 2024 15:59:28 -0700 (PDT) Date: Fri, 27 Sep 2024 23:59:25 +0100 From: Pedro Falcato To: jeffxu@chromium.org Cc: akpm@linux-foundation.org, keescook@chromium.org, corbet@lwn.net, 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, 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 Subject: Re: [PATCH v1 1/1] mseal: update mseal.rst Message-ID: <2vkppisejac42wnawjkd7qzyybuycu667yxwmsd4pfk5rwhiqc@gszyo5lu24ge> References: <20240927185211.729207-1-jeffxu@chromium.org> <20240927185211.729207-2-jeffxu@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240927185211.729207-2-jeffxu@chromium.org> X-Rspam-User: X-Rspamd-Queue-Id: A08E8C0004 X-Rspamd-Server: rspam01 X-Stat-Signature: m7y9qbtei88u5xcpzadrr8c6a7rqq9kx X-HE-Tag: 1727477971-242405 X-HE-Meta: U2FsdGVkX1+AEYvy6SWw0EHuG69wmVJID7q+/WvhTObcfpdJI0jTVmynLhau70zjbT4IBtIhpwNfUmZzUeVWhZHVw6gx6y/XAiojgyglMknBLm+1tyEjkoTU+FTIXNpIhJo44qpT2UNg+q+mMzHyR89y4QGxxWh3b/Zx+wnDJN+/y5qWmj/E8EEdtYB1CZb1P9gfov6OGuylXcWqPb5Pbit2hc7KB8Oo3Du9dxfeFqpidj5Dl1KBuKWKvPrlUtKm2APys3iZ29Kopht+0jeUWacsVWpUdxQ28/hxooBKnH38jvkhdaQ7bkHIIi7laOwEi3Q2PbXiJfG30WO0V2AuGa7WUt2dLGrqgefhv2PrVSNvWQSxILixBfDEoIAoNHUYVUAil8W36jJ7CoS5P5iOvEM7IdDqMR1PZrwmJoubUc/rqHADGkd0MIsEfT4NgMqlV7/iHzgklEd8qU+ubddn4Tk125KAFuvj13veHRE5HqcB+g94H9kIFm/Nd5uuDOc82VAKXR5FuVLztPysF8dPWJ4kPrnFEl+/Mj7lbSdko6Q8xfXYs2dwgoVOTQlP303NZQ8+v/NaKSPY++m4D0risYHY2/JBKu8//bOY3AAUs0adYyMZRrBEpcLYhAiLi0tgYBE1y4AQKNJtmea89rx8q7wAKAe/3Qoscyg567Q3NyXgpUftNWn5Q5dZlYEMAV6otlYMSh0ylbl8w0bZ/I6ta0krw3/jmS72RMEH79w+IVaXQ99yE7/y0SVQf7vIL3U9NSeaobKR8OA7eqWGbBXUlNhh5TeNJhexWEn1/CKKD5SFdu3ugwBfKHkzZV5Cis2HykdzVieE4dI1XfT8n0I5QHwVZwgMrzXBco7BTMAX2BOtllrRvQXfpzGXPNb1HogX0oMlb0k6doDT6AODN3xfJHHZIjdZ2GxC/3YwgCSpVL+0nZvT5eaSuK0yUTiRwSFLQaJgOUUdhPNlDV7KopC oEUBpLi3 KmYYkSJv61nM77nSp43fa8Fqd1RO5NEdTklCv56ddfxqyqocGF4El9afb92Q6g0eBxWPx0YAWGaKVVXc/un4uZMX3dHogw92l+9KD7x4fmOGM5/2bVayxV5YeD/SaIQlCuLM9/dBZuuV46+RowjNz2kZnZusqSPhC1GGMYE/fWV/tiXVgT5xfusYlz6eWd8QCeEhe2s3Vgm+HIGL+6YmTqoUKdVExKry5G3BUlLw7ft9f0898IWR3oSi/4FbzSzC6a2w4A70tzZhgiumLhoijDBWLxCYoluFgfWTmo1IHh8Uzb8qg8i7jh6hwYg41QPYiK8HN8oLcEV916NR6vHeHpo5pI/TyAKm1xzkgk4PogH+q2zagiCIMuERUzoneH8pBFNI/eWZiqsfJL1aXSikgzdBMOLHWdMLwwcwMEf3E5Rm4jZzDJjmXKn88nhc1IvqP/lEyMDDjjTIKnyHyw7eOt5Mop1n5noOpExPY9/PkiD6UtYvjbmzfNGrrSvnc0KbrCQN3nbCjFj0aN8M= 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 Fri, Sep 27, 2024 at 06:52:09PM GMT, 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) > + > + **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. How about turning the above into a man page? > + **Architecture support**: > + mseal only works on 64-bit CPUs, not 32-bit CPU. > + > + **Idempotent**: > + users can call mseal multiple times, mseal on an already sealed memory > + 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 > + 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 change > + protection bits (rwx) of the mapping. > + > + Some destructive madvice behaviors (MADV_DONTNEED, MADV_FREE, > + 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. What's the difference between anonymous memory and MAP_PRIVATE | MAP_FILE? The feature now, as is (as far as I understand!) will allow you to do things like MADV_DONTNEED on a read-only file mapping. e.g .text. This is obviously wrong? > + > + 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. mmap and mremap are actually not undefined as they use munmap semantics for their unmapping. Whether this is something we'd want to document, I don't know honestly (nor do I think is ever written down in POSIX?) > > 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. > > -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: > +=================== > +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. There should probably be a nice disclaimer as to how most people don't need this or shouldn't use this. At least in its current form. > - > - > -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. I don't understand how this is not a problem, but MADV_DONTNEED is. To me it seems that what we have now is completely useless, because you can trivially bypass it using /proc/self/mem, which is enabled on most Linux systems. Before you mention ChromeOS or Chrome, I don't care. Kernel features aren't designed for Chrome. They need to work with every other distro and application as well. It seems to me that the most sensible change is blocking/somehow distinguishing between /proc/self/mem and /proc//mem (some other process) and ptrace. As in blocking /proc/self/mem but allowing the other FOLL_FORCE's as the traditional UNIX permission model allows. -- Pedro