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 1D80FC282C6 for ; Mon, 3 Mar 2025 20:21:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9BDC1280002; Mon, 3 Mar 2025 15:21:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 945A2280001; Mon, 3 Mar 2025 15:21:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7BEEF280002; Mon, 3 Mar 2025 15:21:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5A23B280001 for ; Mon, 3 Mar 2025 15:21:10 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id F065750D4E for ; Mon, 3 Mar 2025 20:21:09 +0000 (UTC) X-FDA: 83181359058.03.9A3402D Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com [209.85.161.45]) by imf12.hostedemail.com (Postfix) with ESMTP id 8893A40013 for ; Mon, 3 Mar 2025 20:21:04 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ikX4QxrO; spf=pass (imf12.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.45 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=1741033264; 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=no1wNnrlYf60l/eQVo26WKDaWNkCjUcGsIVdGrLtGj0=; b=qPx2lZRG9kUMuXzXauZK2jredkSCSkBiHtH5MlJBT/DJZUdSUNm0lYuB0AhP0RAidAQvMF ePz8uBno6eCqqohyL8IawCIUd3IqCOSgAYWLAeE4ebOf7yK25XxgMzQ2f0r9rF2od2UIai DRZ6EMYPuY7nX4dU+Tc80CMlsgjIXUw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ikX4QxrO; spf=pass (imf12.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.45 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=1741033264; a=rsa-sha256; cv=none; b=3flSRtcbnaiL7n+vn2rLLDpiv5tPfEfdeUANvIsSs23BDc/+zr+rKxY3BX1uhHbGbBCu5+ J8FMujbXNPxovbcm9eZyNOZqw/fNs+woMY6vaEYdgHXKW9lXN7PLJoOnymNbc0DgDDHbnY Z3/O1exlgmy+L0pJBHw2zXkVs6WK9TI= Received: by mail-oo1-f45.google.com with SMTP id 006d021491bc7-60011e5ad81so58194eaf.0 for ; Mon, 03 Mar 2025 12:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1741033263; x=1741638063; 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=no1wNnrlYf60l/eQVo26WKDaWNkCjUcGsIVdGrLtGj0=; b=ikX4QxrOkt0bhD/1o4JMwg7YEciqWLzC0mFJiQ61kMZj/Cv1u8/mwSrzxG8ER/p3Rg 3eWLYY7hA4AE2fIvkFydMzDMRf2PlnxH65IjTRrU5BZ0bcCy6MxVuYdI3yFD6nLuBeMd E2QYJTN9ASQszrdqvtWNrPKNIywOx+qiAGCgg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741033263; x=1741638063; 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=no1wNnrlYf60l/eQVo26WKDaWNkCjUcGsIVdGrLtGj0=; b=tatYyiWLkgDsRPvLMX/FJilq7zENj3iMKszWQMMxAQn9CrwzbuaD46jNCdwmH81fyh OOUQxaLyXcj92EQmbZT4w0++uhsZl1GBJhKFnsKplBryFWtBJte4AXMe2t0v6HSPqZ7f 11JqpLKLbVRJAo2Rrs1Ewb1EIHecuyLpk4N82+7YgMnHMEuxNv94eAhbNKevJux5yhzU Pa80bUe0vuu44hj0/nUPEdKXVkMUOkWNORfHO2XMy2G9wuU8MRqEJxyteRBmRsykbeVZ rGPGDU2wnmvXbnklRpePdnMoaIH2psdJFrbpXu7KpaJEAi97dOg9pA5bszPbFT2RYW9H toWA== X-Forwarded-Encrypted: i=1; AJvYcCV/iyaWkGiwaSYjUNjR+yDN1eEm9shZqlqzpKmDHwSJ9W+Z75ByQbyXWG0QQFxJuG4z4tvXyC06ww==@kvack.org X-Gm-Message-State: AOJu0YwnBI1HVIFh+Rd80Tu1frgfuG0VYZOGW3XCsQfkloFhbStv5W6p EBbwqco9jdKB6sKSFBLCYIiVA0akxfr07pkLZI/lf3g1Xhsde6tnAHGVBR1ufL3I0U7rueBkHVd A2BPGKcCZi6fEQ5Ov6e5a6FsCAZzioGEbiIQH X-Gm-Gg: ASbGncs2P+xyikOj/2JOoezWF+ePMKt7AUBKQsEAKxFkr/uqWelsQjH8nzNJdetHHGq buzTlFVk/GaSHPTb/CgVGWTiZP/LyKLi5Rnut4MA9Jw/YYDxQTbyZxurePR49v7TLUSu7R5Ji5B 2bPgl+tKdCkDmX51m4j7HpEv/rVnUOqpRMpneiXnj8GRra710gmFdnowU= X-Google-Smtp-Source: AGHT+IEXfmyX2wHlJ2lbAx4n6yyJgXMnztKsNOPcFdztGEqA04VTuX/LC9mY3PQN9ceUAoP2o9Hzx/eI4jjE4s3OgTM= X-Received: by 2002:a05:6808:211d:b0:3f3:fbd8:402f with SMTP id 5614622812f47-3f558513ff2mr3027208b6e.3.1741033263013; Mon, 03 Mar 2025 12:21:03 -0800 (PST) MIME-Version: 1.0 References: <20250303050921.3033083-1-jeffxu@google.com> <20250303050921.3033083-8-jeffxu@google.com> <202503030848.30D0E54E7@keescook> In-Reply-To: <202503030848.30D0E54E7@keescook> From: Jeff Xu Date: Mon, 3 Mar 2025 12:20:51 -0800 X-Gm-Features: AQ5f1Jq5svbCVb3FqQP-Y_uMsz2QYtbH_Pm1ryvuu3brSFjJbdq9EGliYsj9Lxg Message-ID: Subject: Re: [PATCH v8 7/7] selftest: test system mappings are sealed. To: Kees Cook Cc: akpm@linux-foundation.org, jannh@google.com, torvalds@linux-foundation.org, vbabka@suse.cz, lorenzo.stoakes@oracle.com, Liam.Howlett@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, linux-kselftest@vger.kernel.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, Shuah Khan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: ar6jbwzcoyhhpfeu1yfk4ywr4ihir1sn X-Rspamd-Queue-Id: 8893A40013 X-Rspamd-Server: rspam07 X-HE-Tag: 1741033264-777248 X-HE-Meta: U2FsdGVkX1/8h9tBThOwDgqkWi8CDcbDZWq/mKdh5D7fQ1f7vCnjWtfJJXkzEkrvwHVSj47+ZbGS1qJNbBnnONasDDQUKkH2B3+V03nb/Xuqinp3wuhoZfwDxr0cbmPTk+M4WwOsW38UyqOGRRSqaK5ZfySu0lbN2PCWSpPvQfOVvlQvV+T041JIr6EG3UOdoJDwuoCIM4uOGp+h0b9NF4ptojmMyxn6H1Sts7v7ox8I6/xGQR/PKOpzselfGTbznrSJg4fAwZuwE1XyFuwpQCQVT29EdegUYU7dcN8M17M3Tf5VYXeE9eT3CNcTO9nsge/UjLNqNaW+2GzetdpMoBImGh/zRDvh7zCOoRtqiv5T945h+zmn2r0IvJzzZg+NP471KytdPWtAGE/MGbhwScXHTsE0xBBlMRB6qDui92gaEGJbCJzUclDcrOO9lfncKhvMOo3748dohu/wymEh46qrjrLVtF+f4TsepwNz2TFkEBjqNBUpgQwyAj42lld+VxLALai3T/MRvJ1Ceqdx1FtiU6G55EDZyDNVGw5TvYB+sCys4RXfy86beVt5C1EvXQc1ADvIOiUgcPV9OE927uYdlhIyzmk7ZLi4eCYef+bbjxjJU9c+3mxzAGjMMf8A8SztjaGzU1rvnTLWxYQcLwVXOr3GTnIQa4SFEivssTrZfX3+EulUO+W7XBtkz/SlHIFoogJHqg9h0TciR56pDIoTONxtK5gAH46GnP+gnAvXiOEtToCQhmf295pE1ugXRiqH1Gv2ajBkdWlJMQC7lilYQxQnZvaoL0yDH8qLt8/CryrjNGVdx5crL3mg0czJg/+niDttK4AIuJqx+maW6GaP1iXkHUcD6YOydUHTyAG1Z0IaW2gTnxa6iICL6pcHerXSmwcOH4du7HijXsXH/y4Wjm8y5KeMojvmwsldzDt+ZONx9uRF8017j2bpkyiKx8RMZgRv8PM+RG63dVb 5vAyNjTn AKppyL5LUMIDefnklzqTjr/XWkvKeV9lPRXOLKaPXJKMPuFgt64JgGvhGRBXGMCNlaUxvaQiug/j/cZqCB/8tC5zDiXYJG9cUS4o8U1wNitQnH1JFV/eGGsUzVzqA1G1/WbL86WX2ZY5H0sXC7hx4YKcY92GIlafS9XFAYZqlU5LLLV/3wItihYBfL8Uay18H7aT8lqwTlegOl+3b5JlnSDHNp/fcpJa9NirskcDfZKJnJ1IsyLl92YJ8PZvmZVhpOpCM7jhOKSmgaIXJv4if69jYjn0WYsmoooEBTdbz/VqL8Ewr1syaq3vJw1o3/CNcd9d9 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, Mar 3, 2025 at 9:01=E2=80=AFAM Kees Cook wrote: > > On Mon, Mar 03, 2025 at 05:09:21AM +0000, jeffxu@chromium.org wrote: > > From: Jeff Xu > > > > Add sysmap_is_sealed.c to test system mappings are sealed. > > > > Note: CONFIG_MSEAL_SYSTEM_MAPPINGS must be set, as indicated in > > config file. > > > > Signed-off-by: Jeff Xu > > --- > > .../mseal_system_mappings/.gitignore | 2 + > > .../selftests/mseal_system_mappings/Makefile | 6 + > > .../selftests/mseal_system_mappings/config | 1 + > > .../mseal_system_mappings/sysmap_is_sealed.c | 113 ++++++++++++++++++ > > 4 files changed, 122 insertions(+) > > create mode 100644 tools/testing/selftests/mseal_system_mappings/.giti= gnore > > create mode 100644 tools/testing/selftests/mseal_system_mappings/Makef= ile > > create mode 100644 tools/testing/selftests/mseal_system_mappings/confi= g > > create mode 100644 tools/testing/selftests/mseal_system_mappings/sysma= p_is_sealed.c > > > > diff --git a/tools/testing/selftests/mseal_system_mappings/.gitignore b= /tools/testing/selftests/mseal_system_mappings/.gitignore > > new file mode 100644 > > index 000000000000..319c497a595e > > --- /dev/null > > +++ b/tools/testing/selftests/mseal_system_mappings/.gitignore > > @@ -0,0 +1,2 @@ > > +# SPDX-License-Identifier: GPL-2.0-only > > +sysmap_is_sealed > > diff --git a/tools/testing/selftests/mseal_system_mappings/Makefile b/t= ools/testing/selftests/mseal_system_mappings/Makefile > > new file mode 100644 > > index 000000000000..2b4504e2f52f > > --- /dev/null > > +++ b/tools/testing/selftests/mseal_system_mappings/Makefile > > @@ -0,0 +1,6 @@ > > +# SPDX-License-Identifier: GPL-2.0-only > > +CFLAGS +=3D -std=3Dc99 -pthread -Wall $(KHDR_INCLUDES) > > + > > +TEST_GEN_PROGS :=3D sysmap_is_sealed > > + > > +include ../lib.mk > > diff --git a/tools/testing/selftests/mseal_system_mappings/config b/too= ls/testing/selftests/mseal_system_mappings/config > > new file mode 100644 > > index 000000000000..675cb9f37b86 > > --- /dev/null > > +++ b/tools/testing/selftests/mseal_system_mappings/config > > @@ -0,0 +1 @@ > > +CONFIG_MSEAL_SYSTEM_MAPPINGS=3Dy > > diff --git a/tools/testing/selftests/mseal_system_mappings/sysmap_is_se= aled.c b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c > > new file mode 100644 > > index 000000000000..c1e93794a58b > > --- /dev/null > > +++ b/tools/testing/selftests/mseal_system_mappings/sysmap_is_sealed.c > > @@ -0,0 +1,113 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * test system mappings are sealed when > > + * KCONFIG_MSEAL_SYSTEM_MAPPINGS=3Dy > > + */ > > + > > +#define _GNU_SOURCE > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include "../kselftest.h" > > +#include "../kselftest_harness.h" > > + > > +#define VDSO_NAME "[vdso]" > > +#define VVAR_NAME "[vvar]" > > +#define VVAR_VCLOCK_NAME "[vvar_vclock]" > > +#define UPROBES_NAME "[uprobes]" > > +#define SIGPAGE_NAME "[sigpage]" > > +#define VECTORS_NAME "[vectors]" > > These are only ever used once, and it feels like having them spelled out > right in the variant definitions would be more readable, but I'm not > sure I feel strongly enough about it to say it should be changed. > They're available via "variant->name" as well, which makes it unlikely > the macros will be used anywhere in the future? Maybe you have plans for > them. :) No plan for reuse them in other code, will move to Variant in v9. > > > +#define VMFLAGS "VmFlags:" > > This one gets a strlen() on it, so it feels better to have a macro. > Ok, thanks for the reasoning. > > +#define MSEAL_FLAGS "sl" > > +#define MAX_LINE_LEN 512 > > + > > +bool has_mapping(char *name, FILE *maps) > > +{ > > + char line[MAX_LINE_LEN]; > > + > > + while (fgets(line, sizeof(line), maps)) { > > + if (strstr(line, name)) > > + return true; > > + } > > + > > + return false; > > +} > > + > > +bool mapping_is_sealed(char *name, FILE *maps) > > +{ > > + char line[MAX_LINE_LEN]; > > + > > + while (fgets(line, sizeof(line), maps)) { > > + if (!strncmp(line, VMFLAGS, strlen(VMFLAGS))) { > > + if (strstr(line, MSEAL_FLAGS)) > > + return true; > > + > > + return false; > > + } > > + } > > + > > + return false; > > +} > > + > > +FIXTURE(basic) { > > + FILE *maps; > > +}; > > + > > +FIXTURE_SETUP(basic) > > +{ > > + self->maps =3D fopen("/proc/self/smaps", "r"); > > + if (!self->maps) > > + SKIP(return, "Could not open /proc/self/smap, errno=3D%d"= , > > + errno); > > Good SKIP usage, though I wonder if not having /proc should be a full > blown failure? > Usually, the failure is used to report failures directly related to what this code is testing. If /proc is unavailable, it's an environment setup issue, which is more fitting for SKIP, otherwise, we wouldn't need "SKIP" - we'd just report all environment requirements checked as failures. Unless you mean that "/proc" is always available and can never be unavailable in any selftest environment? Then, I can change to use the failure reporting. > > +}; > > + > > +FIXTURE_TEARDOWN(basic) > > +{ > > + if (self->maps) > > + fclose(self->maps); > > +}; > > + > > +FIXTURE_VARIANT(basic) > > +{ > > + char *name; > > +}; > > + > > +FIXTURE_VARIANT_ADD(basic, vdso) { > > + .name =3D VDSO_NAME, > > +}; > > + > > +FIXTURE_VARIANT_ADD(basic, vvar) { > > + .name =3D VVAR_NAME, > > +}; > > + > > +FIXTURE_VARIANT_ADD(basic, vvar_vclock) { > > + .name =3D VVAR_VCLOCK_NAME, > > +}; > > + > > +FIXTURE_VARIANT_ADD(basic, sigpage) { > > + .name =3D SIGPAGE_NAME, > > +}; > > + > > +FIXTURE_VARIANT_ADD(basic, vectors) { > > + .name =3D VECTORS_NAME, > > +}; > > + > > +FIXTURE_VARIANT_ADD(basic, uprobes) { > > + .name =3D UPROBES_NAME, > > +}; > > I love seeing variants used in the test harness. :) > Ya, copied from landlock selftest :-) > > + > > +TEST_F(basic, is_sealed) > > +{ > > + if (!has_mapping(variant->name, self->maps)) { > > + SKIP(return, "could not found the mapping, %s", > > typo nit: "find" instead of "found" > > > + variant->name); > > + } > > + > > + EXPECT_TRUE(mapping_is_sealed(variant->name, self->maps)); > > +}; > > This is a good "positive" test, but I'd like to see a negative test > added as well. (This adds robustness against something going "all wrong" > or "all right", like imagine that someone adds a VmFlags string named > "slow", suddenly this test will always pass due to matching "sl". With > a negative test added, it will fail when it finds "sl" when it's not > expected.) For example, also check "[stack]" and "[heap]" and expect > them NOT to be sealed. > > You could update the variant as: > > FIXTURE_VARIANT(basic) > { > char *name; > bool sealed; > }; > > FIXTURE_VARIANT_ADD(basic, vdso) { > .name =3D "[vdso]", > .sealed =3D true, > }; > > FIXTURE_VARIANT_ADD(basic, stack) { > .name =3D "[stack]", > .sealed =3D false, > }; > > And then update the is_sealed test to: > > EXPECT_EQ(variant->sealed, mapping_is_sealed(variant->name, self-= >maps)); > The challenge is that I'm unsure how to detect "CONFIG_MSEAL_SYSTEM_MAPPINGS" from selftest runtime. Without that, the test can't reliably set the "sealed" flag. Lorenzo suggested parsing /proc/config.gz, but I responded, "None of the existing selftests use this pattern, and I'm not sure /proc/config.gz is enabled in the default kernel config." [1]. To work around this, in this version, I add selftests/mseal_system_mappings/config to indicate CONFIG_MSEAL_SYSTEM_MAPPINGS=3Dy is a mandatory requirement for running this test. Therefore, this selftest assumes the ".sealed" is always true, i.e. no negative test. I'm looking to Linux Kernel Self-Test (LKST) and Shuah Khan for guidance/suggestion on handling different kernel config variants within selftest. Thanks -Jeff [1] https://lore.kernel.org/all/60f5b979-2969-4cb0-ad3d-262908869c5f@lucife= r.local/ > -- > Kees Cook