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 DBB3AD6C299 for ; Tue, 19 Nov 2024 20:57:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CB786B0088; Tue, 19 Nov 2024 15:57:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A2496B0093; Tue, 19 Nov 2024 15:57:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 442956B0095; Tue, 19 Nov 2024 15:57:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 24A566B0088 for ; Tue, 19 Nov 2024 15:57:54 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D0036140814 for ; Tue, 19 Nov 2024 20:57:53 +0000 (UTC) X-FDA: 82804052898.17.B8D1848 Received: from mail-oo1-f43.google.com (mail-oo1-f43.google.com [209.85.161.43]) by imf20.hostedemail.com (Postfix) with ESMTP id B3C591C0007 for ; Tue, 19 Nov 2024 20:56:48 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=edxBK5GW; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf20.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.43 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732049805; a=rsa-sha256; cv=none; b=rV/FoZm7wsaiUbhxisZpBZeQ89lMtpxlomrny1Rw3IyguEyJsEzaEGpqi3eK+qmUNfgV71 VnHg1+C0Y9ng9dkaSqwc+hZYXZedChhkQCn1SCLLrYAVCtC7Yq2uZ7Xs32EBNBumkXZn78 90X8esxXst8qsuz5T/igHv9w0YQ8EsI= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=edxBK5GW; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf20.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.43 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=1732049805; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=IO9EX+rbjLtm8cqkrUr8HQs42GPnLgvoRuxnFLut8c0=; b=ZaFVQ9fLIrxOQZ9t9XECUxBiyjHfUDeRwmkn6XJojePXWT9/wy1qF7q4udmcY+lTNga3aE 0CKmltIqKIcRZWmqy38sWuzx+4fvy3JaLXaYGleGMZvSHLIpf3vbaH7vecyze/aM8j9Bdx hRdPWhXKwKFvaPCyjlo7HxSVoeGRHxQ= Received: by mail-oo1-f43.google.com with SMTP id 006d021491bc7-5eb8b48a257so361238eaf.1 for ; Tue, 19 Nov 2024 12:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1732049871; x=1732654671; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=IO9EX+rbjLtm8cqkrUr8HQs42GPnLgvoRuxnFLut8c0=; b=edxBK5GWXrXd5dqePuJ6A3MB+HjJUalIWKqyj40AdeSUdhIeiRHCuvq6JNTOFZTxXx Z/98wglehRcAyhqG0A7eaNORmFsNCxAhq0yzLnofDvgl4Ucl5I6wQ9/7nSrry7fG3hzf 6c3454nCpZWrewtnt4/0yP2MQXEbEGjXuDyRA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732049871; x=1732654671; h=content-transfer-encoding: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=IO9EX+rbjLtm8cqkrUr8HQs42GPnLgvoRuxnFLut8c0=; b=EpZ0ZGFlFXWp5+viIFW9Wjm+YDu+gczsDWfuIC+r9l930DwjlxqqMR3lEqb+rf0kGd u7OeoAwupUvMRbg8yqMR849W/Wjj3m/RcHWp2UNfu/77QVuAnj6ky9tbiioGZjNrspD0 t5PW+Z4CVw+XRWWrKq21zNibltvrbnZSqB3w3NMPtSF3qnLAjG3w2kauHvdNJRmk4qAP /5XGGW9H42fMNtX1Lpx3FvncazB3ovedCeheuz0K6Kx3b2WR8IcS6aKtZnrisDQgN6P4 ElWtTyJGEL6pgVq7oaRNL7EULmV/3ZoAfTdNmwC2HI43aE4seitsnCTNdm4NPEVBsDvD Ztpw== X-Forwarded-Encrypted: i=1; AJvYcCXbq10qeGXOjgEMX0xBH4lwA6+aErWCN2jpUO8PACIUyCXFnh715Uti+CrI7KlG3rJeSxFEsn/MRw==@kvack.org X-Gm-Message-State: AOJu0YymyIfO/scyNCeJkevLYQpYXvAPjS5vXG5zTg1J76HfyiJdSm0U 5x/I801HeWKZ1E4ZupLJvuUrFPz5SCZWjZY/du10TwQjkrSDCaIUUorSpk81N/GEuSoilcaRxlx IXSAg+Hr/uDgDIWuCA3IWvEkZ/+eeu8SK/Lx1 X-Gm-Gg: ASbGncs8WSAL/fYkxZ7gzJNUxs5kmfj1bioiVvPXAdBKv+BjH9e37Sj8t+VdY3oS8gM +GIShvf245WFDbBoOdwnUPddEGRB97vfBBfcZONxJAsLQvtRHpebeV0SDSr86 X-Google-Smtp-Source: AGHT+IFTrU1fA61t0Luh+9E+lP7gFvXHb60eu4Gw43LbPkNHC4l2jJzMO4RiOm3/mriXN7Czm3b797q73IggsHtNEWA= X-Received: by 2002:a4a:d342:0:b0:5eb:c1fe:881c with SMTP id 006d021491bc7-5eee7ee759bmr95103eaf.0.1732049870869; Tue, 19 Nov 2024 12:57:50 -0800 (PST) MIME-Version: 1.0 References: <20241113191602.3541870-1-jeffxu@google.com> <20241113191602.3541870-2-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Tue, 19 Nov 2024 12:57:39 -0800 Message-ID: Subject: Re: [PATCH v3 1/1] exec: seal system mappings To: "Liam R. Howlett" , jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, torvalds@linux-foundation.org, adhemerval.zanella@linaro.org, oleg@redhat.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, ojeda@kernel.org, adobriyan@gmail.com, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, hch@lst.de, peterx@redhat.com, hca@linux.ibm.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, lorenzo.stoakes@oracle.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: B3C591C0007 X-Rspamd-Server: rspam01 X-Stat-Signature: 4bn5eaatrrg9ezs3bprq8yhc96g1wayw X-HE-Tag: 1732049808-222089 X-HE-Meta: U2FsdGVkX1/lZ86zL+QlOFRVsFKWSCzKl6VAd7kjlIVjGD3bpZRrH9/EkOAIyWsq4usGYPrQueS9H609EIMvpkR3aLONXb3ohN/y1tNwl2UKPdBkM3A0pgb/o4GAaYhFB8MZEnscnX+JIcg5rvFaJsuCgn5rVIHaSnllT4SE1gFUat+8XP+hsKv5ZegyO8uz4OXfi+Gv/Z14otz5VSaN77UlMmDHXtK3T6lQc41EHG+q7DvN973b1SF5l1sJOLB2MM5c/x9bIGd2zqc8mQ4iy/BP1SsXniObmENi7XtpkzSD7N+xF1M23ejjLwW3AkMYf3MCk0mVJBvVCyEB9O4YX1h3i03HO5Gu+JrBKbwPomeaCdiRPaiqtyuwIFCEt6wOHd5ZmyuDMQoJogTmI33tfsgA6LQ21hl6EWHhdpk1UFtfcDOBQ4yXLQ87omHPnY4ITllcJ2FRgZabN9BOdoeMXBBYYjCn2uEg6MpVVVj97LSqem7qc4PUKuvQPpMC5+Cy1pzAtNoS07AdCAxzHAbzRtIQprWFjP1UUjs6CJHKJ5o+OJ27aj68qnX7VlfyMKSeyvOGZQx7C5kY0UirPkgpfBhEVinJgkcDsL3U0yjPD+9RtbndcQB7TdVRwXbft26JUoGXZy2GesUKsFOdBR0OGahgl5EIrAqpGmFgmJcmS6N5aA0PwEV8iMh2nB0do+iEyc8m16mb70gkMIqX1lG4IGXZSsfdyV41vSgv36mWlGhxqVBsQdqNZRfiDMS/YDO6jtnuKbaR7TpZBkG/SH/wVKTiwsStrJAR7PPN/PinVVAqlPnvWiQdyI9evWDHEANrAdNqL5qZcy8QycQR0mlxkoNszMi0U588Ta2po6A5cFNRlxV5jFC33JJMR0bKYXrPCMZY2rN2LtlDoGx+fBhCwB1b3RlPrQDGyyO/e0SUi+TGGuG9N5mVYgtTmsZEnDn3UL/Eat6FGmHHQjP8dsm FiKFcEtV KGEanMGwnDVcoC5jGCA+m1rgK1K9gDSByoTiEFv3jasn0A7j/amU+eoBpb7h/bdkzYqoxbuL2ySpH+LNvy907OiEUA+iGLPjvD/wzYbB2CUpfyyRf/WpQYsk4MzLweYCyN+tPWuwCQimZYba0Vz4/30IwAGS1wt1elr1bEEeoVPHOyVEitnjqSnyOrpN3urP2yYEdJuiv2etk9mVKq6OCGRAP4lSyBZ0wvoufEF6QP/RILWXbUrLYrb9fW+GsJYLnRk2hQVyIX+I1+5YMMpkveD2+hdyNPQaMLoPGL1lvW3D4b4aCysUAB/Fy/ot38cVh50jtn2tuEowBPPP4tPFczeb/Dg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000296, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Liam, On Wed, Nov 13, 2024 at 4:54=E2=80=AFPM Liam R. Howlett wrote: > > Unlike the aforementioned mappings, the uprobe mapping is not > > established during program startup. However, its lifetime is the same > > as the process's lifetime [1]. It is sealed from creation. > > Why are you referencing mseal.rst for the uprobe mapping lifetime? I > can't find anything in there about uprobe. > This should be [2], thanks for checking. > > It also can't be used on 32 bit systems, as per your kernel-parameters > changes (and mseal specification). This is missing from the changelog. > sure, I will add that to the commit msg. > > + exec.seal_system_mappings =3D [KNL] > > + Format: { no | yes } > > + Seal system mappings: vdso, vvar, sigpage, vsysca= ll, > > + uprobe. > > + This overwrites KCONFIG CONFIG_SEAL_SYSTEM_MAPPIN= GS > ^^^^^^^^^ overrides ? sure. > > - if (vsyscall_mode =3D=3D XONLY) > > - vm_flags_init(&gate_vma, VM_EXEC); > > + if (vsyscall_mode =3D=3D XONLY) { > > + unsigned long vm_flags =3D VM_EXEC; > > + > > + vm_flags |=3D seal_system_mappings(); > > + > > nit, extra line here. > removed. > But.. this will add the VM_SEALED flag on any 64bit architecture that > enables the SEAL_SYSTEM_MAPPINGS config. That will happen by bots with > random config builds. I don't know if they have test cases that > specifically unmap the vmas you are sealing (ppc64 probably tries to > unmap the vdso). > > I do know that I've had syzbot bugs that unmap _all_ vmas. I'm guessing > you will get bot notification on these failures for any 64bit > architecture. You may want to look into it to avoid such fuzzing > failures, but we still need this to be tested somehow. >test_mremap_vdso.c I found one selftest that could fail: tools/testing/selftests/x86/test_mremap_vdso.c I could add tools/testing/selftests/x86/config and add CONFIG_SYSTEM_MAPPINGS=3Dn there. as instructed in selftest documentation [1] [1] https://docs.kernel.org/dev-tools/kselftest.html#contributing-new-tests= -details > > overwrite or override? I think the difference is that overwrite implies > permanence where override doesn't. I'm fine with either, it just reads > a bit odd to me. > sure, changed to override > > > > +config SEAL_SYSTEM_MAPPINGS > > + bool "seal system mappings" > > + default n > > + depends on 64BIT > > + depends on !CHECKPOINT_RESTORE > > + help > > + Seal system mappings such as vdso, vvar, sigpage, vsyscall, upr= obes. > > + Note: CHECKPOINT_RESTORE might relocate vdso mapping during res= tore, > > + and remap will fail if the mapping is sealed, therefore > > + !CHECKPOINT_RESTORE is added as dependency. > > You could also add a portion here about your override functionality on > command line. "this can be disabled or enabled by..." > sure. > I really think having something that can be found by searching for mseal > is really desirable here. That is, make menuconfig, press / for search, > type mseal -> find this feature. If this was MSEAL_SYSTEM_MAPPINGS, > searching for seal or mseal would work and would serve to link the > config option to the mseal document. > using "seal" would work here. I will add a note here to mseal.rst for refer= ence. > Right now there is no information in the help that will allow it to be > found by 'mseal'. There is also nothing in the documentation that > states this exists, which you should probably update with this feature? > I will update mseal.rst to include this feature. Thanks for reviewing. -Jeff