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 D9D76CDB47E for ; Wed, 18 Oct 2023 07:01:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C4398D013A; Wed, 18 Oct 2023 03:01:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 473928D0016; Wed, 18 Oct 2023 03:01:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33AC18D013A; Wed, 18 Oct 2023 03:01:53 -0400 (EDT) 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 243998D0016 for ; Wed, 18 Oct 2023 03:01:53 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EC780B66AC for ; Wed, 18 Oct 2023 07:01:52 +0000 (UTC) X-FDA: 81357687264.03.C3D62A1 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf25.hostedemail.com (Postfix) with ESMTP id 2273BA0027 for ; Wed, 18 Oct 2023 07:01:50 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=vCbWHii0; spf=pass (imf25.hostedemail.com: domain of jeffxu@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697612511; 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=LQMWdsjrcNxGemB+Ki+j+OmjDR6Ap/DLLOnXpTvSXXU=; b=0RjIfG4XlQEFTddFjgS4QbQwWRhhKlPoqHJp5Rg/HTR9c4QwK/8gpWVu+4QmY6gJkwfynO kLy6PEGMjm00thZWmpN/d9hB9BkZIzKesjDtj3uXzsfYGIolisCz8a/YqPRbQGJEo53Agc Hj9rRjIDnL0LpKbr0wqWoBozQElzswk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697612511; a=rsa-sha256; cv=none; b=6So53oWtQEgC5ab5HtLfGGORovnU5HYZrhnhb+fxWCyZNvexgy3TTx0ue9I6yozNo+YeVu dIayJAkPPsH8Fe7Ea8QIlr2nZA65B9Gg/ZDH55TtdJLGMhvNXmp8u6D5/VFQpAEFPvQRWT 7UrB/4pJG5/DtcdaM9hC3H//+UcmEUU= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=vCbWHii0; spf=pass (imf25.hostedemail.com: domain of jeffxu@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-41b813f0a29so142851cf.0 for ; Wed, 18 Oct 2023 00:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697612510; x=1698217310; 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=LQMWdsjrcNxGemB+Ki+j+OmjDR6Ap/DLLOnXpTvSXXU=; b=vCbWHii0fheG7YeU8kYDXLoJqnZR4HO4q6o2REwumX+5yl9CMLrkF3nav60ONJ0XWG N0sXZlRzvKF4DivpssEe6ilQrWh4IyqXnkNS8jkIPnQQLEcM8VmRVL46knllu1DSoEGS FZjscKGPkXEN9ORJZwh74CuoomszJpK0rYJTjYuLk9fdOZa6ezvVGOCodeTdUg5/BLNq NjnPrLsB4Nm8jb+On2xbxyloGuBtc3EuzYKZncyyJYVvCUs3wdhF4KXJUWCLInBiA54+ UFfFAb7LVklrGQMH6djJOlw8QAnK0gY+tyh9xSC232fSrGtPX2gAbUQddmfrBUNCl1Wi 7yJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697612510; x=1698217310; 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=LQMWdsjrcNxGemB+Ki+j+OmjDR6Ap/DLLOnXpTvSXXU=; b=JVPC3Ho6L1K/y9HWVC4yWnCNZ3EW918iYr4F6E2GOWznLsueoZYJKaM/JtLZEnTxi/ 1xEfsu70nrusx7bWbVuEF3LAYLYnVfv4Wajel/Zviv4lhz8cu94F7vogRPFKHbSOZ/AF 8OWcNjqqtfVJHmiwQbV9zAv5MEccr3icMPD9RLtRuAs96gedaLcGrRcHbZamalWfaCwk ndj4LPA2ArBNXoA0Xe2Dp4ZYhkZFuhcxLZKbF69FlbZf6jGi56ycgDEETdb9G4/ljakD bqajv4hVOVrhQGxU6UQkmYqayP9b6l+kBtULkwV6KWineajKdeNZksDiFuBdu4arhwiM HzPg== X-Gm-Message-State: AOJu0Yy0nIjy522cieKJjdSsWcCFGSBtgr7BgI+PBFq3ZOt77E3q/YE6 z3gvYX0T1vr6zO5vOEySG2nZaoHCs9NlcopdnYuUBg== X-Google-Smtp-Source: AGHT+IHQyYOLE+Z9gTa+AYX+0rUotOh258UwOYKTEH95jYD/ocMbUJZKoG7x1mSLfzj+pDUtHplvY6ztBQyrR0NiBRo= X-Received: by 2002:a05:622a:a047:b0:41b:ef8f:dcbc with SMTP id ju7-20020a05622aa04700b0041bef8fdcbcmr234597qtb.0.1697612509813; Wed, 18 Oct 2023 00:01:49 -0700 (PDT) MIME-Version: 1.0 References: <20231017090815.1067790-1-jeffxu@chromium.org> <20231017090815.1067790-8-jeffxu@chromium.org> In-Reply-To: From: Jeff Xu Date: Wed, 18 Oct 2023 00:01:13 -0700 Message-ID: Subject: Re: [RFC PATCH v2 7/8] mseal:Check seal flag for mmap(2) To: Linus Torvalds Cc: jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, surenb@google.com, alex.sierra@amd.com, apopple@nvidia.com, aneesh.kumar@linux.ibm.com, axelrasmussen@google.com, ben@decadent.org.uk, catalin.marinas@arm.com, david@redhat.com, dwmw@amazon.co.uk, ying.huang@intel.com, hughd@google.com, joey.gouly@arm.com, corbet@lwn.net, wangkefeng.wang@huawei.com, Liam.Howlett@oracle.com, lstoakes@gmail.com, mawupeng1@huawei.com, linmiaohe@huawei.com, namit@vmware.com, peterx@redhat.com, peterz@infradead.org, ryan.roberts@arm.com, shr@devkernel.io, vbabka@suse.cz, xiujianfeng@huawei.com, yu.ma@intel.com, zhangpeng362@huawei.com, dave.hansen@intel.com, luto@kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2273BA0027 X-Rspam-User: X-Stat-Signature: o5eczxhjn1t8ja5rmn3153o7yop1m6yn X-Rspamd-Server: rspam03 X-HE-Tag: 1697612510-298315 X-HE-Meta: U2FsdGVkX191muMt/18e7/9BWEWN1exZ1EJHHQwrjaOKvynxZ+rlbVZNfCD4jMKrVwpmtg/hXZf0kZ/lEeR2GFj+GOEKR9xDWTuCVaix2rZd3fPdANbnNntLPXSqxcrDPHWSENzVE0ogGs9IYlxC/HALgCoNhljtelyDb2eFdgWrG2M9E+rxiCk5UArSx0XagxTqBfuieboRoIjFt7wXFOy9J1s58I6vz0KzYUcSvM3hU1up/jFrg7pWMo+r5j4+ct+f8iTU6QrWjnB/8nfXC+LEFs+mnHi/DZhntCpG7RFApDVXtjEWMyG5HtU7G7FJmCl5YoY7V7gmdnWSZUeZKH7HOpmhjg9WrgrAWeT/4TK782e/hCTmSmm3piGBPlBv5nvEHZXqEkvSM1Mn2LfvXjWn+G+xZvI1hX6v9qVysmaH7TTUz4arONrDq3tBe813LTIiu2dhPLKsZmJGQx2a8Q9P7e5k+Pcd0OVI3BFMtq/EQE+5dKc27rSqkiPjvovLY4YfuRRiASVC9K+IegbAA1Iq9cLqytaMqopbYxuJRAOtKry+LbDldXIwp6yzXML+TJHDxYhtVwz6w2F8HiMLgpG22WB24JXyDc0DqTaSlZHwugrwhhq02G0sXI3qt3LeekJNx1okieigD1etdX0Cs6X4IZ4QHwwxWZ+zhnlSg0QIR0yw7NeLkAJSxICpQb6PQPya4MlkALFzXpubWNNrb5EMlSTPYL98DAfndv2pVF0rWiiwru6G7GZ0tprY3OH3CTA4+8S6pP/Dqq/cFe6owHo9Zo5yvzOKVaI0fHdF1sNTB5ucZH1Mg5hzUCUrNoqmzDodCOtQKsZytov66bk0q+vcKefW5kPhB8g87V56Lg/riT0PWx7/dS33WGFkRDBWTAPkLw8qJYJnJUjI2Z/wtNl4WA0m9pcgPBkLY10w6us4c0lXijeVf2fq+oKYyUu9qBs/YNcTowT/MymncjF houVIeLU pjNchwxsj6tyyQVo+4FEG3LfqYjNvSVciLcQpYPCQqoWHOO0G/pTnLoNTJpYh9wMlboJyuoLyNna6IZS6uelrD2vK0FR/dXKMTqeb/7zwQpP+F4QdRCve5vHHle7uqgYVFW1tLu2CQUNJoVi/CiTg9AK5VOJIbFWkjWpg+IKKNTI4opdI2QBFxV5oPE4om3F7eEJD 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: Hi Linus, On Tue, Oct 17, 2023 at 10:43=E2=80=AFAM Linus Torvalds wrote: > > On Tue, 17 Oct 2023 at 10:04, Linus Torvalds > wrote: > > > > Honestly, there is only two kinds of sealing that makes sense: > > > > - you cannot change the permissions of some area > > > > - you cannot unmap an area > > Actually, I guess at least theoretically, there could be three different = things: > > - you cannot move an area > Yes. Actually, the newly added selftest covers some of the above: 1. can't change the permission of some areas. test_seal_mprotect test_seal_mmap_overwrite_prot 2. can't unmap an area (thus mmap() to the same address later) test_seal_munmap 3. can't move to an area: test_seal_mremap_move //can't move from a sealed area: test_seal_mremap_move_fixed_zero //can't move from a sealed area to a fixed address test_seal_mremap_move_fixed //can't move to a sealed area. 4 can't expand or shrink the area: test_seal_mremap_shrink test_seal_mremap_expand > although I do think that maybe just saying "you cannot unmap" might > also include "you cannot move". > > But I guess it depends on whether you feel it's the virtual _address_ > you are protecting, or whether it's the concept of mapping something. > > I personally think that from a security perspective, what you want to > protect is a particular address. That implies that "seal from > unmapping" would thus also include "you can't move this area > elsewhere". > > But at least conceptually, splitting "unmap" and "move" apart might > make some sense. I would like to hear a practical reason for it, > though. > > Without that practical reason, I think the only two sane sealing operatio= ns are: > > - SEAL_MUNMAP: "don't allow this mapping address to go away" > > IOW no unmap, no shrinking, no moving mremap > > - SEAL_MPROTECT: "don't allow any mapping permission changes" > I agree with the concept in general. The separation of two seal types is easy to understand. For mmap(MAP_FIXED), I know for a fact that it can modify permission of an existing mapping, (as in selftest:test_seal_mmap_overwrite_prot). I think it can also expand an existing VMA. This is not a problem, code-wis= e, I mention it here, because it needs extra care when coding mmap() change. > Again, that permission case might end up being "don't allow > _additional_ permissions" and "don't allow taking permissions away". > Or it could be split by operation (ie "don't allow permission changes > to writability / readability / executability respectively"). > Yes. If the application desires this, it can also be done. i.e. seal of X bit, or seal of W bit, this will be similar to file sealing. I discussed this with Stephan before, at this point of time, Chrome doesn't have a use case. > I suspect there isn't a real-life example of splitting the > SEAL_MPROTECT (the same way I doubt there's a real-life example for > splitting the UNMAP into "unmap vs move"), so unless there is some > real reason, I'd keep the sealing minimal and to just those two flags. > I think two seal-type (permission and unmap/move/expand/shrink) will work for the Chrome case. Stephen R=C3=B6ttger is an expert in Chrome, on vacation/ be back soon. I will wait for Stephen to confirm. > We could always add more flags later, if there is a real use case > (IOW, if we start with "don't allow any permission changes", we could > add a flag later that just says "don't allow writability changes"). > Agreed 100%, thanks for understanding. -Jeff > Linus