linux-kernel - Re: [PATCH 5/5] iommu/dart: Assert !locked when configuring

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: <20250211192152.GA810942@robin.jannau.net>
Date: Tue, 11 Feb 2025 20:21:52 +0100
From: Janne Grunau <j@...nau.net>
To: Robin Murphy <robin.murphy@....com>
Cc: Alyssa Rosenzweig <alyssa@...enzweig.io>,
	Sven Peter <sven@...npeter.dev>, Joerg Roedel <joro@...tes.org>,
	Will Deacon <will@...nel.org>, asahi@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/5] iommu/dart: Assert !locked when configuring

On Tue, Feb 11, 2025 at 06:41:00PM +0000, Robin Murphy wrote:
> On 2025-02-10 7:39 pm, Alyssa Rosenzweig wrote:
> > Configuration is only possible and needed for non-locked DARTs and will
> > fail for locked DARTs. We cannot try -- assert that we do not.
> 
> Except now we absolutely will - if a locked DART and its client device 
> are advertised to Linux, instead of gracefully refusing to touch it, 
> we'll now attach the client to a DMA domain, firing a barrage of 
> multiple WARNs in the process, and give it DMA ops which still cannot 
> work. I'm not really convinced this series on its own leaves us in a 
> better position than we're already in now... :/
> 
> How hideous is the rest of what's required to actually make this usable?

The TTBR can not be changed but the preset first level table can
modified at will. The driver keeps a shadow first label table and syncs
that to the preset 1st level table on flush_tbl().
It gets more complicated by the fact that the iommu for the display
coprocessor is locked and mappings for its firmware and boot framebuffer
are preinstalled and have to be maintained or restored on
initialization.
This is handled via reserved memory with translation.

Downstream change to handle this is in
https://github.com/AsahiLinux/linux/commit/d90cc3590ea460e1c574b4b7c47fdafb2794af6a
not including the change to parse / handle reserved memory with
translation in iommu core.

Janne