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 1A2D8CDB483 for ; Wed, 18 Oct 2023 18:55:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA2B78D0187; Wed, 18 Oct 2023 14:55:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A524D8D0016; Wed, 18 Oct 2023 14:55:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 808AF8D0187; Wed, 18 Oct 2023 14:55:01 -0400 (EDT) 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 6BE608D0016 for ; Wed, 18 Oct 2023 14:55:01 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3FAD5C0460 for ; Wed, 18 Oct 2023 18:55:01 +0000 (UTC) X-FDA: 81359484402.28.3F4E71A Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) by imf14.hostedemail.com (Postfix) with ESMTP id 84DBF100037 for ; Wed, 18 Oct 2023 18:54:59 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dxtNiBsa; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of jeffxu@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697655299; a=rsa-sha256; cv=none; b=KMmEsVCqVMSX7qU7fLQKRPMH9zndaZN6zmnU+TBNOLcgvYJr3kAcJRNPUj/+bhWLpYPaQE mCKnvU2E3EosdGGzTtO3NSuqt6BWdSnt6YeGH57xq2kCtQCq+Ygx86AzsAMuvyPEmfSlZ9 wr/uJmJb+0VDYDF7jPV6LMimr0ciEJE= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dxtNiBsa; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of jeffxu@google.com designates 209.85.160.179 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697655299; 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=NFJlA+mQhi+0DERBwp78bB/+mqro8rSJvhQZ9F+v2NE=; b=2bBdyhJpUOxCQQ49qpRQw3jaDzGAQSTV6akFH9YMXeNLdR0BD2PN5AQCC/Hrp341Aeg2HN VvrZnmzakXdm15BLypXyJ4Ydj7tsw22g9o7juzHEv/2QZJJ2b/gO+Zc9EI2jL1h9QbCbPT GnZSae53prjfPA2RexDc8XnPyDVD3CA= Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-41b19dda4c6so48251cf.1 for ; Wed, 18 Oct 2023 11:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697655298; x=1698260098; 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=NFJlA+mQhi+0DERBwp78bB/+mqro8rSJvhQZ9F+v2NE=; b=dxtNiBsatRhBDeK5SYeR3WJpRm2JQjKqZXiIlnJ3FNmnmnYUjwH9sHVL9i1X4j7B09 6MEQkfMo2pTVEGYd+Z6CFftOh6Pxl8A9YF43MGF0hOO+G6cQdwmHfF5CA0vweyCKrwlg k6j9RxCkC1vsS2epd9Z0NFt2TJfztsXUbfV5fW+QMQq2oDNKre1jHddFhPxn5Huc5GnN cFU23fChOQYorSDusO58+AxvnTYYtxp78deDWTUUYIszXQMvQuOT2HQDe7Hh+xjdWl6i oWhTJRDmr+ChzqGHrtzYCob7lYMOU8ElgETIDxnPhYAtQj3WL5J4uX+RyZ5XRwsWqqCO JBlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697655298; x=1698260098; 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=NFJlA+mQhi+0DERBwp78bB/+mqro8rSJvhQZ9F+v2NE=; b=tfbVh1WHxke/g8khVfIjdJ3bZED17zBlAOZZm+sz57wg4y0TRE8+0rCfEjOz7x/Cwk cK/kCsdluXhnw35VW7VJSyySx+/B/kXz7CeXvWRjxvFUCK7YkKyzURIzkcysAE3IBnUE kKzHVT0r9hON3cgWUE+BVkuJHnO+AYRmYQEUP7tJ3CK24pJ7EMSX+qopsB20dkeOfHFI 0lRKqYfdG2O2Uw+WPOk1tnE6rr1tXRsKUz7eiBd0GvBxIXJR1kj5/sXn2jmZFaxhFzZp nwUiBrNdQ3e+I8d4MkQXketG2vECEIXSMpFluKT9yGUTTygZ2KcP8t9yG05NjL443V7T iF8Q== X-Gm-Message-State: AOJu0YwZb2uXFz63P5ckgsUzF1ZC9tX6A5Jn91AK+3jofa2rBgBzfBZa cncsZ+Q9hh5OeR3ebHzoOLqClzUZrLqWMCXlYvoa6w== X-Google-Smtp-Source: AGHT+IGjizzkFJ61gHRpVi03W6jxKFHsg7oR29EE+XHiKGg+Nd1AGPkE/bY4MhXNSrPSxo096Ldf5GQvn/xYA+BV/to= X-Received: by 2002:a05:622a:668a:b0:419:77b7:da5f with SMTP id hx10-20020a05622a668a00b0041977b7da5fmr39818qtb.11.1697655298459; Wed, 18 Oct 2023 11:54:58 -0700 (PDT) MIME-Version: 1.0 References: <20231016143828.647848-1-jeffxu@chromium.org> <55960.1697566804@cvs.openbsd.org> <95482.1697587015@cvs.openbsd.org> In-Reply-To: From: Jeff Xu Date: Wed, 18 Oct 2023 11:54:22 -0700 Message-ID: Subject: Re: [RFC PATCH v1 0/8] Introduce mseal() syscall To: Matthew Wilcox Cc: Theo de Raadt , Linus Torvalds , jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, sroettger@google.com, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jannh@google.com, 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-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 84DBF100037 X-Stat-Signature: q6hpii5zfg548cxih7dpjp7m13reaodo X-HE-Tag: 1697655299-108860 X-HE-Meta: U2FsdGVkX1+vfDgHy+i1w39SWpUyxrwl80UXPXLxYsy6KFvIzDy7yQjm5w+qISirLavY/Gs0e5zN723P3k0mHo6Qm2WeJK5Rz+AlN16+9etL1BIvN+lXxRFFzVq09UPjhr0kwdIRoECjIEEyrlZmSsAlW0pjsoU0vNYQjWoTchPbr6dPO/cPpiCZ4IXAmacAl2QTtBUw2tjI6p8inPp3BqJf8zfr/qPJGwpEfgIcMUFOTQ+PkkEY7exYiAP05Gg5QLxTKUsTjtfStZqVxZqDwJnfiV8bjSK5YBGQMQiXrBgA5/hYnd3g4OYMGu80HjEOumcuYY2Ijsfq3DamVdOwEzBp1NLWisn+Ywc37sFeDh24NLMmRvjbD/3EGXEbPUt+cHXC8ZrogIb7/RgTm/GqxFgWPU9R2YCwQ5rPJhH20Nuf0Y8R3Wszh+RG3hnVYMCPw0hDnDh7vfw81go1xyQ6ClpD+gWlrJfKQCY/ratqNaRTc5n42z6PmBfMbZsecKOz8cvMwPNW+hCwrf06/Ok5OtSAv1cvpaU+TmV0qBUqsEk37BsSsk97X55zC/L5Ukh2W/l4Q8pPgatKLq51CerIa/DahJvw32ThvukzKTM8TXJI+qce8vAioUqZnQg+Cr+5UCuNs8Jid8VFVSrotS+K2d+1AJlN0KMD2IsN7Lf08jpyxfzsYoO9iOVpsJjpfgUPkmot/UkqPHhreDH/EKUm94eylFJJ8ANLOSQ/5i9xvpwEXuPvnCBPWALfNW+CYoBQ2MbdXwOYi3NBvBl6W6DOcOK3NAYuDA+eEexiBPdZlYQOCeA5P11NRv9VTROBJpJgFsOpppnHqSf9r9806jJYIp5ATrH5sbQ3KyUVCSbfd2ZWkYZU/zvNr9ZeNNoDTdaXWZbrLUo0JLDLUud9Oe2nY0p8Zgv2kdc7kZzRF8FIeC3N4VkSGJJWouMpj0VYpV1XIUFcCpjytpX4TQ8K9Dl Hz6FdnRw RDzEJUDfkERjB/RJCf/0msQRAOldibVa9AdQtJ2shXqArLyFp0zOIYHJ7hVg3ouNyb1esoxh3oXMF5qF9Mq99VNv+A4ivEuQaHu7Ci+hq3yisWETzDAze3/ujQrWDucYWZnMTAwlLnSw25IFlmAeWmQfas21Lp2RW7io+v0qPg7qK2EcL70R2H9xktUTS3S11SwaKedpxwSaXjpLtQ6cEE7V1o4kW8COIeLf56OFKZGB75Cdq56xr1crjszQVLahORB4wdMohSUpz7y79jdbBi88GwtWNP+teT1/R 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: On Wed, Oct 18, 2023 at 8:17=E2=80=AFAM Matthew Wilcox wrote: > > Let's start with the purpose. The point of mimmutable/mseal/whatever is > to fix the mapping of an address range to its underlying object, be it > a particular file mapping or anonymous memory. After the call succeeds, > it must not be possible to make any address in that virtual range point > into any other object. > > The secondary purpose is to lock down permissions on that range. > Possibly to fix them where they are, possibly to allow RW->RO transitions= . > > With those purposes in mind, you should be able to deduce for any syscall > or any madvise(), ... whether it should be allowed. > I got it. IMO: The approaches mimmutable() and mseal() took are different, but we all want to seal the memory from attackers and make the linux application safer. mimmutable() started with "none of updates to the sealed address is allowed once marked as immutable", this includes from within kernel space including driver, or any new syscalls. It is reasonable to me. mseal() starts with 4 syscalls from userspace, which is just a way (among m= any other ways) to demo what memory operation can be sealed, which happens to meet what Chome wants. This is an RFC, I appreciate your input. Best regards, -Jeff