linux-kernel - Re: [RFC PATCH 0/7] support for mm-local memory allocations and use it

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: <23d90b50-f087-4daa-b4bc-4da406160c9d@amazon.com>
Date: Fri, 20 Sep 2024 15:19:32 +0200
From: Alexander Graf <graf@...zon.com>
To: Fares Mehanna <faresx@...zon.de>
CC: <nh-open-source@...zon.com>, Marc Zyngier <maz@...nel.org>, Oliver Upton
	<oliver.upton@...ux.dev>, James Morse <james.morse@....com>, Suzuki K Poulose
	<suzuki.poulose@....com>, Zenghui Yu <yuzenghui@...wei.com>, Catalin Marinas
	<catalin.marinas@....com>, Will Deacon <will@...nel.org>, Andrew Morton
	<akpm@...ux-foundation.org>, Kemeng Shi <shikemeng@...weicloud.com>,
	Pierre-Clément Tosi <ptosi@...gle.com>, Ard Biesheuvel
	<ardb@...nel.org>, Mark Rutland <mark.rutland@....com>, "Javier Martinez
 Canillas" <javierm@...hat.com>, Arnd Bergmann <arnd@...db.de>, Fuad Tabba
	<tabba@...gle.com>, Mark Brown <broonie@...nel.org>, Joey Gouly
	<joey.gouly@....com>, Kristina Martsenko <kristina.martsenko@....com>, "Randy
 Dunlap" <rdunlap@...radead.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	Jean-Philippe Brucker <jean-philippe@...aro.org>, "Mike Rapoport (IBM)"
	<rppt@...nel.org>, David Hildenbrand <david@...hat.com>, Roman Kagan
	<rkagan@...zon.de>, "moderated list:KERNEL VIRTUAL MACHINE FOR ARM64
 (KVM/arm64)" <linux-arm-kernel@...ts.infradead.org>, "open list:KERNEL
 VIRTUAL MACHINE FOR ARM64 (KVM/arm64)" <kvmarm@...ts.linux.dev>, open list
	<linux-kernel@...r.kernel.org>, "open list:MEMORY MANAGEMENT"
	<linux-mm@...ck.org>, <mark.rutland@....com>, Mike Rapoport
	<mikerapoport@...rosoft.com>
Subject: Re: [RFC PATCH 0/7] support for mm-local memory allocations and use
 it

On 11.09.24 16:33, Fares Mehanna 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.
>
> An RFC was posted few months back [2] to show the proof of concept and a simple
> test driver.
>
> In this RFC, we're using the same approach of implementing mm-local allocations
> piggy-backing on memfd_secret(), using regular user addresses but pinning the
> pages and flipping the user/supervisor flag on the respective PTEs to make them
> directly accessible from kernel.
> In addition to that we are submitting 5 patches to use the secret memory to hide
> the vCPU gp-regs and fp-regs on arm64 VHE systems.
>
> The generic drawbacks of using user virtual addresses mentioned in the previous
> RFC [2] still hold, in addition to a more specific one:
>
> - While the user virtual addresses allocated for kernel secret memory are not
>    directly accessible by userspace as the PTEs restrict that, copy_from_user()
>    and copy_to_user() can operate on those ranges, so that e.g. the usermode can
>    guess the address and pass it as the target buffer for read(), making the
>    kernel overwrite it with the user-controlled content. Effectively making the
>    secret memory in the current implementation missing confidentiality and
>    integrity guarantees.
>
> In the specific case of vCPU registers, this is fine because the owner process
> can read and write to them using KVM IOCTLs anyway. But in the general case this
> represents a security concern and needs to be addressed.
>
> A possible way forward for the arch-agnostic implementation is to limit the user
> virtual addresses used for kernel to specific range that can be checked against
> in copy_from_user() and copy_to_user().
>
> For arch specific implementation, using separate PGD is the way to go.
>
> [1] https://lore.kernel.org/lkml/20190612170834.14855-1-mhillenb@amazon.de/
> [2] https://lore.kernel.org/lkml/20240621201501.1059948-1-rkagan@amazon.de/


Hey Mark and Mike,

We talked at LPC about mm-local memory and you had some inputs. It would 
be amazing to write them down here so I don't end up playing game of 
telephone :)


Thanks!




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