linux-kernel - Re: [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-prev] [day] [month] [year] [list]

Message-ID: <f2d6e44c-585f-460c-9d68-0be4d5fbe9fd@amazon.com>
Date: Wed, 28 Aug 2024 11:50:08 +0200
From: Alexander Graf <graf@...zon.com>
To: Roman Kagan <rkagan@...zon.de>, <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: Re: [PATCH RFC 0/3] add support for mm-local memory allocations

Hey Roman,

On 21.06.24 22:14, Roman Kagan wrote:
> 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/


I haven't seen any negative feedback on the RFC, so when can I expect a 
v1 of this patch set that addresses the non-production-readyness of it 
that you call out above? :)


Alex




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