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 570D2C19F32 for ; Fri, 28 Feb 2025 00:55:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB72C280002; Thu, 27 Feb 2025 19:55:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C4053280001; Thu, 27 Feb 2025 19:55:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB9A0280002; Thu, 27 Feb 2025 19:55:22 -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 897A1280001 for ; Thu, 27 Feb 2025 19:55:22 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3B4ED12131E for ; Fri, 28 Feb 2025 00:55:22 +0000 (UTC) X-FDA: 83167534884.12.C348D16 Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by imf30.hostedemail.com (Postfix) with ESMTP id 58B9E80005 for ; Fri, 28 Feb 2025 00:55:20 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=QHxaqSHE; spf=pass (imf30.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.169 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740704120; 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=4XdIbSK97U2bcx4CS9xaVietnaFUPHThbia6b1sB6bY=; b=vmcL+nVhyOnhL7GlpzP39wvsi2FbPkDb7UWhvPUcVw39Z2KdeB5J9BLLjRCIeBSNsWe6up ZZWOWiB8cE0xtY+KeomTfz+NGVW9jRQ2iRA0+ATEm5IhlshWlrtgZKOOyUwZjn9KzlSJTY sjcRxCXCFskQIrX+ICvUVtciraFnHWQ= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=QHxaqSHE; spf=pass (imf30.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.169 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740704120; a=rsa-sha256; cv=none; b=8hPBZvt8KiU8j5PCJrCMGJ72zNGOsEeXyO+r0m/lBIuxZwMtFD3PzVBjDNgoJHrXF627MV lbr/+SfPmLt7cfUDBv1Ds2lvVCUX73qbbUGRlNsi+z3hSvjcV+8ZMa6QOJnZtZlRbgm4BD luCmlVLrDz71pUgdq6x0HqAJRXmA9PE= Received: by mail-oi1-f169.google.com with SMTP id 5614622812f47-3f411a225a2so24497b6e.1 for ; Thu, 27 Feb 2025 16:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1740704119; x=1741308919; 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=4XdIbSK97U2bcx4CS9xaVietnaFUPHThbia6b1sB6bY=; b=QHxaqSHEDztdzRkf9uOuY0aUK90cuECK3u4jDorDm4MBPewlY3fR016tdnmasUElCm qIWY/e1GmEZm/Jwc9AhzMEvM+NqpFtDbuFkfP1QmXwoJncbC6pUUF2MzFqQL1CMMOuzV mB6jTEdT57UQIbkAEvQLJ6WWVDuOt7YSFlKjQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740704119; x=1741308919; 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=4XdIbSK97U2bcx4CS9xaVietnaFUPHThbia6b1sB6bY=; b=JDIiCChTdxHH0GRcV4M5kcHdX4Ez26Gu9E7Rpy4mFsejcQ8/r4sO+LESHuuZZh9uAL 6FY2I8irZ35MiMyFb5TL35FSPhPPe+bMU38sjUFn2iz3OmftfGywJUVTLfr5iEMPVYlk 1AMn0EM5ne1nU6EN/YvI/27uirRdB7ccooy1VGGACM0IgZF4fo0bYjTPBmqWjXxKc3uh gLQrOpUDExQYi0nUU9I//tUvNLT+qJKdd43kAkKQ2IpG+xAJhOY+34UtEi1pmQPDssej YMNfCm06WUgzai3Kcrey0o5/KYXeh6+5xhTqO/h3sqgKkC/7Mg8idsVypsNQQE+A8Id9 6BRw== X-Forwarded-Encrypted: i=1; AJvYcCUZGRd0bDutDNr3hWMGIB9WtzgJ+fvaKzq7D0UpeHIeCffLJuyIRa65W9YqVT5Q1t+eQmnhSP0M3w==@kvack.org X-Gm-Message-State: AOJu0YzkjaAIaQs4ZJC2FMnfM37GOuHAQIXgPyNyNQzhxyRbxmTfDO5V H2yRh4sjCXYMibk67k5sAQEJ+Psvwfrmm73PLbh0pvJEVXiuRLGzqIJqTUeqbSFL0KzM9dqGEIt N3oEH4x5ZT/yNQow3YQQhAtc18MBcRgI/hju9 X-Gm-Gg: ASbGnctEapXWvXyFBaz4oOXjN9vxl0VcLeG56aKHgcNa+OYKirEbJdPZZDXwW7AkTwU Xs6LtBrbhwrye4aVeu0f9NyIdCDh8yP/KbqcMBWKTS6bjNYnbONfC6m5PuBEm97kr39Du1V4z5v kv4hkhUO18HQJkcdHmqp9nfx4UcfIrkrJDKx1/7gE8 X-Google-Smtp-Source: AGHT+IEE2Zd0YzlD1eKMXngbEqBUP4PcSWI2iH/mCQwG/4t9rw5I6pMzSFtNyw80iCn/K5sXKW6A8N4md+Tsh7pLQmA= X-Received: by 2002:a05:6808:bcb:b0:3f4:ad6:519c with SMTP id 5614622812f47-3f5584f047bmr344626b6e.2.1740704119270; Thu, 27 Feb 2025 16:55:19 -0800 (PST) MIME-Version: 1.0 References: <20250224225246.3712295-1-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Thu, 27 Feb 2025 16:55:06 -0800 X-Gm-Features: AQ5f1JrkAFHfI5uVGX9oxsAvwNBUue9qkGMdRly8ZF6iNxbuavzAsApzVHFK-rU 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-Rspam-User: X-Rspamd-Queue-Id: 58B9E80005 X-Rspamd-Server: rspam09 X-Stat-Signature: 1o4qi5j3om8y7z38k77akkbczoe899fs X-HE-Tag: 1740704120-811927 X-HE-Meta: U2FsdGVkX1/jg/4nbC70JSmVZR7jJL8OqhbzCzu/3P6Ksc1w66E4Zl2Yde/yM24jyj9VmQTFm+jwiHWRIFJbEpBIdAadUnrkpjJOZ39m7nEAOd1OHb1Te+mhq01K4xlWSfMVVAu4sNN0aBb/G81bl8cA+8E2O2pucsjvnLmsgAdCXOhSJwHcuErnCNvlrk/xgGFMPmd0TjMnYzOTSnLuvvbjYZQ5CFx3XpSE44atXgdCHXhDoe4btUbTrQqzP3oo92c1Wlj8MT4qRy8bmHmeSiHSiiUWeG7UJtuIMId7QromquRnxevKo3y4rzwQkisceczS0eQiinMCbU58W3guTsBykmpoD543t5iMFUYGL2b8er7VRbMHzHkBDfHpZEMu6Bs6mgIr7g7JefhYCzUOlZvciE0tpyjAp/9jthbYTCmckScIzLzXBXMVBKVRfpIaUBrGYfMSum77Qmb9spOjcYjFLKaXpVRhBlKioTy3vAzDoCv+aJWkKKrq5qPtBD3g7jqqn6+nFxmjyNSEEuCjxABjwhkMwfc+e70IvV7dUfmj+xZgOB7IXnKMmU4ktjam16Z7wf+qWTbiVOUf5DXeS1u15RTKy0kIFDu1atNrbgOYN5w3gJFcshcnGweE5e1R477SAfwiess9r8HPnDTkc/mGl6kWAfPFlGkvQc23krEYvWAnhdSSnAkz0CReFHx0OfdkyA64Qd5mHOU4MfBZYeUQ+BKtUWptMHv7RpcjfDJA0WgfUkG3mCDXoBqEpmjOm+khBbpuTcVrsfp+6BocKWD1ZrVrqBSGoNaIavR+K8aJC7Ff9HFfIQkqy8f7HU9y48igPEYCyCPd/Efwap72wTl+2/xC3ZOo8ebMLL3+ESJT6drRi2WbgEvufcSO3ObNgE3dXFqAIV4NPQ8HbiJo/H+CA6s0EWVo/KL1R67/DVkp4R0ds3WqxkU8lGJHGEfhMEb78KzCbh2sq/Mx4CV omjQ5I9r /1ONpDPnMN6fsrBnhOOs8acTyKiZcah/X55eAJasrQhGLW5p6alVvzXMwm2IQ7EGN4gB+aOBsZ2NzeXMOgVnxlzIJFX794M7Jr4s8SPdeE+qgtquCVKCPiOJwiK7K/eaSaNkpgZIKVv4/4YIzjVUQ+++TiX+0CDWp+4NM4ZUkQ3+8slpcTvGyU0fhxL7QS0mAk61n9ZOo3Mk4mqROpERW1snZDiwh9RubXELEf9Imc9rbVjkn9TG1hVsy2E5UU6SgRqkfNga4t7VbvuTm0ke3AER06hcgrUlJlKU+AJ8estoB5vO0VHtHqbldPFQawtPSC7TMaiD1jq0FX/CmdCLs+Spr8H+xa0lcJs6mdhuvj8L8XiM= 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: 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() fa= ils > > > 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 have c= ode > > > for finding out whether VDSO is msealed, so just use that to see i= f you > > > skip, then attempt mremap(), mmap() over etc. + assert it fails. > > > > > > 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 t= he > request being made :) makes life much easier. > There might be miscommunication ? This version is the first time you ask about adding a self test. 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 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. > > So I think it is easy actually. As I say here (perhaps you missed it?) yo= u > 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 see i= f > 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. 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-xRLAggCvDqJMHxT17mGy-= XutSTAwg@mail.gmail.com/ > 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 whethe= r > 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 thin= gs > up here/add yet more to the series. I suspect you and Kees alike would > prioritise getting _this series_ in at this point :) > > You could, if you wanted to, check to see if /proc/config.gz exists and > 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. One option is to have ChromeOS or Android to maintain an out-of-tree test, since the configuration will be enabled there. 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. 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. > > But anyway, FWIW I think it'd be useful to assert that mremap() or munmap= () > fails here for system mappings for the sake of it. I guess this is, in > 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, yo= u > 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) ? In any case, I think the risk is low, and the code changes are quite simple, and fully tested. Thanks. -Jeff.