mbox series

[v1,0/2] mseal: fixing madvise for file-backed mapping and PROT_NONE

Message ID 20241017005105.3047458-1-jeffxu@chromium.org
Headers show
Series mseal: fixing madvise for file-backed mapping and PROT_NONE | expand

Message

Jeff Xu Oct. 17, 2024, 12:51 a.m. UTC 
From: Jeff Xu <jeffxu@google.com>

Two fixes for madvise(MADV_DONTNEED) when sealed.

For PROT_NONE mappings, the previous blocking of
madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
memory access, madvise(MADV_DONTNEED) should be allowed to proceed in
order to free the page.

For file-backed, private, read-only memory mappings, we previously did
not block the madvise(MADV_DONTNEED). This was based on
the assumption that the memory's content, being file-backed, could be
retrieved from the file if accessed again. However, this assumption
failed to consider scenarios where a mapping is initially created as
read-write, modified, and subsequently changed to read-only. The newly
introduced VM_WASWRITE flag addresses this oversight.

Jeff Xu (2):
  mseal: Two fixes for madvise(MADV_DONTNEED) when sealed
  selftest/mseal: Add tests for madvise

 include/linux/mm.h                      |   2 +
 mm/mprotect.c                           |   3 +
 mm/mseal.c                              |  42 +++++++--
 tools/testing/selftests/mm/mseal_test.c | 118 +++++++++++++++++++++++-
 4 files changed, 157 insertions(+), 8 deletions(-)