From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: pasha.tatashin@soleen.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-doc@vger.kernel.org,
akpm@linux-foundation.org, rientjes@google.com, pjt@google.com,
weixugc@google.com, gthelen@google.com, mingo@redhat.com,
corbet@lwn.net, will@kernel.org, rppt@kernel.org,
keescook@chromium.org, tglx@linutronix.de, peterz@infradead.org,
masahiroy@kernel.org, samitolvanen@google.com,
dave.hansen@linux.intel.com, x86@kernel.org, frederic@kernel.org,
hpa@zytor.com, aneesh.kumar@linux.ibm.com, jirislaby@kernel.org,
songmuchun@bytedance.com, qydwhotmail@gmail.com
Subject: [PATCH v2 0/4] page table check
Date: Sat, 4 Dec 2021 18:23:10 +0000 [thread overview]
Message-ID: <20211204182314.1470076-1-pasha.tatashin@soleen.com> (raw)
Changelog:
v2:
- Fixed bug reported by Fushan Wen
The root cause was that in do_swap_page() we first add page table entry
and only later change its type to anon.
- Added EXPORT_SYMBOL() to functions which are called from set_pte_* type
functions.
- Replaced DEFINE_STATIC_KEY_TRUE_RO with DEFINE_STATIC_KEY_TRUE to fix
issue with module load/unload as reported and root caused by Jiri Slaby
v1:
- Added ptep_clear() to mm/debug_vm_pgtable.c (thanks Anshuman Khandual)
- Addressed documentation comments from Jonathan Corbet.
Ensure that some memory corruptions are prevented by checking at the
time of insertion of entries into user page tables that there is no
illegal sharing.
We have recently found a problem [1] that existed in kernel since 4.14.
The problem was caused by broken page ref count and led to memory
leaking from one process into another. The problem was accidentally
detected by studying a dump of one process and noticing that one page
contains memory that should not belong to this process.
There are some other page->_refcount related problems that were recently
fixed: [2], [3] which potentially could also lead to illegal sharing.
In addition to hardening refcount [4] itself, this work is an attempt to
prevent this class of memory corruption issues.
It uses a simple state machine that is independent from regular MM logic
to check for illegal sharing at time pages are inserted and removed
from page tables.
[1] https://lore.kernel.org/all/xr9335nxwc5y.fsf@gthelen2.svl.corp.google.com
[2] https://lore.kernel.org/all/1582661774-30925-2-git-send-email-akaher@vmware.com
[3] https://lore.kernel.org/all/20210622021423.154662-3-mike.kravetz@oracle.com
[4] https://lore.kernel.org/all/20211026173822.502506-1-pasha.tatashin@soleen.com
Previous versions:
v1: https://lore.kernel.org/all/20211123214814.3756047-1-pasha.tatashin@soleen.com/
RFC: https://lore.kernel.org/all/20211116220038.116484-1-pasha.tatashin@soleen.com
Pasha Tatashin (4):
mm: change page type prior to adding page table entry
mm: ptep_clear() page table helper
mm: page table check
x86: mm: add x86_64 support for page table check
Documentation/vm/arch_pgtable_helpers.rst | 6 +-
Documentation/vm/index.rst | 1 +
Documentation/vm/page_table_check.rst | 56 +++++
MAINTAINERS | 9 +
arch/Kconfig | 3 +
arch/x86/Kconfig | 1 +
arch/x86/include/asm/pgtable.h | 29 ++-
include/linux/page_table_check.h | 147 ++++++++++++
include/linux/pgtable.h | 8 +
mm/Kconfig.debug | 24 ++
mm/Makefile | 1 +
mm/debug_vm_pgtable.c | 2 +-
mm/khugepaged.c | 12 +-
mm/memory.c | 7 +-
mm/page_alloc.c | 4 +
mm/page_ext.c | 4 +
mm/page_table_check.c | 270 ++++++++++++++++++++++
17 files changed, 566 insertions(+), 18 deletions(-)
create mode 100644 Documentation/vm/page_table_check.rst
create mode 100644 include/linux/page_table_check.h
create mode 100644 mm/page_table_check.c
--
2.34.1.400.ga245620fadb-goog
next reply other threads:[~2021-12-04 18:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-04 18:23 Pasha Tatashin [this message]
2021-12-04 18:23 ` [PATCH v2 1/4] mm: change page type prior to adding page table entry Pasha Tatashin
2021-12-04 18:23 ` [PATCH v2 2/4] mm: ptep_clear() page table helper Pasha Tatashin
2021-12-04 18:23 ` [PATCH v2 3/4] mm: page table check Pasha Tatashin
2021-12-08 0:05 ` Andrew Morton
2021-12-08 17:35 ` Pasha Tatashin
2021-12-04 18:23 ` [PATCH v2 4/4] x86: mm: add x86_64 support for " Pasha Tatashin
2021-12-21 13:09 ` [PATCH v2 0/4] " Fusion Future
2021-12-21 14:48 ` Pasha Tatashin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211204182314.1470076-1-pasha.tatashin@soleen.com \
--to=pasha.tatashin@soleen.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=frederic@kernel.org \
--cc=gthelen@google.com \
--cc=hpa@zytor.com \
--cc=jirislaby@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=masahiroy@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=qydwhotmail@gmail.com \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=samitolvanen@google.com \
--cc=songmuchun@bytedance.com \
--cc=tglx@linutronix.de \
--cc=weixugc@google.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.