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 3642CC021A4 for ; Mon, 24 Feb 2025 19:25:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1BE328000D; Mon, 24 Feb 2025 14:25:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BCBE428000C; Mon, 24 Feb 2025 14:25:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A930828000D; Mon, 24 Feb 2025 14:25:07 -0500 (EST) 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 8C5F828000C for ; Mon, 24 Feb 2025 14:25:07 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1965DC1BFE for ; Mon, 24 Feb 2025 19:25:07 +0000 (UTC) X-FDA: 83155816254.18.80F02FF Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf14.hostedemail.com (Postfix) with ESMTP id 6E4FB10000B for ; Mon, 24 Feb 2025 19:25:05 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="M+Un/Jtp"; spf=pass (imf14.hostedemail.com: domain of kees@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740425105; 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=2dwYc/gfk+mjnYVCFUsNVOGy28tbPX4Pfj2hPBlo9XI=; b=gohHwM03RKVVbNPRPY35eTmzkS9/vJg6j5aWAW2Vp0ZLckWOPUC03QherhW99VpIdVL0iZ lmMW1lXDidPSZnr2pshu5v+braD9Ulb6iVm36xSQgIuks3D/1KrD3y5VSljQe2RPtxe9rz MQS2bNEjNDeccVA8pZobXFz9n9cU3B4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="M+Un/Jtp"; spf=pass (imf14.hostedemail.com: domain of kees@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740425105; a=rsa-sha256; cv=none; b=NFHrW3hZKo7sYRvluYFoGdKQ6MfPmGLix/aoBQcreefs9akNVscO5hguEH2gWjhtbyvlB5 NZ0C5tmC53jfTKEVHVJf6j5dKPT0xpQ6mvmOqVDL6J6Ui3rRCUdC4LdP1JLVBhS7uFy8Jz R9oci+fIVSI+aGjCyclCXWg+bekmYP0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 94199611F6; Mon, 24 Feb 2025 19:24:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2AFA8C4CED6; Mon, 24 Feb 2025 19:25:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740425104; bh=fjHcvZgvhTSj5FFdxPdTk8Lrdzdg91sRk6S1mMi4Ecg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=M+Un/Jtp4PMYsu31G/MB+IssTm4ML0IcZHZJuXJZ5gat79fHEjhseokSxoMn37u0U cMPJlHQMu8vpQYUwr0zcFhE6jye6ox9AkoXfGZ3dUjfbfSrD+fJARvD/f+qm8Xlb76 a5aYZdqadSKVP4kxOcxwV8hlPfqxbzKQ1sSgyNGydW6Ati8FarqauaHK2JQOQp8aXk zYe0vy9lg4Wmb9q9Y3PfEVrgN3RZYIjySk2LixWgwOQy905Gx8aMN5yprecw3WGPJC /a/X3AgCfNuYpwq5lV/adtEbh+ExsuBrI/1fuQqNEhYH9YHowmOjBpSG0VBv3xVppI 75gxhF8ZQzOzQ== Date: Mon, 24 Feb 2025 11:25:00 -0800 From: Kees Cook To: Jeff Xu Cc: "Liam R. Howlett" , Dave Hansen , akpm@linux-foundation.org, jannh@google.com, torvalds@linux-foundation.org, vbabka@suse.cz, lorenzo.stoakes@oracle.com, adhemerval.zanella@linaro.org, oleg@redhat.com, avagin@gmail.com, benjamin@sipsolutions.net, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, hch@lst.de, ojeda@kernel.org, thomas.weissschuh@linutronix.de, adobriyan@gmail.com, johannes@sipsolutions.net, pedro.falcato@gmail.com, hca@linux.ibm.com, willy@infradead.org, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, peterx@redhat.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, enh@google.com, rientjes@google.com, groeck@chromium.org, mpe@ellerman.id.au, aleksandr.mikhalitsyn@canonical.com, mike.rapoport@gmail.com Subject: Re: [PATCH v6 1/7] mseal, system mappings: kernel config and header change Message-ID: <202502241123.D398A24@keescook> References: <20250224174513.3600914-1-jeffxu@google.com> <20250224174513.3600914-2-jeffxu@google.com> <443992d7-f694-4e46-b120-545350a5d598@intel.com> <3nxcy7zshqxmjia7y6cyajeoclcxizkrhhsitji5ujbafbvhlu@7hqs6uodor56> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 6E4FB10000B X-Stat-Signature: cbjt1ku7tqg15mqyw6q3itrqrt6d4wie X-HE-Tag: 1740425105-135849 X-HE-Meta: U2FsdGVkX18IPfGzy5aM87o5uyqxt4TMeKyczsf2SkXLBubRknlR/W8K4Xv3ZL2bKo6Rb2fBYh9jk8mTtApwj6xnQczGMNnz7QoNcyGc2DvyhEvxOIZrUZjYkFmNzarukIUPmqSxzzdSpMpkB8G4oVS+nSA6gqqg/U9sTQEL5AmhGl2ws9uw3bCijWZ6sgg4alEz8q9tAZ4bpawk6KXiGtNrGMBM00PTcDWcgp67er4nHqoJyA6tVqWaL6Hd6fuEsVEKfa4uwNtkw+KdnVvaFeNsq2dZd31vj950I23XVRGE/672N8FZ8+nTjG7BI+a+mZP6Vx+slebOjKl1u9dmSLFplAtAa1QKgM17PBE2uYt20URYAa05A2AvEwmM7fTVMWrXgZfsfDMeZOWcWIl4JQTvMuQ74jFHuCX+WEhWYZZYIYUFFav0bAX9JFjoZefaYuBVhvBWrrTz6No6oD7E0LX4FTSnUV2lEFBu7mwfeR79/UGCuDyqjwprlxshkmrkJN6R5Fi238LYVtivZNyA4bId5+vBC7jDaqeJcFNVKqDZDZHSUXqA/qZXH5mcXb4ZjUqFxNaf0mZQGRmiP5gvVgFr6TwaVynNSEQCaC6jaziKXR5bIqZUp+r0zi7FaoahvwFCTncF0Gf0oGIRKSeLz9JxloCAll30mM0j4859O9747FAx6vJbPbJ7b/hUNo7MxFpagUascYZx+KdmCdJRGEXDQuMpN84orS4Cf5cE/k0Z3DWSdrsfshsODo7T0ZjQFNn+bDl061USVXzaCUGcTxC32ec85rG8hoCUAP0zGGU2cJuxr+xofg0XBFipM/g2Z2seJ8PRmvFXyYAd45mP40yjVqmtwqVWeO3j6OCPNrVClS6Mk9XkCmdy6x7xe74RyuTYkvGoBllP+tK1kBji2bqFFzgpwYlUp2CKdSiuu6Or4X8p8y9enVeTB/wDs42yF56/DQ0gEMPiuskr0U0 /9HmnI1U YxURYgrRzIS1f6EqCqwG+6yDuUTUu4Z7Jk7jzDxN7rDUKrOy53QFZVMWBI0qhXfCEoV8HZA2KKzeIgEIJ3S6GkBCWvD1s/07UuiCTUpW2X0qiW61fOGMFggAToEKRzGoPSwpUlXtYJFHvS4Z870gJ0jIo6THPu6bsB6tlrSXanQFKlR9I/Gp+RKrXTPpr4DA7F4x4NPqbmYFvAkiLw1o0s+jyk62Y9//N85mpIGHMWrf9UEus+1odxERNgAGfOf+vSXH7ohXS5Mrb6BBTCZach84/4bJe+yN1LPH3tFypMHDoMpFNIlEalusqlNBdQsKOvj+NhPBUeqtZ0xlNhdevnPhnRYK8OQLETQ3jkMVQHFmuxk/xa6eo01pEzJDG0QQUm9CazJsmiLK/wk7Wbk528v3f6dsCNgFeEeJV 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 Mon, Feb 24, 2025 at 11:10:22AM -0800, Jeff Xu wrote: > On Mon, Feb 24, 2025 at 11:03 AM Liam R. Howlett > wrote: > > > > * Jeff Xu [250224 13:44]: > > > On Mon, Feb 24, 2025 at 10:21 AM Dave Hansen wrote: > > > > > > > > On 2/24/25 09:45, jeffxu@chromium.org wrote: > > > > > +/* > > > > > + * mseal of userspace process's system mappings. > > > > > + */ > > > > > +#ifdef CONFIG_MSEAL_SYSTEM_MAPPINGS > > > > > +#define MSEAL_SYSTEM_MAPPINGS_VM_FLAG VM_SEALED > > > > > +#else > > > > > +#define MSEAL_SYSTEM_MAPPINGS_VM_FLAG VM_NONE > > > > > +#endif > > > > > > > > This ends up looking pretty wonky in practice: > > > > > > > > > + vm_flags = VM_READ|VM_MAYREAD|VM_IO|VM_DONTDUMP|VM_PFNMAP; > > > > > + vm_flags |= MSEAL_SYSTEM_MAPPINGS_VM_FLAG; > > > > > > > > because MSEAL_SYSTEM_MAPPINGS_VM_FLAG is so much different from the > > > > other ones. > > > > > > > > Would it really hurt to have > > > > > > > > #ifdef CONFIG_64BIT > > > > /* VM is sealed, in vm_flags */ > > > > #define VM_SEALED _BITUL(63) > > > > +#else > > > > +#define VM_SEALED VM_NONE > > > > #endif > > > > > > > > ? > > > > > > > VM_SEALED isn't defined in 32-bit systems, and mseal.c isn't part of > > > the build. This is intentional. Any 32-bit code trying to use the > > > sealing function or the VM_SEALED flag will immediately fail > > > compilation. This makes it easier to identify incorrect usage. > > > > > > > The reason that two #defines are needed is because you can have mseal > > enabled while not sealing system mappings, so for this to be clean we > > need two defines. > > > > However MSEAL_SYSTEM_MAPPINGS_VM_FLAG, is _way_ too long, in my opinion. > > Keeping with "VM_SEALED" I'd suggest "VM_SYSTEM_SEALED". > > > How about MSEAL_SYSTME_MAPPINGS as Kees suggested ? > > The VM_SYSTEM_SEALED doesn't have the MSEAL key or the MAPPING, so it > might take longer for the new reader to understand what it is. I think to address Dave's concern, it should start with "VM_". We use "SEAL" already with VM_SEALED, so the "M" in "MSEAL" may be redundant, and to clarify the system mapping, how avout VM_SEAL_SYSMAP ? That capture's, hopefully, Dave, Liam, and your thoughts about the naming? -- Kees Cook