linux-kernel - Re: [RFC PATCH 1/7] mseal: expose interface to seal / unseal user memory ranges

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

Message-ID: <20240925152509.87152-1-faresx@amazon.de>
Date: Wed, 25 Sep 2024 15:25:09 +0000
From: Fares Mehanna <faresx@...zon.de>
To: <liam.howlett@...cle.com>
CC: <akpm@...ux-foundation.org>, <ardb@...nel.org>, <arnd@...db.de>,
	<bhelgaas@...gle.com>, <broonie@...nel.org>, <catalin.marinas@....com>,
	<david@...hat.com>, <faresx@...zon.de>, <james.morse@....com>,
	<javierm@...hat.com>, <jean-philippe@...aro.org>, <joey.gouly@....com>,
	<kristina.martsenko@....com>, <kvmarm@...ts.linux.dev>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	<linux-mm@...ck.org>, <mark.rutland@....com>, <maz@...nel.org>,
	<nh-open-source@...zon.com>, <oliver.upton@...ux.dev>, <ptosi@...gle.com>,
	<rdunlap@...radead.org>, <rkagan@...zon.de>, <rppt@...nel.org>,
	<shikemeng@...weicloud.com>, <suzuki.poulose@....com>, <tabba@...gle.com>,
	<will@...nel.org>, <yuzenghui@...wei.com>
Subject: Re: [RFC PATCH 1/7] mseal: expose interface to seal / unseal user memory ranges

Hi,

Thanks for taking a look and apologies for my delayed response.

> It is not clear from the change log above or the cover letter as to why
> you need to go this route instead of using the mmap lock.

In the current form of the patches I use memfd_secret() to allocate the pages
and remove them from kernel linear address. [1]

This allocate pages, map them in user virtual addresses and track them in a VMA.

Before flipping the permissions on those pages to be used by the kernel, I need
to make sure that those virtual addresses and this VMA is off-limits to the
owning process.

memfd_secret() pages are locked by default, so they won't swap out. I need to
seal the VMA to make sure the owner process can't unmap/remap/... or change the
protection of this VMA.

So before changing the permissions on the secret pages, I make sure the pages
are faulted in, locked and sealed. So userspace can't influence this mapping.

> We can't use the mseal feature for this; it is supposed to be a one way
> transition.

For this approach, I need the unseal operation when releasing the memory range.

The kernel can be done with the secret pages in one of two scenarios:
1. During lifecycle of the process.
2. When the process terminates.

For the first case, I need to unmap the VMA so it can be reused by the owning
process later, so I need the unseal operation. For the second case however we
don't need that since the process mm is already destructed or just about to be
destructed anyway, regardless of sealed/unsealed VMAs. [1]

I didn't expose	the unseal operation to userspace.

[1] https://lore.kernel.org/linux-arm-kernel/20240911143421.85612-3-faresx@amazon.de/

Thanks!
Fares.

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