linux-kernel - [PATCH RFC 0/3] add support for mm-local memory allocations

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>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240621201501.1059948-1-rkagan@amazon.de>
Date: Fri, 21 Jun 2024 22:14:58 +0200
From: Roman Kagan <rkagan@...zon.de>
To: <linux-kernel@...r.kernel.org>
CC: Shuah Khan <shuah@...nel.org>, Dragan Cvetic <dragan.cvetic@....com>,
	Fares Mehanna <faresx@...zon.de>, Alexander Graf <graf@...zon.de>, "Derek
 Kiernan" <derek.kiernan@....com>, <linux-kselftest@...r.kernel.org>,
	<nh-open-source@...zon.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<linux-mm@...ck.org>, David Woodhouse <dwmw@...zon.co.uk>, Andrew Morton
	<akpm@...ux-foundation.org>, Arnd Bergmann <arnd@...db.de>
Subject: [PATCH RFC 0/3] add support for mm-local memory allocations

In a series posted a few years ago [1], a proposal was put forward to allow the
kernel to allocate memory local to a mm and thus push it out of reach for
current and future speculation-based cross-process attacks.  We still believe
this is a nice thing to have.

However, in the time passed since that post Linux mm has grown quite a few new
goodies, so we'd like to explore possibilities to implement this functionality
with less effort and churn leveraging the now available facilities.

Specifically, this is a proof-of-concept attempt to implement mm-local
allocations piggy-backing on memfd_secret(), using regular user addressess but
pinning the pages and flipping the user/supervisor flag on the respective PTEs
to make them directly accessible from kernel, and sealing the VMA to prevent
userland from taking over the address range.  The approach allowed to delegate
all the heavy lifting -- address management, interactions with the direct map,
cleanup on mm teardown -- to the existing infrastructure, and required zero
architecture-specific code.

Compared to the approach used in the orignal series, where a dedicated kernel
address range and thus a dedicated PGD was used for mm-local allocations, the
one proposed here may have certain drawbacks, in particular

- using user addresses for kernel memory may violate assumptions in various
  parts of kernel code which we may not have identified with smoke tests we did

- the allocated addresses are guessable by the userland (ATM they are even
  visible in /proc/PID/maps but that's fixable) which may weaken the security
  posture

Also included is a simple test driver and selftest to smoke test and showcase
the feature.

The code is PoC RFC and lacks a lot of checks and special case handling, but
demonstrates the idea.  We'd appreciate any feedback on whether it's a viable
approach or it should better be abandoned in favor of the one with dedicated
PGD / kernel address range or yet something else.

[1] https://lore.kernel.org/lkml/20190612170834.14855-1-mhillenb@amazon.de/

Fares Mehanna (2):
  mseal: expose interface to seal / unseal user memory ranges
  mm/secretmem: implement mm-local kernel allocations

Roman Kagan (1):
  drivers/misc: add test driver and selftest for proclocal allocator

 drivers/misc/Makefile                         |   1 +
 tools/testing/selftests/proclocal/Makefile    |   6 +
 include/linux/secretmem.h                     |   8 +
 mm/internal.h                                 |   7 +
 drivers/misc/proclocal-test.c                 | 200 +++++++++++++++++
 mm/gup.c                                      |   4 +-
 mm/mseal.c                                    |  81 ++++---
 mm/secretmem.c                                | 208 ++++++++++++++++++
 .../selftests/proclocal/proclocal-test.c      | 150 +++++++++++++
 drivers/misc/Kconfig                          |  15 ++
 tools/testing/selftests/proclocal/.gitignore  |   1 +
 11 files changed, 649 insertions(+), 32 deletions(-)
 create mode 100644 tools/testing/selftests/proclocal/Makefile
 create mode 100644 drivers/misc/proclocal-test.c
 create mode 100644 tools/testing/selftests/proclocal/proclocal-test.c
 create mode 100644 tools/testing/selftests/proclocal/.gitignore

-- 
2.34.1

Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597