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 C86BCC282D1 for ; Fri, 28 Feb 2025 17:24:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6764D280005; Fri, 28 Feb 2025 12:24:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 60032280004; Fri, 28 Feb 2025 12:24:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4789B280005; Fri, 28 Feb 2025 12:24:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 24280280004 for ; Fri, 28 Feb 2025 12:24:26 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D484B1C9050 for ; Fri, 28 Feb 2025 17:24:25 +0000 (UTC) X-FDA: 83170027290.07.92C05BD Received: from mail-oo1-f43.google.com (mail-oo1-f43.google.com [209.85.161.43]) by imf11.hostedemail.com (Postfix) with ESMTP id E3DB840003 for ; Fri, 28 Feb 2025 17:24:23 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=AUoRD5xl; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf11.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=1740763464; 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=WEwvlNxw2Xxs+TAyoZXFHjuOJ7HCWPZTchi8vXriEjI=; b=5Mye3wOhbFttT2wRbNrEXN3A/GezAES0pQeswwG2Bfhz+k28OvW5ED1Mka6XBoP+3Jhsfw HAAW7H3iHJQ3YByx1IcpY3I0YnRAca8zpdZD/yxt+eTgtKdlKEX/vFohc7PvyakRl68z0i JW4NI1Hx8/1OIQRtcS7rOpOAEGX+XIs= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=AUoRD5xl; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf11.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=1740763464; a=rsa-sha256; cv=none; b=IqgI23IP2+TlFePbKA+XV1WCXjozxMyyHjaN0irpy/JkCx3G/ShizKn4Dx6YghkH8P5ulZ G87CLLgmPRQvXc5OSdXtuNIyriDLUhoU7wpAK3s5UEtfkhtgz0+0pcFO6n399ZHGk6XjzP Ja5UVdChcnb466RDD5h3KXC4Uj3tRaA= Received: by mail-oo1-f43.google.com with SMTP id 006d021491bc7-5fd0c859e6fso151535eaf.0 for ; Fri, 28 Feb 2025 09:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1740763463; x=1741368263; 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=WEwvlNxw2Xxs+TAyoZXFHjuOJ7HCWPZTchi8vXriEjI=; b=AUoRD5xlVyvCiyzC92pAj5nSpzlzsa7YSipoJYklSJfrc9RqO4jcqv3aqAxDKEg+oN /zxbVFQsVi0t3EUBJ4APR74CGnaDlXrn1oyHGiV5uV/ynyE4pfYbbsJCApcCo2ZlHbNI essr444HkFv1BrOw5QSc3U8wqtfWynm8SiObQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740763463; x=1741368263; 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=WEwvlNxw2Xxs+TAyoZXFHjuOJ7HCWPZTchi8vXriEjI=; b=u6eEle6hezYDE/fIrA4cWuUgDuIzRX+pcFzSIGKYlBpmynA+AR/bHxNMiTGqNq7Aa3 JBBp5ZzGRqsAPhSlZjrZfmBy0+1lBr5mFKJ0eC7vJS1E7+NLUyL8us6DE5vKnzldVigC Uuj5KvYGbHgoC6oqe3nmnFtj9DzBDZISsuQpWutxQBK78X6e94gEYJ9+/+ZcZO6MnIG3 8gZvoLvYfj/VOxrMZFDRdRVvxy4mBRamNneZRds7SMtDXlAujovdifg0VnKr+LSa9V6v n/9RMW6Us0ZxxfcA5yAnUZvwQQvMjHjZF5X6Kk08anGBGC/rB2B64MBbdHK9cnLmxaWv pbng== X-Forwarded-Encrypted: i=1; AJvYcCUy7sARYaDGHKEb0TkLfTozUMz2/v5yrVIquclRGZp6hIIB7OLxepTN//qU6HBvCQApFatRe79yMA==@kvack.org X-Gm-Message-State: AOJu0YyO5Ws0rM2KsjAS0ITjWoGwyWcgK500ac+D1h9NbRzsI/AANkn6 YWKGrAwOj3PkfWl7Mwt/a1Qdvf7o6r118gQPFa5aOkE6Zuc+Ptmagkc8zXByptaZRIiUbUBGX1c uzV9vP2C88IQQG37auRV53OaRNde1XKRTMssc X-Gm-Gg: ASbGnctO5mDzSWf9hskDz1y4IIyb07f5xT4aQLZaVuZhlXSf9DRr/SFWfrvak/KdJSS BM1plIbwiuACvowJA4xefYfaBUUtKNTwQjDDHOSO/rAhU4AS/8B7E2jJxbfNLt7UE1e13VbjLua fWZSIdJkmOfsMsmw7vNQFcDox4LU2uwtN/jrZ0 X-Google-Smtp-Source: AGHT+IELmIZtfBk1UK9h8+WtL5wpgAYYMKF9e2oSSIxoQJia0xhiHJ8VA3Nret0YY6RTyQeg0N3QCQfgbJs/+4ZoALk= X-Received: by 2002:a05:6808:4490:b0:3f4:17fa:8b25 with SMTP id 5614622812f47-3f5585f76a9mr1063932b6e.5.1740763462729; Fri, 28 Feb 2025 09:24:22 -0800 (PST) MIME-Version: 1.0 References: <20250224225246.3712295-1-jeffxu@google.com> <60f5b979-2969-4cb0-ad3d-262908869c5f@lucifer.local> In-Reply-To: <60f5b979-2969-4cb0-ad3d-262908869c5f@lucifer.local> From: Jeff Xu Date: Fri, 28 Feb 2025 09:24:11 -0800 X-Gm-Features: AQ5f1JrKoMI7MAoJt_s4VBjawQ2oE7qOjznd7nZIAKK-HcNxZUPVPRG1COgivdw Message-ID: Subject: Re: your mail To: Lorenzo Stoakes Cc: Andrew Morton , Kees Cook , Jann Horn , Linus Torvalds , Vlastimil Babka , "Liam R. Howlett" , Adhemerval Zanella Netto , Oleg Nesterov , Andrei Vagin , Benjamin Berg , LKML , "linux-hardening@vger.kernel.org" , linux-mm@kvack.org, Jorge Lucangeli Obes , =?UTF-8?Q?Stephen_R=C3=B6ttger?= , "hch@lst.de" , "ojeda@kernel.org" , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , "adobriyan@gmail.com" , "johannes@sipsolutions.net" , Pedro Falcato , "hca@linux.ibm.com" , Matthew Wilcox , "anna-maria@linutronix.de" , "mark.rutland@arm.com" , "linus.walleij@linaro.org" , "Jason@zx2c4.com" , Helge Deller , Randy Dunlap , "davem@davemloft.net" , Peter Xu , "f.fainelli@gmail.com" , "gerg@kernel.org" , "dave.hansen@linux.intel.com" , Ingo Molnar , "ardb@kernel.org" , "mhocko@suse.com" , "42.hyeyoo@gmail.com" <42.hyeyoo@gmail.com>, "peterz@infradead.org" , "ardb@google.com" , Elliott Hughes , "rientjes@google.com" , Guenter Roeck , Michael Ellerman , Alexander Mikhalitsyn , Mike Rapoport Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E3DB840003 X-Rspam-User: X-Stat-Signature: z7t7repskyzzo1m9btfsr1otcdabqx19 X-HE-Tag: 1740763463-165498 X-HE-Meta: U2FsdGVkX18bYSo1/aB4spzhAlb8nAJSCj3JOR13e0KLiiK+1abZ3a/1dYdK56CTEARD0rQSlWzIrOVN9W4nPALMFzvF4Q2TvkDvSwEd5VC32Sbk8BXJYwy+ItsY9gj3vuzg7izkk4IqXzLmgoByST06oz8NwOiP8xJ/S7e6HZKoQp6VownHAYOuGhKbOUeDLAY36SLhs3EA88e0zh+JzGZ5M0QvzW+vkm7CcyqzGZFP5iDu9eLUabrO6zhBOhnsPxfLLClb0bX+jkAVADNEW+vq/dmh9sjR4SchlznHhuv3gNHC37Go/ZkUoYGDQGkFPGTJi9uhmvSLQ7RhzQJ7fFWmxA6mLnA6UIsWV2W59cc+BoQ/qXhMcJnoLxLKP+2SPcEbeLUq2qPieiREluIjT4MpRXWoKpbIf/9eE/4CeMDkruhc3aH4NY8vVw/0hHJ9Lfw5UkBN3cCcQUGIM2PqpZdfZ6yLHMyHjX1kZNmEzzrJzGr8K6EfrwnBPqCvqzCR0bHkXx6T2bJDgrtTME/01EDQXqzIZDIVfuBJaKzHkwiyxOdllIpmKx4cReBu43kmkJRPby/PYYwdeM755xsLvOXozaSUu6HYPo320kmgNvXRVcNmKEWXVulKaWX5jfyey7a17QX61euganfiHHOCl5L5CVPRnfZY+0iMpdAcU8Ox46g3Vk3DV8vhlI/HX3Y6ORQNnO9lVROuXDv7c5yLMuTGw9eDP4l4Eg70Qb5d/KcpksfzhVwgE7bcYhQKxb1tkKVdhEehb5+ux9aBSEyj05f5PwY/lnNsYSdJfx5z78eUS+BGvlSOuL7QaLll3oW10L9MwbEBrfUtJXdMoBuxDdc02BIwIHAHYu5xk338r9v6HXwzytSYWrp7K586sJUvu3gS+DBL3SIuZ+29NFH+6wjvbEbOk12ru1QVobvpI/TjQpxG38ihvw6B2VRnw5dxkiDlV/6Jwj9gZ4ymrrF WZqP6sey 8AvKgnaCtJCaBs3GoCxqjJaNu+xVF6qp4IvxThani8i30bXZwTZMFKrBZpjJo8WDsGDuFhEQUgLMNH0N+I/D45aq1MvXKxSODgNX4n6ufKGZQVJMoQ16BFG2TogBbdIAfkRPslJ4JZnilIiqVgfEt9HBhkb7s84bLOlj7BBiehzBDw9FwBjLn1Pnm/AHNbEgaJGNERg3A0llUGXFSJB08dO7+2qu5zSrwUMwkAuOAOxMfU9ktfc2nT0v9aUIWD1OLIwj2PbfpNiiI42zSWYH4IsjDnMlIOIKs6qLU+CGFB9hrdWhvWzZ6xwq5JkrfZZsFBlpaGPREV9ZEWZ78Q9m3iWe8wehvhBvFNUojgAAsanASTAZEehJHZcUSqfQ16vPMV2yk 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 Fri, Feb 28, 2025 at 1:35=E2=80=AFAM Lorenzo Stoakes wrote: > > On Thu, Feb 27, 2025 at 04:55:06PM -0800, Jeff Xu wrote: > > Hi Lorenzo, > > > > On Tue, Feb 25, 2025, 9:43=E2=80=AFPM Lorenzo Stoakes > > > > > > > > 2. Tests - could you please add some tests to assert that mremap(= ) fails > > > > > for VDSO for instance? You've edited an existing test for VDSO= in x86 to > > > > > skip the test should this be enabled, but this is not the same= as a self > > > > > test. And obviously doesn't cover arm64. > > > > > > > > > > This should be relatively strightforward right? You already ha= ve code > > > > > for finding out whether VDSO is msealed, so just use that to s= ee if you > > > > > skip, then attempt mremap(), mmap() over etc. + assert it fail= s. > > > > > > > > > > Ideally these tests would cover all the cases you've changed. > > > > > > > > > It is not as easy. > > > > > > > > The config is disabled by default. And I don't know a way to detect > > > > KCONFIG from selftest itself. Without this, I can't reasonably > > > > determine the test result. > > > > > > Please in future let's try to get this kind of response at the point = of the > > > request being made :) makes life much easier. > > > > > There might be miscommunication ? > > This version is the first time you ask about adding a self test. > > Yeah I thought I'd been clear but this might _very well_ have been me not > having been, so apologies if so. > > I mean 'make sure it's tested' is an overloaded term right? So fact you'v= e > tested on android, chromeos, etc. implies 'tested', but also self > tests/kunit/whatever. > > > > > IIRC, you had comments about providing the details of what tests I did,= in V4. > > As a follow-up, I added a test-info section in the cover letter of V5 > > Thanks. Appreciate that! And this really does point towards a > miscommunication on my part, will try to be super explicit in future. > > > > > Though I have thought about adding a selftest since the beginning, > > there are two problems: > > 1> This config is by default disabled, > > 2> No good pattern to check KCONFIG from selftest. > > Yeah agreed, it's a TOTAL pain. > > I wish we had a better way of doing this. Maybe a self-volunteering > exercise (*goes to write on writeboard :P*) > > > > > > > > > So I think it is easy actually. As I say here (perhaps you missed it?= ) you > > > literally already have code you added to the x86 test to prevent test > > > failure. > > > > > > So you essentially look for [vdso] or whatever, then you look up to s= ee if > > > it is sealed, ensure an mremap() fails. > > > > > This suggestion doesn't test the core change of this series, which is > > to enable mseal for vdso. > > Right, and thinking about it, what does this test? Just that mseal works > right? > > It's sort of implicit that, if a VMA is sealed, the seal should work (or > rather, tested in mseal tests themselves, rather than mseal system > settings). > > > > > When the vdso is marked with "sl", mremap() will fail, that's part of > > the mseal() business logic and belongs in mseal_test. The mseal_test > > already covers the mseal, and this series doesn't change mseal. > > > > As for the "sl", as I responded in the "refactor mseal_test" [1] , it > > will be part of the verifying step: > > > > [1] https://lore.kernel.org/all/CABi2SkUv_1gsuGh86AON-xRLAggCvDqJMHxT17= mGy-XutSTAwg@mail.gmail.com/ > > OK cool thanks. I will look at this when I can, I'm just snowed under > pre-LSF and have been sick so backlog, backlog as discussed off-list. But > it's not been forgotten (whiteboard etc. etc.) > Ya, no worry about that review, please take time to recover, I will wait. And appreciate your time and take priority for reviewing this series. > > > > > Of course this doesn't check to see if it _should_ be enabled or not.= I'm > > > being nice by not _insisting_ we export a way for you to determine wh= ether > > > this config option is enabled or not for the sake of a test (since I = don't > > > want to hold up this series). > > > > > > But that'd be nice! Maybe in a > > > /sys/kernel/security endpoint... > > > > > > > > > ...but I think we can potentially add this later on so we don't hold = things > > > up here/add yet more to the series. I suspect you and Kees alike woul= d > > > prioritise getting _this series_ in at this point :) > > > > > > You could, if you wanted to, check to see if /proc/config.gz exists a= nd > > > zgrep it (only there if CONFIG_IKCONFIG_PROC is set) and assert based= on > > > that, but you know kinda hacky. > > > > Ya, it is hacky. None of the existing selftest uses this pattern, and > > I'm not sure /proc/config.gz is enabled in the default kernel config. > > Yeah and I'm not sure I even like my hacky suggestion here, I mean let's = be > honest, it sucks. > > > > > One option is to have ChromeOS or Android to maintain an out-of-tree > > test, since the configuration will be enabled there. > > Nah haha, though of course you can do what you want. Really want somethin= g > upstream. > > > > > Option two is to create a new path: > > tools/testing/selftests/sealsysmap. Then, add > > CONFIG_SEAL_SYSTEM_MAPPING=3Dy to the config file and add a selftest to > > this path. This seems to be the preferred way by selftest, but we need > > a new dir for that. > > OK I like option 2 let's do this. > > But let's call it mseal_system_mappings (yes I"m being nitty again :) I > really want to try to _explicitly_ say 'mseal' because we have other form= s > of sealing. > Sure. If long path names aren't a problem, I will use mseal_system_mappings, otherwise mseal_sysmap. > Not your fault, but we overload terms like _crazy_ in mm and need to be > cautious as not to confuse vs. e.g. memfd seals. > > > > > > Option three is to add a self-test when we have a process-level opt-in > > solution. This would allow the test to deterministically know whether > > the vdso should be sealed or not. > > Yeah one for future. > > > > > > > > > But anyway, FWIW I think it'd be useful to assert that mremap() or mu= nmap() > > > fails here for system mappings for the sake of it. I guess this is, i= n > > > effect, only checking mseal-ing works right? But it at least asserts = the > > > existence of the thing, and that it behaves. > > > > > > Later on, when you add some way of observing that it's enabled or not= , you > > > can extend the test to check this. > > > > I think it is best that we don't add a test that doesn't actually > > check the code change. Do you think one of the above three options > > works ? maybe the second option (with a new path) ? > > Yeah I actually agree on reflection. And yes agreed option 2 is great, > thanks! > > > > > In any case, I think the risk is low, and the code changes are quite > > simple, and fully tested. > > Yeah indeed, but I'd really like _something_ if possible. If option 2 is > relatively quick let's get that sorted out! > Great ! I will work on option 2. Thanks -Jeff