From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 81E2C425866; Thu, 16 Jul 2026 13:43:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784209423; cv=none; b=rwOprZ8kVPinWLY5PbBYyaxARSY9eTj9Kuc923wUnezdE0KuCanBGq/Lu+b/Mn6iXwg0AVq6lpMqXRjq6uFAgeM4DHXYeFepXvD+oe28l9wfH3AMiztsz7QWkbh2fcOhWBvwHcUrteAyBLmoFbZeG/wgO2iqvDTwMSuiIBsEjbg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784209423; c=relaxed/simple; bh=3XEOElWo0Iax9roa0jK1sDNI5MbeHwqjApf5pqY6yz0=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=icjQPmraUAfBA0GqSluvODW3WA8gnwgjvDyHZ40i2N3qpOJsDDS9kIuJF0q8pIPTuE76yaex8wTDmuJairbb5P1dFHpj70ZNujMs2k3NKvPCX7hE+mIAYJ54+U18Lq5Cv3Nghc6pWxiqVjAnFoQP9sUZ2xUseu74tGLRpNd/i+4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ddRFPeB/; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ddRFPeB/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D11B41F00A3A; Thu, 16 Jul 2026 13:43:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784209418; bh=oWUsUTsHTYC4oF1+U1zCOlOpJa+o/HcjMqULEm1jNKI=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=ddRFPeB/dy4N9t+1VV61tUOy6RSwcG9ODLZw+J8v/DsHFuvLSCm+SEyltiVJaOJNq zfJEikRpZms7kR5FsxnW/wY68XiDM/HWCi7PgE+3mtkbuQC7zlsu+x9UM1MxQo71pB L7i5hBbUGDOVT7oE57f976DdElPde+afbcy8vQ5PFOO+I32bG9ryUvKL4s1FGTIiKn tI2Phf7XpCYEruV/Pcz11uYKUlbxmiCmMo9YcJdQwQ8bbrjgLRkkB+5hVvrV9f0xot zjF/I+b9w6nqb3R9uLXQHPiwG9dOe6iwPzAHQxhwLMWUlVAwdKTyXNhRj3DgrjEkUU VW1D68HV5+d+g== From: "Lorenzo Stoakes (ARM)" Date: Thu, 16 Jul 2026 14:43:11 +0100 Subject: [PATCH 3/3] mm/mseal: remove further superfluous comments, do_mseal() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260716-mseal-fixups-v1-3-3a9609bf041b@kernel.org> References: <20260716-mseal-fixups-v1-0-3a9609bf041b@kernel.org> In-Reply-To: <20260716-mseal-fixups-v1-0-3a9609bf041b@kernel.org> To: Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Jann Horn , Pedro Falcato , Alexander Viro , Christian Brauner , Jan Kara , Kees Cook , David Hildenbrand , Mike Rapoport , Suren Baghdasaryan , Michal Hocko Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Lorenzo Stoakes (ARM)" X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=4242; i=ljs@kernel.org; h=from:subject:message-id; bh=3XEOElWo0Iax9roa0jK1sDNI5MbeHwqjApf5pqY6yz0=; b=owGbwMvMwCV2fu7ZrsZH9SKMp9WSGLIi7n+adExAyarM7UFw98yGhv+zX/n8V1ryQedU13Xv7 fJWT64WdZSyMIhxMciKKbI8/yK+P0gkbF7nBX83mDmsTCBDGLg4BWAiU8UYGTZdV2ExVnl8xdrM TzDynwdjRGP87vUdSg/3zqvgrD3C7cXwP/rh4aR5i1REq12Cd/AFBBhurriRJ3MixZtjhbT/4XU JnAA= X-Developer-Key: i=ljs@kernel.org; a=openpgp; fpr=E7F417BF5214569E89D04F46CF9DCD8A81E27F14 There's no need to abstract do_mseal() any longer so put the system call implementation in the system call declaration. The comment around do_mseal() is strangely formatted, overly long and adds a lot of superfluous information that the code already provides, so boil it down to the essentials. Signed-off-by: Lorenzo Stoakes (ARM) --- mm/mseal.c | 74 ++++++++++++++------------------------------------------------ 1 file changed, 16 insertions(+), 58 deletions(-) diff --git a/mm/mseal.c b/mm/mseal.c index 5930551d84f2..d01ab35d3f0f 100644 --- a/mm/mseal.c +++ b/mm/mseal.c @@ -99,60 +99,24 @@ void mseal_mmap_page_zero(void) } /* - * mseal(2) seals the VM's meta data from - * selected syscalls. + * Seal VMAs in the specified input range to prevent an attacker replacing what + * is mapped in the range with something else. * - * addr/len: VM address range. + * Disallows: + * - VMA unmapping, remapping or shrinking. + * - Overwriting the VMA with another one via mmap(), mremap() or similar. + * - Alteration of properties via mprotect()/pkey_mprotect(). + * - Destructive madvise() behaviours (like MADV_DONTNEED) on anonymous read-only + * ranges. * - * The address range by addr/len must meet: - * start (addr) must be in a valid VMA. - * end (addr + len) must be in a valid VMA. - * no gap (unallocated memory) between start and end. - * start (addr) must be page aligned. + * Since unmapped ranges can be mapped at any time, the input range must span + * mapped ranges only. * - * len: len will be page aligned implicitly. - * - * Below VMA operations are blocked after sealing. - * 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() behavior (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. - * - * flags: reserved. - * - * return values: - * zero: success. - * -EINVAL: - * invalid input flags. - * start address is not page aligned. - * Address range (start + len) overflow. - * -ENOMEM: - * addr is not a valid address (not allocated). - * end (start + len) is not a valid address. - * a gap (unallocated memory) between start and end. - * -EPERM: - * - In 32 bit architecture, sealing is not supported. - * Note: - * user can call mseal(2) multiple times, adding a seal on an - * already sealed memory is a no-action (no error). - * - * unseal() is not supported. + * The flags parameter is currently reserved. */ -static int do_mseal(unsigned long start, size_t len_in, unsigned long flags) +SYSCALL_DEFINE3(mseal, unsigned long, start, size_t, len, unsigned long, flags) { - size_t len; + size_t len_aligned; unsigned long end; /* Verify flags not set. */ @@ -163,12 +127,12 @@ static int do_mseal(unsigned long start, size_t len_in, unsigned long flags) if (!PAGE_ALIGNED(start)) return -EINVAL; - len = PAGE_ALIGN(len_in); + len_aligned = PAGE_ALIGN(len); /* Check to see whether len was rounded up from small -ve to zero. */ - if (len_in && !len) + if (len && !len_aligned) return -EINVAL; - end = start + len; + end = start + len_aligned; if (end < start) return -EINVAL; @@ -177,9 +141,3 @@ static int do_mseal(unsigned long start, size_t len_in, unsigned long flags) return mseal(start, end); } - -SYSCALL_DEFINE3(mseal, unsigned long, start, size_t, len, unsigned long, - flags) -{ - return do_mseal(start, len, flags); -} -- 2.55.0