Message ID | 20241211053311.245636-1-jeffxu@google.com (mailing list archive) |
---|---|
Headers | show
Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90CF64C85 for <linux-hardening@vger.kernel.org>; Wed, 11 Dec 2024 05:33:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733895195; cv=none; b=nVVsRjG12/IRTSG6eTPpMYInr0qUyOvSW5vROVb+6wLG+CGmlsr4X2a6nr1EwX4KtbG2XR+3l/barDND2QQmfOZ+caSQKvUlNxFz9gcr4hXrKdKhvgnLGRKQOu3q2lArHNpYA6y4BaYdBbEujfwY28OxNI87K64O7QW+oV6EDLw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733895195; c=relaxed/simple; bh=h7gVITOrQkSkReYxOXpU0/sJiaPzKJ50gjtWWld/7oQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=ZXde4/DJ8RKLfei0yAEd5j7JaVIPDYV3S2xoSI28Gz1lp+43X2XE72fi5oqMVWQep0eQJFYLrepAW5LdR1YBszxitxB3Z/VoQIqm/mcx0VFzqg5QRz76gS8p4yARzNawkCrOvQ5HWG3o7TGBogax9eG6EZt173b/CezwUmaYAZw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=SlFjRhxd; arc=none smtp.client-ip=209.85.216.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="SlFjRhxd" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-2ee9b1a2116so719075a91.3 for <linux-hardening@vger.kernel.org>; Tue, 10 Dec 2024 21:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1733895193; x=1734499993; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=TcPnvSnitIZYgE4SSPh1sjaLPoyZLCmck1DlGFSmRwU=; b=SlFjRhxdHb57OIm1Xj5HroO/7zQ88RGhxOTrr7V3TThkWDUecrPhV8s3mPSxlHGipX 3hZrerj+sgz3wuvt3LkYy7t4kds3cEM6RgRoRasfXegQssvZkCat0Pf1Vbn6pbg1n2Jo pHR5dKjZ1f1l3R8I0zRYnl1dJ3dAn5o9Aif3o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733895193; x=1734499993; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TcPnvSnitIZYgE4SSPh1sjaLPoyZLCmck1DlGFSmRwU=; b=BpxnZMSzx5TN/mC4/UwjhAwF5n20Gz6qP00L3X4+VBt3WJ0dBP1VIjzdG4tfQic+kE kgKZ78zLVhMzRh+3uim3wTxP55sMObeldItk61F6VYZSyHd8NxJGTOsoHfsSGJ5dB29T XCk1flzDsWQXE0T0zPJ0YuvLid0TjcgihZ6CGM+VkBSIKDNHT1frn0MRO3uWmyaFVlzC oJTklmDritldAR91I2ferKfbMe90FLV2yNGdAAG9Gb4a5HowurI02/i7Sw6WwG6ziuln Nquj7Q3pe6fl7GsCFQjownugyw3iOu1txy7iVCmQAdCl8GuRjxb2yh/Eapf9SxS6VI7s /b6w== X-Forwarded-Encrypted: i=1; AJvYcCWcqfnmXNabKma+OlKN/HnlgJ4R/8kCx+QztmUBb73VPS5DRv+w8UlSBueNve+jmcmnEHeC8f/9h1kd2IdaXGQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzTpCD37midodwwEtpXuENoeUe/vGkEKjOPMVONB6xfLBqefko5 FOvLpx1yDc9VgK7PHaUXGpe0GtuDIxvboX6X662VGCFqsafyY/oKqvRTfb0yBg== X-Gm-Gg: ASbGncvYSVVm9Juzy9pjlt4Cdr05R+L9lmCOn+SsZn+ZGQInoh/X4af1GW8YzSHPZ1Z ZuJBXsZaWi/gwv5kOetQEmW5q3SD/8Lo4KjCzG6UDyJfs6skduL+rjm/nSasi5n3CaHVpX7nS5I o6w1kqrqj/GDDQrUrJJbP+2m6VmD9PS9J+dBni8KibXPhVf79eX4gIK5g6x0/Nmvx7N/dnoJp18 YrnBhjIq3dBPPQRJAuyTd2r+hEQO27qEDjFBTQDCpu1u4UVAvD43dFWWldBUnnp8U2/aTUC9ALe c8WKm5tWMlQ6XHg= X-Google-Smtp-Source: AGHT+IFhn0Xr1EvCCo7gWlc9e87/kYfh8vrGg7FJA2vVTx9fVRgwJXmWhxS6Xfg8pWi6I36Ea52j1A== X-Received: by 2002:a17:90b:33cd:b0:2ee:6db1:21dc with SMTP id 98e67ed59e1d1-2f127f8dec6mr980737a91.1.1733895192980; Tue, 10 Dec 2024 21:33:12 -0800 (PST) Received: from localhost (238.76.127.34.bc.googleusercontent.com. [34.127.76.238]) by smtp.gmail.com with UTF8SMTPSA id 98e67ed59e1d1-2ef4600d109sm10721682a91.44.2024.12.10.21.33.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Dec 2024 21:33:12 -0800 (PST) From: jeffxu@chromium.org To: akpm@linux-foundation.org, vbabka@suse.cz, lorenzo.stoakes@oracle.com, Liam.Howlett@Oracle.com, broonie@kernel.org, skhan@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, keescook@chromium.org, pedro.falcato@gmail.com, rdunlap@infradead.org, jannh@google.com, Jeff Xu <jeffxu@chromium.org> Subject: [RFC PATCH v1 0/1] refactor mseal_test Date: Wed, 11 Dec 2024 05:33:10 +0000 Message-ID: <20241211053311.245636-1-jeffxu@google.com> X-Mailer: git-send-email 2.47.1.613.gc27f4b7a9f-goog Precedence: bulk X-Mailing-List: linux-hardening@vger.kernel.org List-Id: <linux-hardening.vger.kernel.org> List-Subscribe: <mailto:linux-hardening+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-hardening+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit |
Series |
refactor mseal_test
|
expand
|
From: Jeff Xu <jeffxu@chromium.org> This change creates the initial version of memorysealing.c. The introduction of memorysealing.c, which replaces mseal_test.c and uses the kselftest_harness, aims to initiate a discussion on using the selftest harness for memory sealing tests. Upon approval of this approach, the migration of tests from mseal_test.c to memorysealing.c can be implemented in a step-by-step manner. This tests addresses following feedbacks from previous reviews: 1> Use kselftest_harness instead of custom macro, such as EXPECT_XX, ASSERT_XX, etc. (Lorenzo Stoakes, Mark Brown, etc) [1] 2> Use MAP_FAILED to check the return of mmap (Lorenzo Stoakes). 3> Adding a check for vma size and prot bits. The discussion for this can be found in [2] [3], here is a brief summary: This is to follow up on Pedro’s in-loop change (from can_modify_mm to can_modify_vma). When mseal_test is initially created, they have a common pattern: setup memory layout, seal the memory, perform a few mm-api steps, verify return code (not zero). Because of the nature of out-of-loop, it is sufficient to just verify the error code in a few cases. With Pedro's in-loop change, the sealing check happens later in the stack, thus there are more things and scenarios to verify. And there were feedbacks to me that mseal_test should be extensive enough to discover all regressions. Hence I'm adding check for vma size and prot bits. In this change: we created two fixtures: Fixture basic: This creates a single VMA, the VMA has a PROT_NONE page at each end to prevent auto-merging. Fixture wo_vma: Two VMAs back to end, a PROT_NONE page at each end to prevent auto-merging. In addition, I add one test (mprotec) in each fixture for discussion. [1] https://lore.kernel.org/all/20240830180237.1220027-5-jeffxu@chromium.org/ [2] https://lore.kernel.org/all/CABi2SkUgDZtJtRJe+J9UNdtZn=EQzZcbMB685P=1rR7DUhg=6Q@mail.gmail.com/ [3] https://lore.kernel.org/all/2qywbjb5ebtgwkh354w3lj3vhaothvubjokxq5fhyri5jeeton@duqngzo3swjz/ Jeff Xu (1): selftest/mm: refactor mseal_test tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + tools/testing/selftests/mm/memorysealing.c | 182 +++++++++++++++++++++ tools/testing/selftests/mm/memorysealing.h | 116 +++++++++++++ tools/testing/selftests/mm/mseal_test.c | 67 +------- 5 files changed, 301 insertions(+), 66 deletions(-) create mode 100644 tools/testing/selftests/mm/memorysealing.c create mode 100644 tools/testing/selftests/mm/memorysealing.h