linux-kernel - Re: [PATCH] iommu: Avoid more races around device probe

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: <ZVZL9kZuVsb9VPnM@nvidia.com>
Date:   Thu, 16 Nov 2023 13:05:58 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Robin Murphy <robin.murphy@....com>
Cc:     joro@...tes.org, will@...nel.org, iommu@...ts.linux.dev,
        linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
        rafael@...nel.org, lenb@...nel.org, lpieralisi@...nel.org,
        andre.draszik@...aro.org, quic_zhenhuah@...cinc.com
Subject: Re: [PATCH] iommu: Avoid more races around device probe

On Wed, Nov 15, 2023 at 06:25:44PM +0000, Robin Murphy wrote:
> It turns out there are more subtle races beyond just the main part of
> __iommu_probe_device() itself running in parallel - the dev_iommu_free()
> on the way out of an unsuccessful probe can still manage to trip up
> concurrent accesses to a device's fwspec. Thus, extend the scope of
> iommu_probe_device_lock() to also serialise fwspec creation and initial
> retrieval.
> 
> Reported-by: Zhenhua Huang <quic_zhenhuah@...cinc.com>
> Link: https://lore.kernel.org/linux-iommu/e2e20e1c-6450-4ac5-9804-b0000acdf7de@quicinc.com/
> Fixes: 01657bc14a39 ("iommu: Avoid races around device probe")
> Signed-off-by: Robin Murphy <robin.murphy@....com>
> ---
> 
> This is my idea of a viable fix, since it does not need a 700-line
> diffstat to make the code do what it was already *trying* to do anyway.
> This stuff should fundamentally not be hanging off driver probe in the
> first place, so I'd rather get on with removing the underlying
> brokenness than waste time and effort polishing it any further.

I'm fine with this as some hacky backport, but I don't want to see
this cross-layer leakage left in the next merge window.

ie we should still do my other series on top of and reverting this.

I've poked at moving parts of it under probe and I think we can do
substantial amounts in about two more series and a tidy a bunch of
other stuff too.

Jason