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 E1233ECE577 for ; Sun, 8 Sep 2024 21:57:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 259696B00E3; Sun, 8 Sep 2024 17:57:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 207666B00E4; Sun, 8 Sep 2024 17:57:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A8236B00E5; Sun, 8 Sep 2024 17:57:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E192B6B00E3 for ; Sun, 8 Sep 2024 17:56:59 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7F66B14070C for ; Sun, 8 Sep 2024 21:56:59 +0000 (UTC) X-FDA: 82542931758.21.CFDBFEE Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by imf04.hostedemail.com (Postfix) with ESMTP id BBFB640006 for ; Sun, 8 Sep 2024 21:56:57 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KLM79CIx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725832543; a=rsa-sha256; cv=none; b=Lk3IFeu2A0jjTHq6v7MQDbr6TrBZhIJj+7D8KIWC1f8SJk8ZfbQLW9r6xjPququtxF3izS tizq3cDJYvQeyW4wbtwc56Zq9dJ4OX4D3Z5UruEjgAp8ccyiiRdqZBnt0Q9/K8AA9tTGVA rolOMCTeFIYQk8alBIy+Yc+vZejTT3o= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KLM79CIx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.222.43 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=1725832543; 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=0bNi04gh8Ppwp4T2sUaifRCrgHKoKyytEnRJoKdjXyQ=; b=ldUm+V45O67euaIttxMl+JYVhfUMWuMMZ0M0wHwtEu1aCF+5HddfrAscSZddVf6kPqW7uG RsRZI6FiQK/btdmfL7kSrIMevuWdk5IxnhElQi8ovWXJjbgnCiA/2KG/yDIJjDldc4VNeI RzwwkRNMuacgRxhMS0dhny23MjeDD40= Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-846db33f4e5so941683241.1 for ; Sun, 08 Sep 2024 14:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725832616; x=1726437416; 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=0bNi04gh8Ppwp4T2sUaifRCrgHKoKyytEnRJoKdjXyQ=; b=KLM79CIxv6izDwp5lsSwd5Seb1wcaLFKmDmEkA3N/XIfA1XxFDLJ+eYJY0tw31aG7Y aXfylm5TfNFWWQkiwcZscLGpNN9Ph1EvyWTMOWHQ9Ygp3Id6QBnOFZkKY3gu0faqkP7x qYzj/mgBxknxfyiUTpC7kUmgMI5Nf69gEL5G9vTEnHYdhr1Nywj2W2rObFOX526hCdfa fQPeVdocCLUkuEajsbOnWgpQR2ZjT07+MtTDmHeJMHLBLvNiqhfdkqoczkbRByizsVB1 rXeUa8lJ/M5dej7kWyAfGjQ9pcK4xLG3Gd11U3iHyQJy93p9L5LAj9oi4Dlp/9YTmQVv lmBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725832616; x=1726437416; 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=0bNi04gh8Ppwp4T2sUaifRCrgHKoKyytEnRJoKdjXyQ=; b=tsm+/RWPLcW06sc8hJk7HVQKb5N3kMFN+iNG1dNwjMGtoyxw24Tcdm9ByLwRuCfSyR w3RAFmv7EpyDyx2LTYFe4vARgfGIP0X0CcwtGZ41uqUTBW/44zQnC3XYSwbK9UfkZ37W 66ykKEeJPe9bOWMQSi9GhVk/+KkNnqnsY4d+4Y1iSOpYhkpghyQTE3oRKfNGST5/xgw2 DPsTm/ZvOcYvW+Cr8zUio5tbIakM5yjsRIq43wuzev04agFQEddvZyI//2aRp+UKc6qD h11jTfCrHKlUKkR2t5L/ZBfG3hU89WBX3+4dz8tH4kfcqZO80bXvZfn7rUIL60q5U7ir QXvg== X-Forwarded-Encrypted: i=1; AJvYcCXBocP+cSGEL3rOIPD2HSm9liV50zfZ5YUmhErf1Byx4qnuCgGEiD9CGpbQXrqEvE8tdV1ia0Dzcg==@kvack.org X-Gm-Message-State: AOJu0YyTTmggbhsV/MyHD3CUgwGEWf/E4QBzb0nGU8SzTSSPay9nHoEm dudUhmT83j2lp9bCMVzP5KeDtn1e3WUmF91FFIjNWrekR77jwN5KXnjz90FEJAm3VcoFSFx8Lzo L/8fPBkXT7dJFIVEi82jiYp6trG4= X-Google-Smtp-Source: AGHT+IHTmy0HSSt2RALtUjPBDItygp6q4MMxq/Z1eCpdrWr07YwXnnknIoe/vKKp9he0xcv0LJ7Ip0FHDemI74/YJT8= X-Received: by 2002:a05:6102:cc8:b0:49b:d066:3e9e with SMTP id ada2fe7eead31-49bedbc1635mr3459267137.10.1725832616371; Sun, 08 Sep 2024 14:56:56 -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: Pedro Falcato Date: Sun, 8 Sep 2024 22:56:45 +0100 Message-ID: Subject: Re: [PATCH v3 4/5] selftests/mseal: add more tests for mmap To: Lorenzo Stoakes Cc: Jeff Xu , 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-Rspamd-Queue-Id: BBFB640006 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 3q9xbqi7fkdnfkwoni6b3qmdpugibqds X-HE-Tag: 1725832617-271681 X-HE-Meta: U2FsdGVkX19rMVNBEJjr1TtVf3H9HENqSKkoZbk8kdKAJlyIEwtqK2r3K+SHfPR5kNo4+LGL6UZE1RCsK92a02ItnUqoX4JgBoarNWhPF/ydgl8ut6/5Vt8DdditXKcm43cWHuaX1IKnKYNN7+Kzs7h5tsARdn8MYgBmsIEE6Kz5KfwoWh5MOY7UjCY+Wf8D7N0VUi7pZGIOxATX8CW4Jm5jUIxobYXIxG/knslI6jN5daLcPzAIP1i1tvMmkV989ZPRV61tS4bTz3U52y4tTeKs8jHDGDFYr9ZIgSaH+CWLgqQrBlfvGYrUxDFtX2bK+T/KTU1AnIQLgq0sfIMZixpI+/oA/o1hKOiamkLpcdyWdQilOmWXecdMTMlXIZOMSe6sWjFXVDC5OML8wiUtRqGc+gz66WQklWu+IS0XjFvx42NCsoXorXTDuO7ZCNwBprmNzVVjZJewipEFt+B9fpjBkhwUFFQm3t+/Ap64vg0G9q7d4/bKf+iJXB3G+RRVd5JgZp0YjzgZk7OU+g7l2lU3C316wI3nBo3WrhdB1VGKob6H5VhHKzkp/1P4ONG8+sKVqXzE+LAh4LCbm1oHInm6BMhwCCjwUoGS0V8Z9ufBVwsRWAly3NpZllEf707LWBhipsasizb9ToUiRQm4p7lcMLMJeiuH/0Lj26oezQ77U5zos+n/crrXf5JOL5k1NzVTgitDXc9kSnFRDGcGfH0K8tvVY8SCDgksPH1vLxWZXr9xoNgxnWjs0YeNYbJNRfaiGqr/WpyBlf0gX0RM1gu3VrJuFDsBiXsjEWO9IzkBOau6FEtvMq+hvsc6DQ3ugh3fHNZv62vvCdR/OtgA9/wOvX3zwE0995Wv73x6eUgiMn4WHkv6fW1rp/mxK9aBs0AdJGnbI4DaILqwCArQFxpcTfKfekeXmdCwoML3bOV9xiWa/1LeJz//9ROZqb/IHmkKJoLVyT0ZI6PcUVk QYpclbnt NcBDy62CgpGVfzLo7W1t4Z6t8ntM9Iu9wYGek7Ixh/8gIN9oWpJWip1XoDuiBBzT0wKZipT4205rPrCoQMf89lwZ8DUiPul+IWHD2ARzfdMtdhcDkubQB6F95iOx4t17P6d4YvsWPV9arjRwSf8aFVetq/qT4XVqe54ZRxdnj3GWZsoM8PuOs4Tf6ebBreTTqKpRSuCvTTnfayXtrGISOT8WPP2wYVnFPsh4xUL35pBGV7baun+/3YkGtPF6NMUp5f+9LdNHc+5wqaAp+VyFhfuNkwHsBDfOow3/65YXfzXK7ZGLFBbatuPJCOZlC8RPhOWcFGB40PGBUcdh8OpqTIYjtOAKId3NbSXxM9QmHAa8e8QyWALKp49kx4A== 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 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 prot= ection > and contents (ish?) (not _only_ backing mapping, but also contents in gen= eral > (see madvise below)) should not be changed throughout the lifetime of the= 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 blo= cked 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 w= e 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 _regions= _, which is slightly > different. We probably do want to block these on MAP_PRIVATE file ma= ppings, 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 region. > 3a) Should mremap expansion be allowed? aka only block moving and shrink= ing, but allow expansion. > We already informally allow expansion if e.g mmapping after it + mse= al. > > 4) mlock and msync are allowed. > > 5) mseal is blocked. > > 6) Other miscellaneous syscalls (mbind, etc) that do not change contents = 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 /p= roc/self/mem from userspace) > should be disallowed (?) > 7a) This currently does not happen, and seems like a large hole? But dis= allowing this > would probably severely break ptrace if the ELF sealing plans come t= o fruition. > > When we say "disallowed", we usually (apart from munmap) allow for partia= l failure. This > means getting an -EPERM while part of the call succeeded, if we e.g mprot= ect a region consisting > of [NORMAL VMA][SEALED VMA]. We do not want to test for this, because we = do not want to paint ourselves > into a corner - this is strictly "undefined behavior". The msealed region= s themselves > will never be touched in such cases. (we do however want to test munmap o= peration atomicity, but this is > also kind of a munmap-related test, and might not really be something we = really want in the mseal tests) > > Kernel-internal wise: The VMA and PTE modifications resulting from the ab= ove operations are blocked. > Sealed VMAs allow splitting and merging; there was contention about the s= plitting issue, but it truly > does not make sense to block operations unless they affect a VMA entirely= , and that would also force > VMA merging to be ABI ("vma_merge isn't merging these two regions and now= 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. --=20 Pedro