linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH v1 0/1] refactor mseal_test
@ 2024-12-11  5:33 jeffxu
  2024-12-11  5:33 ` [RFC PATCH v1 1/1] selftest/mm: " jeffxu
  0 siblings, 1 reply; 6+ messages in thread
From: jeffxu @ 2024-12-11  5:33 UTC (permalink / raw)
  To: akpm, vbabka, lorenzo.stoakes, Liam.Howlett, broonie, skhan
  Cc: linux-kernel, linux-hardening, linux-kselftest, linux-mm,
	jorgelo, keescook, pedro.falcato, rdunlap, jannh, Jeff Xu

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

-- 
2.47.1.613.gc27f4b7a9f-goog



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2025-02-11 10:59 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-12-11  5:33 [RFC PATCH v1 0/1] refactor mseal_test jeffxu
2024-12-11  5:33 ` [RFC PATCH v1 1/1] selftest/mm: " jeffxu
2025-01-02 17:30   ` Lorenzo Stoakes
2025-01-15 20:47     ` Jeff Xu
2025-02-10 21:35       ` Jeff Xu
2025-02-11 10:58         ` Lorenzo Stoakes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox