From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=74.125.82.198 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793161821; b=ZURTBCTmVZjQr7XBxnogI+fW9cNvjBXNb4c85b29QhQ0AIAeMl7hQoKoxGytRfKpwqiY dubSGGiSQeQQt1Z504zQT0fzJ4tw/xoEprgh0vQRe9L2z9eNoXaOpa5Mr3d1yK2EP/TJp B4hJKUTYlzHROCufNL9UhgL0t369q+gBTUvYdjQCp6IOr/hJ9nUhK4/I5UWP15Ct5EkDy /bR4BHrzMN/AeQqXv9Lb+ITBfC7RGXIkmoSJ/zTUyZn4QPvAlvKGQkRSUh0NSeT3hvPEc Ozv5foL2eIkqOE4jZPkjAtksyOtLEYjJhxQcFRlr3wxqD7Va8Zk0B/yGImACYm0QHMQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793161821; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:MIME-Version:X-Received: In-Reply-To:References:Message-ID:Date:Subject:From:To:Cc: Content-Type; bh=kPQx6GgboXmcUMcY5/lzKrJ0ssCkME3FTMDmy2U7T6k=; b=wAk81ynPGdBOOOxo6e5Q76dCkA7T+Ye+K1J7aY79fuRWvxVUcBhpqC3G4zf49emkDumO kIMNo/5EQPpjLK0W2AJlZf1L3WOIuH+yAy3zQN0K9s6okBJbsNlxgxnp3XUJYdL9k0GF5 2EA1GcJsU5GQ/gIFgTrhkACbgfmJV8eFVq553MHMeFMHQNctQjN7KV0HOT38ZdmOcFN7u sxY9vPVMimzRZ3fxYQVygq4l+6G6rvIylLt8A/XbAFDZTj7mSprJJ3BnJX5i9TslaRvpx ToLQ8RMwn6QOy4h2JHuOI4Tyiud7WGyqdaEt0swt6QkZA91Hc9tsI1M9GCqOMSoEygA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=google.com; spf=pass smtp.mailfrom=flex--jeffxu.bounces.google.com; dkim=pass header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20260707 header.b=PCQLkeFq; arc=none smtp.remote-ip=74.125.82.198 Received: from mail-dy1-f198.google.com (mail-dy1-f198.google.com [74.125.82.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67205606A31E for ; Wed, 28 Oct 2026 04:30:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 67205606A31E Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jeffxu.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20260707 header.b=PCQLkeFq Received: by mail-dy1-f198.google.com with SMTP id 5a478bee46e88-33c35f5ca6cso1038565eec.1 for ; Tue, 27 Oct 2026 21:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20260707; t=1793161820; x=1793766620; darn=vger.kernel.org; h=content-type:cc:to:from:subject:date:message-id:references :in-reply-to:mime-version:from:to:cc:subject:date:message-id :reply-to:content-type; bh=kPQx6GgboXmcUMcY5/lzKrJ0ssCkME3FTMDmy2U7T6k=; b=PCQLkeFqYzzEc1UNxxO2SwDWNuvwXCTIhjbkdQznKqU2g4DjFA/FXyxGRex5YcdsnA Xgf5iy01BQ8rOnqrN6NVQPlizUrqHh2RZ6ivs+Oyj1MA9ZP9SL6SV4smhPoQSISGLof3 bfkA1nptW6pC7C2owKdZR1L+bpDE/sb4uN3KYnQm7kyN18GNyXQlDYxEK1+9gaL4vYUd pnpf58X96pUnGR5kaD/ulKDbAv6Bam86N4YfddjhLeLkpwI9XD/lIKOBIC8VmpxhlctP WGbuwl9Y9WOJy3woSOwZZW3I37lEy/0CEbwuA8XqraBjnRplspQ8Og0S/bGriiZtuOI9 k43A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793161820; x=1793766620; h=content-type:cc:to:from:subject:date:message-id:references :in-reply-to:mime-version:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=kPQx6GgboXmcUMcY5/lzKrJ0ssCkME3FTMDmy2U7T6k=; b=2muepU/gl0SaNq3ZOWMltt37zIYDMEBw2pih0OHaZPEIIvfu1/2HYpumtPx8OmtoWp oj5Es4+vZ6hBL/Nv652BEas7CKZ1Rvra3vDu4X0fQaqFHB7bffU8tgBzeSvFHcRY8utM 2oObcJCsyGnyJOiQoXm6WlR6VnA3pOUM240l+79/WOfwAe82CPafVtGKG6QK/Si919Jb fEGxP0gIVN/efDXQxYM0rzPDzgWWbeOQdHCRlBGI9qMoCHPxDnMHP1c9isr7bnx09Kzq PH3zAwcKnPXtIpe9m8ItQ0rEEcAPbtenWoSfNNpjSsfGJp6F/53yoEghJCYJu536f1oa RR4w== X-Forwarded-Encrypted: i=1; AKwUvBxkUc5Qt4HukpV3Ba1t1w2AWLkzfNJRHWYBTtv3DtGZZAA46/vI3ZSLC0vY2fAtZQU6REAf31YV5LzriAA=@vger.kernel.org X-Gm-Message-State: AFq9FYK1HpnAtjStjlZ05v69xAWV6mRQ1IfSmT/+hK/JbmpoNWCvHvZn arU+XFI3vyDNMeLi7OjchYVDmHpxrf3buId5RbLDvhRgwusygypG14muYfueb/jb5OLXwjPgc27 k7Asf5Q== X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 X-Received: from dyaz12-n2.prod.google.com ([2002:a05:693c:638c:20b0:369:fbca:f640]) (user=jeffxu job=prod-delivery.src-stubby-dispatcher) by 2002:a05:693c:250d:b0:369:f5f6:36a7 with SMTP id 5a478bee46e88-36a2014b887mr2079336eec.16.1793161819981; Tue, 27 Oct 2026 21:30:19 -0700 (PDT) In-Reply-To: References: <5bd3c89d733ad22224f296dfa8900769de937de0.1793094611.git.chris@chrisdown.name> Message-ID: <18e2972cb8520c2e.3137322e32382e342e3434.279dd1.0000sendgmr@google.com> Date: Wed, 28 Oct 2026 04:30:20 +0000 Subject: Re: [PATCH 1/3] mseal sysmap: Add mseal_system_mappings= boot parameter From: Jeff Xu To: "Lorenzo Stoakes (ARM)" , Chris Down Cc: Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Jann Horn , Pedro Falcato , David Hildenbrand , Kees Cook , Jeff Xu , Jeff Xu , Andrey Vagin , Alexander Mikhalitsyn , Paul Moore , James Morris , "Serge E. Hallyn" , Shuah Khan , Jonathan Corbet , linux-mm@kvack.org, linux-hardening@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Hi Chris, Lorenzo, On Tue, Oct 27, 2026 at 04:57:04PM +0000, Lorenzo Stoakes (ARM) wrote: > > One option is to skip if [vdso] isn't sealed, and otherwise expect > > all system mappings to be sealed. Then there's parsing at all, and it > > also stops failing on kernels built without > > CONFIG_MSEAL_SYSTEM_MAPPINGS, which matters more once it's in > > run_vmtests.sh. The downside is that it can't notice sealing being > > broken entirely. > > > > Another is to check /proc/cmdline for no_mseal_sys_mappings and > > expect the mappings to be unsealed if it's there. That's only a few > > lines now, but the test still fails on kernels without the option, as > > it does today. > > > > Do you have a preference between the two? > Yeah it's awkward, really moving the tests to mm we'd have to skip them > if the vdso isn't sealed, then assume a sealed vdso for a new process = > feature enabled. > I guess at that point it's redundant to check if disabled? Thanks for working on this series! Could we please keep the test coverage for the unsealed [vdso] case and avoid unconditionally skipping whenever [vdso] is unsealed? There are two regressions I'd love for us to still be able to catch: 1. Kernel or config regressions when sealing is expected to be on: Distros/platforms such as ChromeOS and Android enable CONFIG_MSEAL_SYSTEM_MAPPINGS=y. Originally this test lived in its own selftest directory with `CONFIG_MSEAL_SYSTEM_MAPPINGS=y` in its `config` fragment specifically so that if a kernel change accidentally broke system mapping sealing completely, [vdso] being unsealed would trigger a hard FAIL rather than silently turning into a SKIP in CI (whereas `run_vmtests.sh` runs on kernels with `MSEAL_SYSTEM_MAPPINGS=n`). 2. Regressions in the new `no_mseal_sys_mappings` boot parameter itself: When booted with `no_mseal_sys_mappings` (or when unsealed), running the assertions in Patch 3 (verifying system mappings have no `sl` flag and that `munmap()` / `mremap()` -- and ideally `mprotect(PROT_READ | PROT_WRITE)` -- on [vdso] succeed) directly verifies that the boot parameter works and doesn't regress. If we move the test into `tools/testing/selftests/mm/`, perhaps we could: - Check `/proc/cmdline` for `no_mseal_sys_mappings` and actively test the unsealed behavior when it is set (rather than skipping), and - Either enable `CONFIG_MSEAL_SYSTEM_MAPPINGS=y` in `selftests/mm/config`, or keep strict failure as an option (e.g. `./sysmap_is_sealed` fails if unsealed without the boot param, while `run_vmtests.sh` passes a flag like `--allow-disabled` when `CONFIG_MSEAL_SYSTEM_MAPPINGS` may not be enabled), so CI environments that expect sealing still catch a broken seal. Thanks, Jeff