From patchwork Mon Jan 22 15:28:46 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jeff Xu X-Patchwork-Id: 13525657 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 8988BC47DDB for ; Mon, 22 Jan 2024 15:29:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 200A28D0006; Mon, 22 Jan 2024 10:29:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 187088D0002; Mon, 22 Jan 2024 10:29:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED0178D0007; Mon, 22 Jan 2024 10:29:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D0A048D0006 for ; Mon, 22 Jan 2024 10:29:12 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A7EC4C0960 for ; Mon, 22 Jan 2024 15:29:12 +0000 (UTC) X-FDA: 81707330544.23.28A3834 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf04.hostedemail.com (Postfix) with ESMTP id BF73540020 for ; Mon, 22 Jan 2024 15:29:09 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=NogRNYPe; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf04.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.214.175 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=1705937349; 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: references:dkim-signature; bh=7wQcbezNT+/RjXYY8eCSxvRyrPZ4DMIc5I/z5N1RfdQ=; b=f71mUnwpv67DjcdQ+c4zTPdh3Z1l7KaczsBf4LAix9LCGKO1t7ykux0CCc0KcJEXFJNCeW Sj4HnxJwA5itLphkb8ZvISS7vQraiBzKVfQIoUmyNhIM/YsXguf1eACvLGSoJZIbgVOJzQ 6X8MObrhXuoqcSq13PZ3l661/uxp9Hc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=NogRNYPe; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf04.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.214.175 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705937349; a=rsa-sha256; cv=none; b=IXZh/GyQ+wlv5o2DHv9cHveVbfVnnjJWSsUUAiVeOvP6/CuZqa8WPy4OjnJh8xlkGXbAET WqqTOhfygMnPhwTBkYzVVs9OAraBQXLcZO66HHa9ZW5p+R6o08yX2CXvrA6aoMV/wBSg4h Pxw2IXLQVogwZMgQXOqgASkkcKmtUTE= Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1d75ea3a9b6so5801895ad.2 for ; Mon, 22 Jan 2024 07:29:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1705937348; x=1706542148; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=7wQcbezNT+/RjXYY8eCSxvRyrPZ4DMIc5I/z5N1RfdQ=; b=NogRNYPeb2QIlawS/fRkhiUIS4uz/ZgfSZfXvzToYn1JsAXpIXC7hXSrfSW21d4OKA /XrhgrlLWutoSUzf7ubMJKyEVkHPYUsbtgyGrxec9HWqI+V3Mzu0ytyOrAdW2ZN4dfDV KVmLV2O7KaCZuwPwdjekSVIolKYfoa6w7uDdU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705937348; x=1706542148; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7wQcbezNT+/RjXYY8eCSxvRyrPZ4DMIc5I/z5N1RfdQ=; b=Wm9Aq7WNhW7SlAV9/r986kD8Q/6WfXn6Cuoflh2wS6DCsSn0x5P1m/RIEMfwEgjcRB fDr/4qiDOZ7ZYCu+YpNF06Z+8J5/+TRwyo/wrZ7KAyAGhqd+GAYdPT+je7tFrU7yidb0 XkBcbohh9Ije4zxkT5PmsTRFYUCB2mBUQwZF2b38AwYYcQt2w6c/y1wbmuomBW9XWU3q eKx+HkoNYanaq0D1I3qEYqDnFKdXNlYJ/iUj1trg8khv7KTdpF76Hq/t/cX6DLIPwrcv X7J8cveydwhxoZ/U9Rbj5AqgTl2aaVuvvIDy8Ay5Or3X3HxL1tHgPAZG3+H7Ksm49Va0 ZkJg== X-Gm-Message-State: AOJu0YzAunD8+xBIeaWur1OovCYLSt8wSYlb3zSBU64ZQUv+CtLvF/P8 eYU25EoJZfo2Ax7qinxxoh5iP+GvalsZIaBZUILKMLHIPf8zo5KG6qLqbqToHQ== X-Google-Smtp-Source: AGHT+IHZ79GK1aXYnnWb9q7+P5nP9QYQp8e6sdlkbYXp1r4C5vMOT6bSo0SU5Rd+GH1MWjerbZ5/EA== X-Received: by 2002:a17:902:b702:b0:1d7:57d:2792 with SMTP id d2-20020a170902b70200b001d7057d2792mr4475806pls.103.1705937348244; Mon, 22 Jan 2024 07:29:08 -0800 (PST) Received: from localhost (34.85.168.34.bc.googleusercontent.com. [34.168.85.34]) by smtp.gmail.com with UTF8SMTPSA id u9-20020a170903124900b001d60a705628sm7285775plh.246.2024.01.22.07.29.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jan 2024 07:29:07 -0800 (PST) From: jeffxu@chromium.org To: akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, usama.anjum@collabora.com, rdunlap@infradead.org Cc: jeffxu@google.com, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, pedro.falcato@gmail.com, dave.hansen@intel.com, linux-hardening@vger.kernel.org, deraadt@openbsd.org, Jeff Xu Subject: [PATCH v7 0/4] Introduce mseal() Date: Mon, 22 Jan 2024 15:28:46 +0000 Message-ID: <20240122152905.2220849-1-jeffxu@chromium.org> X-Mailer: git-send-email 2.43.0.429.g432eaa2c6b-goog MIME-Version: 1.0 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: BF73540020 X-Stat-Signature: j7p9cogpkq3ifxxhcg7cjuzwjtodbf63 X-Rspam-User: X-HE-Tag: 1705937349-318249 X-HE-Meta: U2FsdGVkX1/eYf4bwWI23Kv3v1OBKxoroL/hTYzzZTsHE3pI/vITR9+IKfH8OnfoEI1Q+MgR4AKaDWnnstoHqr7PlrMdXYoZdqQxNzU0w4r0bEfP0w/Z3yhpmNVLVK3RZeyPeF47qq8xWaJxqaWKcnjP5LvsFb0qRBYO4td9JS6GCh6uXhvUaKjB9WdGzxOBNvGaWf0iDltAWxg5bIGWQLDaeeodXCNHzOuDw/o2EsAuQAld8Glf6ppabem3meFea9Do1eYWdVXYYXUnxTsYPsfFKJ5rlWuZXr/IqmEkii0FAmyj1Qo6yn+a05TUxb4x/OG2i4vvV7WfC5DjMcr+oPytXaO3pea+/L8gDXN6y6gNiIIcGRFNJyBFzE+jximeY95zlnjvViwOutonrIP6c6pSgsYeN4Go4BSYCPUlZTfFidjQzrvQPbQqCB+k47AdkPg2sqNVTJZrxsNzWnRMiAVXGdCrr69s92i/huOV61y0n/Qm/bU99i2+Pk5I2VocCpexTkDq4sM1KkyE6RAYk7476b5X8Q3hl6d4196W7Y0MAk8OfivnAPbnsgpWntiFJXASgz9sDF2c57N45Bu19c5vchEQfSJRj0cPFXe9l3a52QXxcRQX4nrgHi31NsiZ9+DhcMlPuif42SHLPnwZoj0PttiS1FkEy0rBEGG15+kJRoCa3ibBIKe3X8gSfRE5sZtvEqaKzpDkV2aRxqYJPYz7USRe+uecE75aaLI7GIzqKeNOLwONN+loZvfQvX+5/iLv+THlrHfQv5QMFGNemEiQxDT8qNOjHxAROLtgaGuc5dVLU9y/vkOSipauvfU5LVTMhe2zIfoQyvQBJxdRdBvO1AIdMznD78a/xIyHWKbrXpqeVtH0h769WZXq6VGdAzfHCmoQSgzfcmRvhHsSHFt10+HSzSgS4KikSuJrBDP9e+2zJhPSv4+tvqBMRPzvXGM42cqxUuEpYzqr70m Ac4TJZIj 9rQVLGlCWyU0afIILPWlih6ZcidZChrn238h5eKp5K1ADtxh+Pw+Z1t9qHCv2HDqme7AMrEdmUdCBbkPSIf126WiJRzB83W6IAnruY2R+120oNXaA72z9HeLePInNkYsUoKoDikRf+sd3Mvp+dTL3+YkZxrnC49Zg9Wp0HfJds2QXHegR2si5joB5GNloQRwWEhJpE+Ptx/HQGDS5sEeyPZJFQGIf+mRYiK5+vw8ELjCu66n9E5cc40opvCjxXVp5MnPa1oXjpbg1F9TiWA5CCJtk/uzYOad0GWqZ1LLAmqCGUlhnXK3hjpGIF04GH7w/RP5fX4w2tBqDWkHB/gcRi+yLfjlOcXAlnrtW7++ZC/Dn1sTS7aTAH00uN7btcmbkzMIICRJjEq/wJe9GcWokzVXUIHGXCJeyujCCXdvsqXpsYQqxmWumM3cLoXSP/qqst43WkfVsWF3OsXwE1JO82IxhnNJagb5ix7NibkmTh9KLWDmlv2OP+7v9wgHcb18DITEgvHiH06aDKsYOV04AsKQCijqElWPghRx8TIz6srhmsgrzlRSBx3EFLdD0XKcFLYoZspClIvfQqLemWX8EUjhYBULdvjT3TP2o07nNCbMS3OkO4tR7GIyI42wheDzP4LrHpJHFduvqivu4akSQqdIOPNUSkp+SJ4rFhrwB7RUb1SRnBYw7qhje8iA1CMi5Q/ySbb+4pljMkyCHJqAVZC0SYXK/sf4VENGy2olPsSvvuvSj/Z7T+8QtVA== 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: From: Jeff Xu This patchset proposes a new mseal() syscall for the Linux kernel. In a nutshell, mseal() protects the VMAs of a given virtual memory range against modifications, such as changes to their permission bits. Modern CPUs support memory permissions, such as the read/write (RW) and no-execute (NX) bits. Linux has supported NX since the release of kernel version 2.6.8 in August 2004 [1]. The memory permission feature improves the security stance on memory corruption bugs, as an attacker cannot simply write to arbitrary memory and point the code to it. The memory must be marked with the X bit, or else an exception will occur. Internally, the kernel maintains the memory permissions in a data structure called VMA (vm_area_struct). mseal() additionally protects the VMA itself against modifications of the selected seal type. Memory sealing 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. Memory sealing can automatically be applied by the runtime loader to seal .text and .rodata pages and applications can additionally seal security critical data at runtime. A similar feature already exists in the XNU kernel with the VM_FLAGS_PERMANENT [3] flag and on OpenBSD with the mimmutable syscall [4]. Also, Chrome wants to adopt this feature for their CFI work [2] and this patchset has been designed to be compatible with the Chrome use case. Two system calls are involved in sealing the map: mmap() and mseal(). The new mseal() is an syscall on 64 bit CPU, and with following signature: int mseal(void addr, size_t len, unsigned long flags) addr/len: memory range. flags: reserved. mseal() blocks following operations for the given memory range. 1> 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. 2> Moving or expanding a different VMA into the current location, via mremap(). 3> Modifying a VMA via mmap(MAP_FIXED). 4> 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. 5> mprotect() and pkey_mprotect(). 6> 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. In addition: mmap() has two related changes. The PROT_SEAL bit in prot field of mmap(). When present, it marks the map sealed since creation. The MAP_SEALABLE bit in the flags field of mmap(). When present, it marks the map as sealable. A map created without MAP_SEALABLE will not support sealing, i.e. mseal() will fail. Applications that don't care about sealing will expect their behavior unchanged. For those that need sealing support, opt-in by adding MAP_SEALABLE in mmap(). The idea that inspired this patch comes from Stephen Röttger’s work in V8 CFI [5]. Chrome browser in ChromeOS will be the first user of this API. Indeed, the Chrome browser has very specific requirements for sealing, which are distinct from those of most applications. For example, in the case of libc, sealing is only applied to read-only (RO) or read-execute (RX) memory segments (such as .text and .RELRO) to prevent them from becoming writable, the lifetime of those mappings are tied to the lifetime of the process. Chrome wants to seal two large address space reservations that are managed by different allocators. The memory is mapped RW- and RWX respectively but write access to it is restricted using pkeys (or in the future ARM permission overlay extensions). The lifetime of those mappings are not tied to the lifetime of the process, therefore, while the memory is sealed, the allocators still need to free or discard the unused memory. For example, with madvise(DONTNEED). However, always allowing madvise(DONTNEED) on this range poses a security risk. For example if a jump instruction crosses a page boundary and the second page gets discarded, it will overwrite the target bytes with zeros and change the control flow. Checking write-permission before the discard operation allows us to control when the operation is valid. In this case, the madvise will only succeed if the executing thread has PKEY write permissions and PKRU changes are protected in software by control-flow integrity. Although the initial version of this patch series is targeting the Chrome browser as its first user, it became evident during upstream discussions that we would also want to ensure that the patch set eventually is a complete solution for memory sealing and compatible with other use cases. The specific scenario currently in mind is glibc's use case of loading and sealing ELF executables. To this end, Stephen is working on a change to glibc to add sealing support to the dynamic linker, which will seal all non-writable segments at startup. Once this work is completed, all applications will be able to automatically benefit from these new protections. In closing, I would like to formally acknowledge the valuable contributions received during the RFC process, which were instrumental in shaping this patch: Jann Horn: raising awareness and providing valuable insights on the destructive madvise operations. Linus Torvalds: assisting in defining system call signature and scope. Pedro Falcato: suggesting sealing in the mmap(). Theo de Raadt: sharing the experiences and insights gained from implementing mimmutable() in OpenBSD. Change history: =============== V7: - fix index.rst (Randy Dunlap) - fix arm build (Randy Dunlap) - return EPERM for blocked operations (Theo de Raadt) V6: - Drop RFC from subject, Given Linus's general approval. - Adjust syscall number for mseal (main Jan.11/2024) - Code style fix (Matthew Wilcox) - selftest: use ksft macros (Muhammad Usama Anjum) - Document fix. (Randy Dunlap) https://lore.kernel.org/all/20240111234142.2944934-1-jeffxu@chromium.org/ V5: - fix build issue in mseal-Wire-up-mseal-syscall (Suggested by Linus Torvalds, and Greg KH) - updates on selftest. https://lore.kernel.org/lkml/20240109154547.1839886-1-jeffxu@chromium.org/#r V4: (Suggested by Linus Torvalds) - new signature: mseal(start,len,flags) - 32 bit is not supported. vm_seal is removed, use vm_flags instead. - single bit in vm_flags for sealed state. - CONFIG_MSEAL kernel config is removed. - single bit of PROT_SEAL in the "Prot" field of mmap(). Other changes: - update selftest (Suggested by Muhammad Usama Anjum) - update documentation. https://lore.kernel.org/all/20240104185138.169307-1-jeffxu@chromium.org/ V3: - Abandon per-syscall approach, (Suggested by Linus Torvalds). - Organize sealing types around their functionality, such as MM_SEAL_BASE, MM_SEAL_PROT_PKEY. - Extend the scope of sealing from calls originated in userspace to both kernel and userspace. (Suggested by Linus Torvalds) - Add seal type support in mmap(). (Suggested by Pedro Falcato) - Add a new sealing type: MM_SEAL_DISCARD_RO_ANON to prevent destructive operations of madvise. (Suggested by Jann Horn and Stephen Röttger) - Make sealed VMAs mergeable. (Suggested by Jann Horn) - Add MAP_SEALABLE to mmap() - Add documentation - mseal.rst https://lore.kernel.org/linux-mm/20231212231706.2680890-2-jeffxu@chromium.org/ v2: Use _BITUL to define MM_SEAL_XX type. Use unsigned long for seal type in sys_mseal() and other functions. Remove internal VM_SEAL_XX type and convert_user_seal_type(). Remove MM_ACTION_XX type. Remove caller_origin(ON_BEHALF_OF_XX) and replace with sealing bitmask. Add more comments in code. Add a detailed commit message. https://lore.kernel.org/lkml/20231017090815.1067790-1-jeffxu@chromium.org/ v1: https://lore.kernel.org/lkml/20231016143828.647848-1-jeffxu@chromium.org/ ---------------------------------------------------------------- [1] https://kernelnewbies.org/Linux_2_6_8 [2] https://v8.dev/blog/control-flow-integrity [3] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/osfmk/mach/vm_statistics.h#L274 [4] https://man.openbsd.org/mimmutable.2 [5] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=h.bvaojj9fu6hc [6] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.com/ [7] https://lore.kernel.org/lkml/20230515130553.2311248-1-jeffxu@chromium.org/ Jeff Xu (4): mseal: Wire up mseal syscall mseal: add mseal syscall selftest mm/mseal memory sealing mseal:add documentation Documentation/userspace-api/index.rst | 1 + Documentation/userspace-api/mseal.rst | 183 ++ arch/alpha/kernel/syscalls/syscall.tbl | 1 + arch/arm/tools/syscall.tbl | 1 + arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 2 + arch/m68k/kernel/syscalls/syscall.tbl | 1 + arch/microblaze/kernel/syscalls/syscall.tbl | 1 + arch/mips/kernel/syscalls/syscall_n32.tbl | 1 + arch/mips/kernel/syscalls/syscall_n64.tbl | 1 + arch/mips/kernel/syscalls/syscall_o32.tbl | 1 + arch/parisc/kernel/syscalls/syscall.tbl | 1 + arch/powerpc/kernel/syscalls/syscall.tbl | 1 + arch/s390/kernel/syscalls/syscall.tbl | 1 + arch/sh/kernel/syscalls/syscall.tbl | 1 + arch/sparc/kernel/syscalls/syscall.tbl | 1 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + arch/xtensa/kernel/syscalls/syscall.tbl | 1 + include/linux/mm.h | 48 + include/linux/syscalls.h | 1 + include/uapi/asm-generic/mman-common.h | 8 + include/uapi/asm-generic/unistd.h | 5 +- kernel/sys_ni.c | 1 + mm/Makefile | 4 + mm/madvise.c | 12 + mm/mmap.c | 27 + mm/mprotect.c | 10 + mm/mremap.c | 31 + mm/mseal.c | 343 ++++ tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + tools/testing/selftests/mm/mseal_test.c | 1997 +++++++++++++++++++ 33 files changed, 2690 insertions(+), 2 deletions(-) create mode 100644 Documentation/userspace-api/mseal.rst create mode 100644 mm/mseal.c create mode 100644 tools/testing/selftests/mm/mseal_test.c