linux-kernel - Re: [PATCH v8 2/4] iommufd: Add iommufd_access

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: <ZMJc9elDILpHaKP6@nvidia.com>
Date:   Thu, 27 Jul 2023 09:03:01 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Nicolin Chen <nicolinc@...dia.com>
Cc:     kevin.tian@...el.com, alex.williamson@...hat.com,
        yi.l.liu@...el.com, joro@...tes.org, will@...nel.org,
        robin.murphy@....com, shuah@...nel.org,
        linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
        kvm@...r.kernel.org, linux-kselftest@...r.kernel.org,
        mjrosato@...ux.ibm.com, farman@...ux.ibm.com
Subject: Re: [PATCH v8 2/4] iommufd: Add iommufd_access_replace() API

On Wed, Jul 26, 2023 at 07:59:11PM -0700, Nicolin Chen wrote:

> I just realized that either my v8 or your version calls unmap()
> first at the entire cur_ioas. So, there seems to be no point in
> doing that fallback re-add routine since the cur_ioas isn't the
> same, which I don't feel quite right...

The point is to restore the access back to how it should be on failure
so future use of the accesss still does the right thing.

We already have built into this a certain non-atomicity for mdevs,
they can see a pin failure during replace if they race an access
during this unmap window. This is similar to the real HW iommu's
without atomic replace.

> Perhaps we should pass the ID into iopt_add/remove_access like
> you said above. And then we attach the new_ioas, piror to the
> detach the cur_ioas?

If it is simple this seems like the most robust

Jason