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 CD8FDC4332F for ; Thu, 14 Dec 2023 22:53:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6222C8D00F5; Thu, 14 Dec 2023 17:53:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D1D48D00C7; Thu, 14 Dec 2023 17:53:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47C498D00F5; Thu, 14 Dec 2023 17:53:13 -0500 (EST) 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 31A928D00C7 for ; Thu, 14 Dec 2023 17:53:13 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EE3D11A019D for ; Thu, 14 Dec 2023 22:53:12 +0000 (UTC) X-FDA: 81566926224.25.9C4DE86 Received: from mail-oa1-f48.google.com (mail-oa1-f48.google.com [209.85.160.48]) by imf16.hostedemail.com (Postfix) with ESMTP id 32C6218001F for ; Thu, 14 Dec 2023 22:53:11 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="K69jrZ2/"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf16.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.48 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702594391; 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=qmbndnjcrhmBBoxS6pcuDX2mGwfUQXEv+7vBpDoTDrg=; b=hNDRWnIrguTuP8dltUWaWQv9MMWIMFz3/mJxxNRSlKdfF6hRYDqPYeNKbEyXV7SLqKbHV1 VqJiUGnKEjvgE0/vRdTIUYTDPVeSKSTxwuMN6LDleSfGz6Ov82w06bzHcxkNvE7Ab3vV6+ yT/tRYkgkNTM5Ga3W4BSErI5n++lpYk= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="K69jrZ2/"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf16.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.48 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702594391; a=rsa-sha256; cv=none; b=RVYH6YrKjECRBB0th5DMkFuDbF5UeBcygYJDxVdtP5MGppSzhfgzTBIZBCzMDgTbmfClP7 S9lxsfujPFiiMlzeWHFgOq+DSLqmaKfoMm4pN5BIVVzxdN8SCK2pYUuufvkaUoMCGgblyA oVWNTVN+LrFoQqoh/ZqUV7NAvUS7zJE= Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-1ef36a04931so48592fac.2 for ; Thu, 14 Dec 2023 14:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1702594390; x=1703199190; 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=qmbndnjcrhmBBoxS6pcuDX2mGwfUQXEv+7vBpDoTDrg=; b=K69jrZ2/RRX+FrfPbqzMbSef1WqrOHwMrC88FIh+hacEGAu3eB0I5zbep4FnvZz/XW UPF1AQQRvL85042nthzXbMn9nWWZ7vFtkOu09+5g1UpU/NJRDxM+Z7v+4HbaPu+nCcYe 3ziSKAmZqBOLx484Fmtfkhb4Y6ZZ53RtOQEvw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702594390; x=1703199190; 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=qmbndnjcrhmBBoxS6pcuDX2mGwfUQXEv+7vBpDoTDrg=; b=bJnBv4uKv+lgyT5EZcNgdIuCNpyE8VTL0jP+rLuXSvdKpiTOvL57vjXFxgals7rf67 2glhKbkS4et+Z/pybPJAVvb+eOJHovux0x8lF7DPWKzm4n0JWtUvXoWxaVIcWKd3Rv34 1tgETYzkM/XjmKuUa/wIKhbggVtUD3SNWEQkbTVVzV3JNrOMCh5YsUr/oYwpllklSc7C Nz5GBOTkcGOCnM7H/Xux//xWTOxVcqLxkhNiEwZhRjwnEqMZhtypUMlACMqUMrS3PNEF GXkfZ0ENlp8Ni1cX6y0HnZ9xGxoh+pIuscs4DvTEaL2qSZXgKtyOwjsrHOQ6Mv+Gbnr0 woeQ== X-Gm-Message-State: AOJu0YwbuxbAiNuJZmFfSkoc8ZJIG9tsGsdGVXGkXbVQOEAYwSBpYa6j 3+SJDaaAtNRPtnBgYpJOnttXs3NWr8p8NT3wmEZv5w== X-Google-Smtp-Source: AGHT+IFJ3y2PMmXoZvkDVH8ICFf94qmbkoc3S1Oy8RrT8fx8p95Ie2no/+Omtw/FDZnEY3SV+ywQp6V5BnIOf2HtW54= X-Received: by 2002:a05:6870:41cc:b0:203:4c85:562f with SMTP id z12-20020a05687041cc00b002034c85562fmr1695983oac.59.1702594390274; Thu, 14 Dec 2023 14:53:10 -0800 (PST) MIME-Version: 1.0 References: <20231212231706.2680890-1-jeffxu@chromium.org> <20231212231706.2680890-12-jeffxu@chromium.org> In-Reply-To: From: Jeff Xu Date: Thu, 14 Dec 2023 14:52:58 -0800 Message-ID: Subject: Re: [RFC PATCH v3 11/11] mseal:add documentation To: Linus Torvalds Cc: =?UTF-8?Q?Stephen_R=C3=B6ttger?= , Jeff Xu , akpm@linux-foundation.org, keescook@chromium.org, jannh@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, pedro.falcato@gmail.com, dave.hansen@intel.com, linux-hardening@vger.kernel.org, deraadt@openbsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 32C6218001F X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: m19w6o3hj6jyymdfq6jdat75bmzeau9b X-HE-Tag: 1702594390-139021 X-HE-Meta: U2FsdGVkX1/K2Ah4UiUenu+H5JiM2Nxj5GkQuSgiTr2KehBOSTNkQWOuTtsy6jkum5Rc5qbu0XlrpXLzmtu8Rf88RWeZ8W6kh2Mye+yR7/oCjNOmOmkEn4iHrUY24pB4eegN7zKHn80Vj3cXMoScvxYlAYvkRaeEbuZQtfILbh4FP1Vekb1II+rMG4KxRuCvdqWDRdhOsQlOMDeFSdtPXArYsNbjZFlGKRWEW2qwl+lcZlqhWBqZUBVql2ZTTCXURrAML8dI49A/S1jTaVgHsrRpb8eIhWwBeHVPTnIWyhOsyd8w4i+vVjEaTIRbVo9Yb3SbnaKJgRvkLh37bRf4t6Sbsu3p8H+UK5x51LIPfaPiZxvt8FF/OgNH7NVLCtYKbEcZPI3O84yhUPQFcsstiC09joHHhginezk+u3YYTynhb0BYGaL8UpPMJ1zM/zIwHL6dtHxB3t89jsVRgTuZCIXJbDcH95hRjh/HNzUhTsu0Eq/oi1B9wFi6dzKPkGI+njOZn//f+srdseV0IBF04+wnQ3rG2Xt70rdkEhNnMgIJKH8zuBU2uI/CBSNzA8MT16gKSvIuaxOabOEazi0GHnvjm8gH36vSduDrlm1bdqfmW0ckfFOW06crM6vdIhlJ7KIoVLBQ5gG5odjVkm0vSnsFHZtlYYXZPi+RA1uN/D21hFQtf+jO/BiYWFEKcmTbz2aJjFE+DwNm/TR9Mc9s9wj7lPgLZWnHCM7zTniO18KAD2cxU89W/9pcqWMO8ijYaf38Nb8bPNIbzTYYs0TT/YPUKtnjQVWhBwHEc6CqkvcVhSh9sTD1aRbEEeHNMq/jZsflF/K9IAztL9wVzZowCkbIvp6m/U89IUt3XYvWzyV2qWhMVuJ/pNujhLPyRDBgDwmTiBn/Vm2+HeBM9FZ4+yBNP/YOWUmg7YLKYE11pz9985EdFn/vMh6GeZeZeSAOdJtVs3PXHVBBOHiAg7J d3x0lhUQ iLVA0OY7Z9pxfMlnNEgJ1jJ6p8Mwwnud/HIifBRgkoloshb4RNXusmw5iAHF7YqsBFqd8Ukc5nc47xrtbi3DVj7i9IcbX8lN1g3bUeTyncN6F7OOrXrZYT5fP5n9RZYEhiqaWxXGfPXGB0BBkUiku1KYgoTyoGuGXhLDOIDHxdoZKm4h0wDkgdLG7H+8yZwNB9iueT3P7XLmFGtWEN7XCCgzcFqf4B0465WIfuSAImLR/UW7Y9cm/mypRKhoLu0McfuMcfyWviAh7QjD6i1uHDEhJgX8xBHOBlztR1zHs6KiVZb+QqgBrGqDUiuaG8FRCKgtlgfvzfo0KO6RP0AlkhS7jym7CHwiPluzEKt18nZRuFIZdTgDXovEDNaq8LxeWkH+m 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 Thu, Dec 14, 2023 at 12:14=E2=80=AFPM Linus Torvalds wrote: > > On Thu, 14 Dec 2023 at 10:07, Stephen R=C3=B6ttger = wrote: > > > > AIUI, the madvise(DONTNEED) should effectively only change the content = of > > anonymous pages, i.e. it's similar to a memset(0) in that case. That's = why we > > added this special case: if you want to madvise(DONTNEED) an anonymous = page, > > you should have write permissions to the page. > > Hmm. I actually would be happier if we just made that change in > general. Maybe even without sealing, but I agree that it *definitely* > makes sense in general as a sealing thing. > > IOW, just saying > > "madvise(DONTNEED) needs write permissions to an anonymous mapping when = sealed" > > makes 100% sense to me. Having a separate _flag_ to give sensible > semantics is just odd. > > IOW, what I really want is exactly that "sensible semantics, not random f= lags". > > Particularly for new system calls with fairly specialized use, I think > it's very important that the semantics are sensible on a conceptual > level, and that we do not add system calls that are based on "random > implementation issue of the day". > > Yes, yes, then as we have to maintain things long-term, and we hit > some compatibility issue, at *THAT* point we'll end up facing nasty > "we had an implementation that had these semantics in practice, so now > we're stuck with it", but when introducing a new system call, let's > try really hard to start off from those kinds of random things. > > Wouldn't it be lovely if we can just come up with a sane set of "this > is what it means to seal a vma", and enumerate those, and make those > sane conceptual rules be the initial definition. By all means have a > "flags" argument for future cases when we figure out there was > something wrong or the notion needed to be extended, but if we already > *start* with random extensions, I feel there's something wrong with > the whole concept. > > So I would really wish for the first version of > > mseal(start, len, flags); > > to have "flags=3D0" be the one and only case we actually handle > initially, and only add a single PROT_SEAL flag to mmap() that says > "create this mapping already pre-sealed". > > Strive very hard to make sealing be a single VM_SEALED flag in the > vma->vm_flags that we already have, just admit that none of this > matters on 32-bit architectures, so that VM_SEALED can just use one of > the high flags that we have several free of (and that pkeys already > depends on), and make this a standard feature with no #ifdef's. > > Can chrome live with that? And what would the required semantics be? > I'll start the list: > > - you can't unmap or remap in any way (including over-mapping) > > - you can't change protections (but with architecture support like > pkey, you can obviously change the protections indirectly with PKRU > etc) > > - you can't do VM operations that change data without the area being > writable (so the DONTNEED case - maybe there are others) > > - anything else? > > Wouldn't it be lovely to have just a single notion of sealing that is > well-documented and makes sense, and doesn't require people to worry > about odd special cases? > > And yes, we'd have the 'flags' argument for future special cases, and > hope really hard that it's never needed. > Yes, those inputs make a lot of sense ! I will start the next version. In the meantime, if there are more comments, please continue to post, I appreciate those to make the API better and simple to use. -Jeff > Linus >