linux-kernel - [PATCH 0/2] arch/nios2: Address spurious page faults

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: 
 <fm-32642-2025032713472338dcdd83140019fd15-kduNDQ@errorhandling.siemens-energy.com>
Date: Thu, 27 Mar 2025 14:47:21 +0100
From: Simon Schuster <schuster.simon@...mens-energy.com>
To: Dinh Nguyen <dinguyen@...nel.org>, Arnd Bergmann <arnd@...db.de>
Cc: Andreas Oetken <andreas.oetken@...mens-energy.com>,
	Mike Rapoport <rppt@...nel.org>, Song Liu <song@...nel.org>,
	linux-kernel@...r.kernel.org,
	Simon Schuster <schuster.simon@...mens-energy.com>
Subject: [PATCH 0/2] arch/nios2: Address spurious page faults

On nios2, we have observed instances where a single process can get
stuck in an infinite loop of repeated page faults for a single address.

To invalidate an existing mapping, nios2 replaces the TLB entry for the
virtual address with an invalid dummy (mmu pid 0, physical address 0x0,
all permissions set to invalid).
However, this may conflict with actual, existing mappings for that
virtual address within the address space associated with mmu pid 0,
which will then repeatedly fault until the conflicting entry is
preempted from TLB.

The issue is partially masked by sufficient paging activity in the
system which eventually replaces one of the conflicting entries with a
valid mapping for a different mmu pid. Yet, in the case of low paging
activity (e.g., during early boot), this does not happen reliably,
causing the process to hang.

The commits in this series address this issue in two ways:
- By ensuring that TLB entries are updated from their corresponding
  page-table entry on TLB permission violations as these can be caused
  by an invalidation/dummy entry (PATCH 1/2)

- By not introducing duplicate TLB entries for mmu pid 0. Instead,
  invalidation maintains mmu pid because the pair <mmu pid, virtual
  address> is unique in the current TLB state (PATCH 2/2)

Please see the commit messages in the individual patches for details.

The patches were tested to successfully boot on nios2 hardware on top of
linux-next commit eb4bc4b07f66.

Simon Schuster (2):
  nios2: force update_mmu_cache on spurious tlb-permission--related
    pagefaults
  nios2: do not introduce conflicting mappings when flushing tlb entries

 arch/nios2/include/asm/pgtable.h | 16 ++++++++++++++++
 arch/nios2/mm/tlb.c              | 18 +++++++++++-------
 2 files changed, 27 insertions(+), 7 deletions(-)

-- 
2.39.5