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 05E21CDB47E for ; Wed, 18 Oct 2023 18:20:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92C3180018; Wed, 18 Oct 2023 14:20:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DE558D0016; Wed, 18 Oct 2023 14:20:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A33980018; Wed, 18 Oct 2023 14:20:42 -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 6A9F58D0016 for ; Wed, 18 Oct 2023 14:20:42 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3FE831CB3E6 for ; Wed, 18 Oct 2023 18:20:42 +0000 (UTC) X-FDA: 81359397924.13.2B3FAE4 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf07.hostedemail.com (Postfix) with ESMTP id 724BA40024 for ; Wed, 18 Oct 2023 18:20:40 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kLkUgCrY; spf=pass (imf07.hostedemail.com: domain of jeffxu@google.com designates 209.85.160.176 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=1697653240; 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=6vVIrHuWQVA6shM3HnYPie5+SRU5CPGTqtle1JU5tXo=; b=x4Zf8TKINS0IE6VNPakyKiSR1NVKamAQTanqXOAmQgaCJT0oQgRlqu2oaAvvTFDjncOzKx 2RsXamFiJi3j0Or/NuEsQb8X6O9N6Rl65DBL62iiSjjzzJ41Xio0QDaRAWgFGw7GmXf5tO McyiHI1FU6Ws/muYaYju2pMZ9GwYsO4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697653240; a=rsa-sha256; cv=none; b=7LBx0jp0ljYkiV5zTcBFX0i6SVY8t/kFPtH26Fnrm6vF6NPJNLeb/k50qPerIFnCpbWmb6 NoQnrd1unOLQ+tPNus4JKa4ihPmqd42m8g+xawwXZQc8PQh0O2zb86Wrw2HYlwvYto8Puu BPys2OVhJtXu1pwebVK+ED7s3Ib5YBo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=kLkUgCrY; spf=pass (imf07.hostedemail.com: domain of jeffxu@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-419b53acc11so42681cf.0 for ; Wed, 18 Oct 2023 11:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697653239; x=1698258039; 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=6vVIrHuWQVA6shM3HnYPie5+SRU5CPGTqtle1JU5tXo=; b=kLkUgCrY9vozUs65++4DNwsTAKcZ/A0S9E1PWtg0YQiWT4/bt0ikaP23otKNi/HGIh wB/9izs8oMdRC3aff+Q5sk7uwZvopI14/8W33noaat9Px4knfGkj5Ezax26d2U89bHq+ T3gLOsQAYwwIXSpFUag22goUh1KQup/dd7u/yEO5MGzvDrdisxoimMohW/s3YuWRq2Ts IU3X9olLbzy3QgQGmo7+FvYUdw1BOnQEnaD6IsKBlTyctwvEzctOtQ+psMXcnlVHTt1V 8sWLhwRkaacpH9PgNncKF4dCG5LqWqtxBJRMckN8o0q+5MV2cF81ocIfXKHdKCX7jFy2 JOOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697653239; x=1698258039; 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=6vVIrHuWQVA6shM3HnYPie5+SRU5CPGTqtle1JU5tXo=; b=KBNGjdaT3b8iRDnWQwMVDc5Q/5BUR9C/UnA+0ON1zxji4T7wWK7xbJMoVkebugTqu7 dDEK/UPRK0xVTnlM11jNziQDOiU/DGXWyzNl/2kTU8GT4GB+oS9uo/4dwYgFddQZ9QJ0 AyOwfNY2bLYbONUGGHKCQpObjezayWHG4/RQzVAZPIbZJnNXreHSlyxw1oSitRnCJ5PR p8WmO7nWwpVEFCVglB/j16ylcuBcCOFnw0QgzT6pRwEodXURJU0fsqEidM0f2DZ4ZNj+ cICo4Cks+3oQO+oWKgp30oVzBxWfbYOAi7g3JJyuFu1lj32062ElRZGVK8kflDC1VkwS 9R4g== X-Gm-Message-State: AOJu0YzG+1X0jieg6LUPUFtMo1kUQKIsNPGKJ0O4TtFX6tqQLHc03MZG Q4Yh9GKyfX7q3epU8Sqmzl8sa06nRhRIc8LHyvx/aQ== X-Google-Smtp-Source: AGHT+IGyGQSgQHJFj8BImsesXGVlASS7RW6eopJfbHL22F8InhKtFg9dsIpDe/ROKjo5uadHLqVLhE2zRmNvOeNRnlY= X-Received: by 2002:a05:622a:a049:b0:412:9cd:473b with SMTP id ju9-20020a05622aa04900b0041209cd473bmr48343qtb.4.1697653239212; Wed, 18 Oct 2023 11:20:39 -0700 (PDT) MIME-Version: 1.0 References: <20231016143828.647848-1-jeffxu@chromium.org> In-Reply-To: From: Jeff Xu Date: Wed, 18 Oct 2023 11:20:02 -0700 Message-ID: Subject: Re: [RFC PATCH v1 0/8] Introduce mseal() syscall To: Pedro Falcato Cc: Matthew Wilcox , 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, torvalds@linux-foundation.org, 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-Stat-Signature: mz9q6zff95qdn1mqbb855a9sfcmnneb4 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 724BA40024 X-Rspam-User: X-HE-Tag: 1697653240-190001 X-HE-Meta: U2FsdGVkX18lexpbeHDI24gISuz2qdIj7+ceQeFCc4qFy328CZa2vDcYfDpl0KgdvVUdV6aLwg1ieZB8ZirNDEdBq8FUV8ahptNeeRJ9ZTBPOxCSCbyc04nHNKHn16c9ukOOmUR6ICPJRnHiqdbcyWPNDypRosdHsO2rAcd9+lo6MZkXFikvYNKJH2jg1fJXlAu++wb3JcNXro2pWalYS+Ma/fLMOiR/dI/KKaj6B2d2k+c8jDkN4siJbF2n0r8RevyDTwqwHv0Mt5yHmiqlo2xdH6Zih8cq59fCG5jdQ/tal1W8GDFa+44CSyRywbIvG5lRQLBswlwRrHKLqCBteyN8GXfvTjcNZ8sRCzQBhTxXW1llDzo6nslv4Ipv13nBNaKZ6zf/1yjdfHvt+XrDD9SV/eJwe8iH+V+DHoyvjLh8EVrEAJJ/ubw0ij6bSXhyng16rEKVqkYHTPakNX7R/XytZ6JUpVFs4Q+jQVTLCpwjuoWhSaA0iFn2v5cEberjCqPSWIp+MB5xmPiI3cNvwny3xnSvgxGrTzS6Jua+zvpox4+Drf/Um/W+wGOwT7B9Zu+a2a/36qtM6cTDsDifa/JS//sCogKYVkMfGjhaM8tJKYjoXZNQL+o5duB6qakl3py4cxJt+0irZxx68Ypd3WDLsRTcnXKjga884MmSieHlqZn3XIXlxCyKkwgP0U6yw0Mzp2UZvOIlKQUSugGEcCl7irQdYhPhI+ylkJ5/Z5uCBKTEGVEF2tWAa4wSw+TiVRy8QOQE4/53kDLg+lbqf6NToGdURyxWEuLWGpkWqWb8VCnL1nmZ3DKuGZlvHnPb7ZOeQezPmCRMvD2b20Fl06r4uYW0K+E5MnejyHPYaLUOLdhcPlwLSosjLZnx6Me3tHWZKXI8l5ACCpTCTBw62HAW1oKodDIpl91ICmDJTLzsxa0rX/3gWayoFvBO7ctd9WvymMAVwAEeTRsQdgQ dJgd6hjg 1Y3R+SmgKP3w+FDfOPmX2ZcYcaD+HlcLtDttRwOXAXPSzc+gIUx16mHFJYJaFqJgZS7vD3RsgiV1kEA+QZx5saJkYaRCqgX/GfsUg5WUpPGBGKZD0YJV77c8NEbj34b0mHEZEve4TaemWgXAeoov6EAyBbEafQbFB/FuZxeaiP9BAalure1MpDfkQ5hRIqNpTaOcymNo9BB5zTX0B4bJx6eVTpJ3y/PnGxf0PMRQhVQSFzNExbzXYGSZb3QrHYflWalOK5dNU/Wbze5JzSZGeyS1YBCVxf/NFXN8XXguSsWS9iM61xJTbza9YCHCSV0a5muDekm5QIiHa9b/o8br2QcHbcCSU4uNrr2nLtiN38jC1vMVcOqcugjr2FQTAQLQ7Lw6O 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 Tue, Oct 17, 2023 at 3:35=E2=80=AFPM Pedro Falcato wrote: > > > > > > > I think it's worth pointing out that this suggestion (with PROT_*) > > > could easily integrate with mmap() and as such allow for one-shot > > > mmap() + mseal(). > > > If we consider the common case as 'addr =3D mmap(...); mseal(addr);',= it > > > definitely sounds like a performance win as we halve the number of > > > syscalls for a sealed mapping. And if we trivially look at e.g OpenBS= D > > > ld.so code, mmap() + mimmutable() and mprotect() + mimmutable() seem > > > like common patterns. > > > > > Yes. mmap() can support sealing as well, and memory is allocated as > > immutable from begining. > > This is orthogonal to mseal() though. > > I don't see how this can be orthogonal to mseal(). > In the case we opt for adding PROT_ bits, we should more or less only > need to adapt calc_vm_prot_bits(), and the rest should work without > issues. > vma merging won't merge vmas with different prots. The current > interfaces (mmap and mprotect) would work just fine. > In this case, mseal() or mimmutable() would only be needed if you need > to set immutability over a range of VMAs with different permissions. > Agreed. By orthogonal, I meant we can have two APIs: mmap() and mseal()/mprotect() i.e. we can't just rely on mmap() only without mseal()/mprotect()/mimmutabl= e(). Sealing can be applied after initial memory creation. > Note: modifications should look kinda like this: https://godbolt.org/z/Tb= jjd14Pe > The only annoying wrench in my plans here is that we have effectively > run out of vm_flags bits in 32-bit architectures, so this approach as > I described is not compatible with 32-bit. > > > In case of ld.so, iiuc, memory can be first allocated as W, then later > > changed to RO, for example, during symbol resolution. > > The important point is that the application can decide what type of > > sealing it wants, and when to apply it. There needs to be an api(), > > that can be mseal() or mprotect2() or mimmutable(), the naming is not > > important to me. > > > > mprotect() in linux have the following signature: > > int mprotect(void addr[.len], size_t len, int prot); > > the prot bitmasks are all taken here. > > I have not checked the prot field in mmap(), there might be bits left, > > even not, we could have mmap2(), so that is not an issue. > > I don't see what you mean. We have plenty of prot bits left (32-bits, > and we seem to have around 8 different bits used). > And even if we didn't, prot is the same in mprotect and mmap and mmap2 :) > > The only issue seems to be that 32-bit ran out of vm_flags, but that > can probably be worked around if need be. > Ah, you are right about this. vm_flags is full, and prot in mprotect() is n= ot. Apology that I was wrong previously and caused confusion. There is a slight difference in the syntax of mprotect and mseal. Each time when mprotect() is called, the kernel takes all of RWX bits and updates vm_flags, In other words, the application sets/unset each RWX, and kernel takes it. In the mseal() case, the kernel will remember which seal types were applied previously, and the application doesn=E2=80=99t need to repeat all existing seal types in the next mseal(). Once a seal type is applied, it can=E2=80=99t be unsealed. So if we want to use mprotect() for sealing, developers need to think of sealing bits differently than the rest of prot bits. It is a different programming model, might or might not be an obvious concept to developers. There is a difference in input check and error handling as well. for mseal(), if a given address range has a gap (unallocated memory), or if one of VMA is sealed with MM_SEAL_SEAL flag, none of VMAs is updated. For mprotect(), some VMAs can be updated, till an error happens to a VMA. IMO: I think it makes sense for mseal() and mprotect() to be different in this. mseal() only checks vma struct so it is fast, and mprotect() goes deeper into HW. Because of those two differences, personally I feel a new syscall might be worth the effort. That said, mmap() + mprotect() is workable to me if that is what the community wants. Thanks -Jeff -Jeff > -- > Pedro