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 76C74FC6182 for ; Fri, 13 Sep 2024 23:00:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE6E56B00A6; Fri, 13 Sep 2024 19:00:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B70916B00A9; Fri, 13 Sep 2024 19:00:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E9926B00AA; Fri, 13 Sep 2024 19:00:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7A4386B00A6 for ; Fri, 13 Sep 2024 19:00:06 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E032040F42 for ; Fri, 13 Sep 2024 23:00:05 +0000 (UTC) X-FDA: 82561234770.02.3F36415 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by imf19.hostedemail.com (Postfix) with ESMTP id 1B9DB1A0003 for ; Fri, 13 Sep 2024 23:00:03 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=TLN0GYtz; spf=pass (imf19.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.180 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=1726268297; 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=9uQnZG2FkiJVH/FNBSQsovL+XHO5tAw2cuV4O/cm3RU=; b=dW2jE7uNQCjE2n6l/gnAsu/fDScznOF93b0mV415NZmCpqvhC7Lw2H2zdATqQbRq73j17s mmSkkPClnHOZDOtok8Yu591M8YkjnIsOwIrlo/5KX4gbr9wCMEuEcfX7Kni2kQxS4RHuv2 lIVIv9mw5horVuzeBAiK+ngCNebaTik= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726268297; a=rsa-sha256; cv=none; b=nn4M9kTT5HMKO8qCGdiyVvNt8fHP0Anvzb41l4YeP88ZDwOkkYt3DLVrTyBO2fHYK8rfcx bpCoVOh1GnfR/Slzvifhv5/ItCC7cCgZEa417xUw68ia9VGA1n7FWtpcB6pzaqR51vNWdd Vci6cGzXyylcXkbA6BWMXXQeT33RTew= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=TLN0GYtz; spf=pass (imf19.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.180 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-oi1-f180.google.com with SMTP id 5614622812f47-3e047e96478so144301b6e.0 for ; Fri, 13 Sep 2024 16:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1726268403; x=1726873203; 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=9uQnZG2FkiJVH/FNBSQsovL+XHO5tAw2cuV4O/cm3RU=; b=TLN0GYtzMUJJcIDhVyJk0V5TZY8inMrQCvCCo59Q9ElZqEQG0p3f9BgiWVxPGhZ4bV YqxACZt8+Fbuf0r5l5mWbUf20KawQr5hitOZbfq0x2TZJEW8lLcGiuV9lV2kZRjRcs3n GPjfsRPh615bVz0ySZ4hXsrFjSFTMUHOUE4IM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726268403; x=1726873203; 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=9uQnZG2FkiJVH/FNBSQsovL+XHO5tAw2cuV4O/cm3RU=; b=wlcB2nfgSoBjaJVGO34PPyF4BNpJaL98rK8fUWtZAfNjnx2jBNb7ACXxvLT81iy9no fwVLMSiUnybKXNlOBiQUyTDAN2kjJjXT/dtl727WsPxlk9BDj3bYRB5+q08mLtEOdoLB pNpYYU1orKRl9fEuC4VlLZL/b7ZBwzpxMclhigCw7jwF5EtiV4pFoC9WMDdgLW4pDeVr QMb6g5Vh/WYpaOQr99szh/O5tINZkkLGs3Z87f5R8g5Vx0qlT/VzddYcg51em3dEwr/k b9V+ZH3VBgTsCQECTb6o5+Br5207nThCudtefyrrmSEwDl6QdyM3t5gfCJ3E/VC7tVO8 VtQQ== X-Forwarded-Encrypted: i=1; AJvYcCVy82ChLzVgTcpNYTNVg3bpQB604Bq90ar8pZNsx1IdgStRub094Ct59tZPQXMEi4pSeECOzmH7Yg==@kvack.org X-Gm-Message-State: AOJu0YxKbYcoXR/tA6zo7rwSo4NCzcUl6ySrWkruvPcfCRSIiTZcL/On TwkBwpRCQHDziT5EST8YZ4/mGGebrS7T9LdM102xcDObhUR3DObT4cJ84c32fNmWXjsMoWzR3Iu AAL8W8BuYc77h2TLWc9BmTd9ooqlN3W7fAohr X-Google-Smtp-Source: AGHT+IEVPZfFT+ibnTF4pI9UcZLzSJRCqjMlhaulJR9tiSRKbpWAKYYnC2TslOUpj0ICyRwwZy9DUCydGRjgpkjZ4vU= X-Received: by 2002:a05:6870:b616:b0:27b:58d8:c8de with SMTP id 586e51a60fabf-27c3f278400mr1550781fac.5.1726268402819; Fri, 13 Sep 2024 16:00:02 -0700 (PDT) MIME-Version: 1.0 References: <20240830180237.1220027-1-jeffxu@chromium.org> <20240830180237.1220027-5-jeffxu@chromium.org> <4944ce41-9fe1-4e22-8967-f6bd7eafae3f@lucifer.local> In-Reply-To: From: Jeff Xu Date: Fri, 13 Sep 2024 16:00:00 -0700 Message-ID: Subject: Re: [PATCH v3 4/5] selftests/mseal: add more tests for mmap To: Pedro Falcato Cc: Lorenzo Stoakes , akpm@linux-foundation.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, willy@infradead.org, broonie@kernel.org, vbabka@suse.cz, Liam.Howlett@oracle.com, rientjes@google.com, keescook@chromium.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: zuhoebiriha54trnh3zddizaxu4rkfer X-Rspamd-Queue-Id: 1B9DB1A0003 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1726268403-893435 X-HE-Meta: U2FsdGVkX1/oDvp5D4n3Mf/yL4MlwJRnK93IjfkcTdaEeJfnfG97NJBTw8afPFdxma6umx3KVQsSRmTv9Td5cI/Y64JNV/iphmZrk4q37nFFc1YX1h+clCi7a0l8nuIsNVxBEKqm4L8ObfwA3Az2Ohscdgto3nM4VJmiSFFNMwSEABk3DQ4S4cp1NnKSjxWtV/u306I5433ijy+PYsnOlLtDh9QUWmp+bEyDXVnnGjwoGkUC65Hcb+r2fJYM6LG+CxP7+AtILxv3GYtUMDEA2y/baE8WF8ot0PFseWSipqPlEBzoqKjkLvSoXQVbQWKQ2fMaNl67thPlgddjYKrdVokKMezAxtEKHLxRDiYgE775JXHWgrKvtbz0a5m0U6xdJ4JFrdrJAvfLbJhAC89DSJkf5FVcXqPjtjm9A285ytSgWO6EQZHYoVuTiyIYFJvar1cu+c2g9UdIQzlUzsKEWVk549xJe1KDcXh8J7+TcGVdBxPdyUA+pqsICwwx0qgoNa9AevaCY5DoHjIf/wSl8LxKySGsoaRWknoEFRHknYWQc9pVGuaM3U9TMElM/HL2YTSCYlmbvRPWzWNVCh1QAXoffKKEoSXVAu13EUTc5N9kIz05SmXlu8zwKAafNgc+fvM3X0yPmi94+6ss7FRSv3/scsfwtK4qgIcN9iEoSAd0HkfeNP1EtvSmepfFRdACtNz7bVs7/o4P/KHLEKq6drWF+tG0R4wuizbmysXXNb7c+XfELl2qPicC0nR6JpXGMXqyQ66XK+Owb23bg8aIlySkotE2qnQoFXQQR2MfvLWE91fGQMN6FlRqCz11YIXCdVjqTyt7GTCPJM8Xv8qTlpZd4RR0iYEkPgRSXzz/wmUJtuYuk8M09aEjmIzN7z1+/yCkNsSerErKuurNerZn36jjv0ft7/op6xUeZCTUbhO6ocdkPXHDfHAkkQILjZwTsUKNe4LtIUywF1puYZ7 gLWQ/k0S jMYc+dHmsdxpR+6OBCHCzAfWQyqR4A9cl0+7tCTg+VaVv+8NuxJASS6Xc8kdRIctvkfhIkdfuCvhCIOgU1k1nB1KOx4JhurjPcJzh3GnTxhI8MLXD/smzijECUfmGbBnOkSN0S2O1U0ERHPq3pC7pL990ubrev8O0fdFd88O0Fl6RZlAKDaVRSbPPe//rvWjF59upTC3F+lCVIKT0mi8RS4nkwZQX35bVipqxQOOcywNy0vUr0E4zNoyeSx32vqd6RCx+cqdnVTno87YXAmkaGeKER7FC291d4H5A2V3jQ5CnNFQ= 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 Pedro On Sun, Sep 8, 2024 at 2:56=E2=80=AFPM Pedro Falcato wrote: > > On Sun, Sep 8, 2024 at 10:35=E2=80=AFPM Pedro Falcato wrote: > > Hi, > > > > I agree with most of the points. Sitting down here to write unofficial > > guidelines for mseal behavior. > > > > mseal should seal regions and mark them immutable, which means their pr= otection > > and contents (ish?) (not _only_ backing mapping, but also contents in g= eneral > > (see madvise below)) should not be changed throughout the lifetime of t= he address space. > > > > For the general syscall interface, this means: > > 1) mprotect and munmap need to be blocked on mseal regions. > > 1a) munmap _cannot_ tolerate partial failure, per POSIX. > > 2b) mmap MAP_FIXED counts as an unmap operation and also needs to be b= locked and return -EPERM. > > > > 2) Most madvise calls are allowed, except for destructive operations on > > read-only anonymous _pages_ (MADV_DONTNEED is destructive for anon, but= we also don't care > > about blocking these ops if we can do it manually with e.g memset) > > 2a) The current implementation only blocks discard on anonymous _regio= ns_, which is slightly > > different. We probably do want to block these on MAP_PRIVATE file = mappings, as to block > > stuff like madvise MADV_DONTNEED on program rodata. > > 2b) We take into account pkeys when doing the permission checks. > > > > 3) mremap is not allowed as we'd change the "contents" of the old regio= n. > > 3a) Should mremap expansion be allowed? aka only block moving and shri= nking, but allow expansion. > > We already informally allow expansion if e.g mmapping after it + m= seal. > > > > 4) mlock and msync are allowed. > > > > 5) mseal is blocked. > > > > 6) Other miscellaneous syscalls (mbind, etc) that do not change content= s in any way, are allowed. > > 6a) This obviously means PTEs can change as long as the contents don't= . Swapping is also ok. > > > > 7) FOLL_FORCE (kernel-internal speak, more commonly seen as ptrace and = /proc/self/mem from userspace) > > should be disallowed (?) > > 7a) This currently does not happen, and seems like a large hole? But d= isallowing this > > would probably severely break ptrace if the ELF sealing plans come= to fruition. > > > > When we say "disallowed", we usually (apart from munmap) allow for part= ial failure. This > > means getting an -EPERM while part of the call succeeded, if we e.g mpr= otect a region consisting > > of [NORMAL VMA][SEALED VMA]. We do not want to test for this, because w= e do not want to paint ourselves > > into a corner - this is strictly "undefined behavior". The msealed regi= ons themselves > > will never be touched in such cases. (we do however want to test munmap= operation atomicity, but this is > > also kind of a munmap-related test, and might not really be something w= e really want in the mseal tests) > > > > Kernel-internal wise: The VMA and PTE modifications resulting from the = above operations are blocked. > > Sealed VMAs allow splitting and merging; there was contention about the= splitting issue, but it truly > > does not make sense to block operations unless they affect a VMA entire= ly, and that would also force > > VMA merging to be ABI ("vma_merge isn't merging these two regions and n= ow my madvise works/doesn't work :("). > > > > > > Do I have everything right? Am I missing anything? > > Small addendum: file write, truncate and hole punching might also > matter for sealed file-backed regions, as these change the region's > contents, but we probably > want to rely on file write permissions to protect against this (as we > already do). Any other solution is probably terrible and probably > endlessly NAK'd by fs folks, but it does > mean sealed regions aren't really immutable if you or the attacker can > write to the file. > Right. The mseal protects the control-data of VMA (e.g. prot), it doesn't do anything more than that. The file permission relies on dac/mac control. -Jeff > -- > Pedro