From patchwork Tue Dec 12 23:16:58 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Xu X-Patchwork-Id: 13490087 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 45444C4332F for ; Tue, 12 Dec 2023 23:17:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4300B6B03D7; Tue, 12 Dec 2023 18:17:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B6466B03D8; Tue, 12 Dec 2023 18:17:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E1EC6B03D9; Tue, 12 Dec 2023 18:17:18 -0500 (EST) 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 016B16B03D7 for ; Tue, 12 Dec 2023 18:17:17 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C2E30A20C4 for ; Tue, 12 Dec 2023 23:17:17 +0000 (UTC) X-FDA: 81559729314.21.1F64BE5 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) by imf13.hostedemail.com (Postfix) with ESMTP id CADDD20008 for ; Tue, 12 Dec 2023 23:17:15 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=cnHKu0bq; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.53 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=1702423035; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1D1PlLUfxR4CYnPMS2OzloWMrMloIYQmh/cjfDWMVaY=; b=ILR/I/tvDaCsGi3t0yR7faJGz6CxlUeWtHnoIoMxWnn/3P2m09BwFBy5dL8D9Z0Ppq0zpO tZGgi6msU8OrvLKcBIDnhy+TPMXhfwx/t/sF/PWSIL8vK9JZAu5DJ6zjCl2GrvT4LmeLKk i0RYvNdKr0cnhMWzLeh+7dazEd/Qb3A= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=cnHKu0bq; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.53 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702423035; a=rsa-sha256; cv=none; b=lrCxzGcBgqvI5yyes+S9pkJdlYlWrfh9I4W/rEi1nM5Bd8LYLBRG2zeGWSOATQhUATzvCx AY+SHvAlcns9oYFC3NYl0CuLOnQpqfZxNp1m5qH+ms4ulk1lhqxJ3+aYFKo4Z+fWRjdl+B UfseCktuyReWVxboslA95BK0nZ2POX0= Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-6d9f879f784so3384918a34.2 for ; Tue, 12 Dec 2023 15:17:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1702423035; x=1703027835; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1D1PlLUfxR4CYnPMS2OzloWMrMloIYQmh/cjfDWMVaY=; b=cnHKu0bqn6lauYvZ2oTekCqXWXqA2dQE3FfAJMdUbG6GDx8WlwyJsGl7/Nr7zUTjIp C2o4RhWeqtNp+lIxhYbZmz00hnKbj7+YndVuLPkpeMiBObEbtd7aJB2tbdp59Rt/eahk NDLXASY4vs0NMv58SDtFD9BT8/ytU4DnKnqsY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702423035; x=1703027835; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1D1PlLUfxR4CYnPMS2OzloWMrMloIYQmh/cjfDWMVaY=; b=txoN2ANvkzDYrDsDRqobYfVFZ+IOM0e0K3blKwcssVEw4plTMFfXXv6bMZ392zoCBr wrB4T6cbNeVZFIx1rTYnepuustR0Y2tubz445zQpptDiTZmyobrPXntyqlFPA7TrcnIA T82FUcAb38rhcww22B3OQxGVPDO4jwq1H6oGvrWa2IEeX8veseRpF2u8dqJSfp8ioMsb gTBfADG+3NMvNGKtVxJTsse30Qqi7n8GW+5kfbkenYvYKpL7MV7QcgFo8FPwcW7n3m5F NtHoRWW4tu23ukxajYWA3bHcPB4WLVKbJjPrBMjyJyYtTM6GpohWi4wEWMjBQu9+wTCK piGg== X-Gm-Message-State: AOJu0YygPAIUgjdvknn0swkF5ryuvgfg8We7TM0yHUfWftL3vdNcxo5K SEpgZ6peXDJQKHAbhterTWsnpA== X-Google-Smtp-Source: AGHT+IELl9vxFDBtqlLqQjHJMgXEg7iTyGXK7EqaCyV/trQ5sRcstZZrUugD0WkeVeiGw0jvX4mjLw== X-Received: by 2002:a05:6358:262a:b0:16e:2898:5e02 with SMTP id l42-20020a056358262a00b0016e28985e02mr9003519rwc.32.1702423034702; Tue, 12 Dec 2023 15:17:14 -0800 (PST) Received: from localhost (34.133.83.34.bc.googleusercontent.com. [34.83.133.34]) by smtp.gmail.com with UTF8SMTPSA id s188-20020a635ec5000000b005c6617b52e6sm8763314pgb.5.2023.12.12.15.17.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Dec 2023 15:17:14 -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 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: [RFC PATCH v3 04/11] mseal: add MM_SEAL_BASE Date: Tue, 12 Dec 2023 23:16:58 +0000 Message-ID: <20231212231706.2680890-5-jeffxu@chromium.org> X-Mailer: git-send-email 2.43.0.472.g3155946c3a-goog In-Reply-To: <20231212231706.2680890-1-jeffxu@chromium.org> References: <20231212231706.2680890-1-jeffxu@chromium.org> MIME-Version: 1.0 X-Rspam-User: X-Stat-Signature: mr9s8gtbfa7qzq5m5cirxrzngrmfqp13 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: CADDD20008 X-HE-Tag: 1702423035-233776 X-HE-Meta: U2FsdGVkX19O6ufIvsVIlt2VaOwRTfmp9nKibtBrPjixgcc2OEHPcz2YKWSc9TUO64Uzj4fgy0H8gv7/xp0g4Q7WVfQ9AY+gxKbCUyP4mqDG7KniXUE6/E8khZu7N9ycwq+ROT0GqGkCGJ1P6XA4DtM88KSbh7NtyS2/PfxnIFhbzeumzyOoUzjG3w5fX+nQuq/izLNuT9tW9HS2sOomeoc24+H2jaAkr5f4txzYx2yX1mrsCQCoNwNgA8U6VHIxGjue9Prs9CfDFHJ+36bGgvfyXwRc4oynn1X+kwjMLskcGRlryK6yIm0FP4PlSd0QeSGAfQOQJHzbknU75/iMkjMYxA2BAiwO5+BV6K4vfqbdzKOzM6oKHVSIwOmpIdXA8+kxNlt0bN85ELVJxOx6VvQBRFKoYmfjMZDTu96hO/pSSwqwVGIeN/KzOWN6OhJBKSdloZxP9c4RBgjZA8tWvxjXQhPUl5M67axiCDyrPO+r7dq30/ZNKoZOKSQ5pwEk7GDbHwXOBoq9sljUakSuZJ5DBx9C2l0dF5uYnilBTx1Ve31vLg3xLlmFVfgrHuU7nHZMUVXE9ngsMoEQM/J2PR9w92H/Q4WXzP8CeWCS1zQSRGTl3LgtescHQUqIqeTsb7xQV/woJQpw2CfjS33XciApLXJzECXBkcwzsCbskObmKVXyJWb/6eidsBgqt38Vw8ipvVVoY9ptxF94k4D8UBCW1ptunhoKJeBhzZmxX3sJyFiXAzkMqQhBW4SOrhQxT71W0WTVtAbdMGhGc/aRXCRCqKBCjP+/EIbsDuA65rUVK6qaBeJrt16WPhKDZULgkJPRvxb5Swtx0oZHBZPqH5v3vdJva/GhhwQcT64phG516vVpxQ/GScDGl0+qQGGIwGhSkNgFZ1LPim6vYYBe5eemTFrWF1Le9PFNhYIHf3KNqB79u0j/sMs92bzUQRCPEsKoqc+eEMSa6/AaM89 TSeDDnsc f6XiYK9OOy8+bDhfkSvgN8rtD5xZPGI4B3ZT8SIIiLG1eOhGmB29RR54G+0tXj+KYP5uZYxR/zwbJ+cf4canGTrtC8k00cisODZFlieXu3sxfIseWXuRXTwIymNpkO5vRLGu5O34j9A7TU+VvDY4IpGxl3htM+KYAEHti/soeAGKwo7n+HWj27IrMkGShG9Ppm9Auhm42679OqK9pWfIOgZ3FbcXKQb2uoHJRWISkqFKjY+hKIeMcB7Ip7BYOHc3WIJ86eCsjr/RyFW2FZqoS0B3S2EuWWsVE6VxgNx+LS9QghlMcbGWEOURUI8/yOabYq6RMOm4+Gn/2YHlcnMhXSSk4a3PTA5v1J0PPFi/9N7iBegY6qgl/IlGom+GAxC+lC2FfUMl/WjXHjJ84z6Fi7ma3KrpM7ewBg4RDTfEdvA23lY36R/k0Xy5XbE4f1tO4veC0115HmcD4VP3eHLZQYpvxF5biGcN3OJXr 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 The base package includes the features common to all VMA sealing types. It prevents sealed VMAs from: 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> Move or expand a different vma into the current location, via mremap(). 3> Modifying sealed 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. We consider the MM_SEAL_BASE feature, on which other sealing features will depend. For instance, it probably does not make sense to seal PROT_PKEY without sealing the BASE, and the kernel will implicitly add SEAL_BASE for SEAL_PROT_PKEY. (If the application wants to relax this in future, we could use the flags field in mseal() to overwrite this the behavior of implicitly adding SEAL_BASE.) Signed-off-by: Jeff Xu --- mm/mmap.c | 23 +++++++++++++++++++++++ mm/mremap.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 65 insertions(+) diff --git a/mm/mmap.c b/mm/mmap.c index 42462c2a0c35..dbc557bd460c 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1259,6 +1259,13 @@ unsigned long do_mmap(struct file *file, unsigned long addr, return -EEXIST; } + /* + * Check if the address range is sealed for do_mmap(). + * can_modify_mm assumes we have acquired the lock on MM. + */ + if (!can_modify_mm(mm, addr, addr + len, MM_SEAL_BASE)) + return -EACCES; + if (prot == PROT_EXEC) { pkey = execute_only_pkey(mm); if (pkey < 0) @@ -2632,6 +2639,14 @@ int do_vmi_munmap(struct vma_iterator *vmi, struct mm_struct *mm, if (end == start) return -EINVAL; + /* + * Check if memory is sealed before arch_unmap. + * Prevent unmapping a sealed VMA. + * can_modify_mm assumes we have acquired the lock on MM. + */ + if (!can_modify_mm(mm, start, end, MM_SEAL_BASE)) + return -EACCES; + /* arch_unmap() might do unmaps itself. */ arch_unmap(mm, start, end); @@ -3053,6 +3068,14 @@ int do_vma_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma, { struct mm_struct *mm = vma->vm_mm; + /* + * Check if memory is sealed before arch_unmap. + * Prevent unmapping a sealed VMA. + * can_modify_mm assumes we have acquired the lock on MM. + */ + if (!can_modify_mm(mm, start, end, MM_SEAL_BASE)) + return -EACCES; + arch_unmap(mm, start, end); return do_vmi_align_munmap(vmi, vma, mm, start, end, uf, unlock); } diff --git a/mm/mremap.c b/mm/mremap.c index 382e81c33fc4..ff7429bfbbe1 100644 --- a/mm/mremap.c +++ b/mm/mremap.c @@ -835,7 +835,35 @@ static unsigned long mremap_to(unsigned long addr, unsigned long old_len, if ((mm->map_count + 2) >= sysctl_max_map_count - 3) return -ENOMEM; + /* + * In mremap_to() which moves a VMA to another address. + * Check if src address is sealed, if so, reject. + * In other words, prevent a sealed VMA being moved to + * another address. + * + * Place can_modify_mm here because mremap_to() + * does its own checking for address range, and we only + * check the sealing after passing those checks. + * can_modify_mm assumes we have acquired the lock on MM. + */ + if (!can_modify_mm(mm, addr, addr + old_len, MM_SEAL_BASE)) + return -EACCES; + if (flags & MREMAP_FIXED) { + /* + * In mremap_to() which moves a VMA to another address. + * Check if dst address is sealed, if so, reject. + * In other words, prevent moving a vma to a sealed VMA. + * + * Place can_modify_mm here because mremap_to() does its + * own checking for address, and we only check the sealing + * after passing those checks. + * can_modify_mm assumes we have acquired the lock on MM. + */ + if (!can_modify_mm(mm, new_addr, new_addr + new_len, + MM_SEAL_BASE)) + return -EACCES; + ret = do_munmap(mm, new_addr, new_len, uf_unmap_early); if (ret) goto out; @@ -994,6 +1022,20 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len, goto out; } + /* + * This is shrink/expand case (not mremap_to()) + * Check if src address is sealed, if so, reject. + * In other words, prevent shrinking or expanding a sealed VMA. + * + * Place can_modify_mm here so we can keep the logic related to + * shrink/expand together. Perhaps we can extract below to be its + * own function in future. + */ + if (!can_modify_mm(mm, addr, addr + old_len, MM_SEAL_BASE)) { + ret = -EACCES; + goto out; + } + /* * Always allow a shrinking remap: that just unmaps * the unnecessary pages..