linux-kernel - Re: [PATCH 6/8] iommu: Retire bus ops

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]

Date:   Fri, 20 Jan 2023 12:31:21 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Baolu Lu <baolu.lu@...ux.intel.com>, joro@...tes.org,
        will@...nel.org
Cc:     hch@....de, jgg@...dia.com, iommu@...ts.linux.dev,
        linux-kernel@...r.kernel.org,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 6/8] iommu: Retire bus ops

On 2023-01-20 00:27, Baolu Lu wrote:
> On 2023/1/20 3:18, Robin Murphy wrote:
>> +    /*
>> +     * For FDT-based systems and ACPI IORT/VIOT, drivers register IOMMU
>> +     * instances with non-NULL fwnodes, and client devices should 
>> have been
>> +     * identified with a fwspec by this point. For 
>> Intel/AMD/s390/PAMU we
>> +     * can assume a single active driver with global ops, and so grab 
>> those
>> +     * from any registered instance, cheekily co-opting the same 
>> mechanism.
>> +     */
>> +    fwspec = dev_iommu_fwspec_get(dev);
>> +    if (fwspec && fwspec->ops)
>> +        ops = fwspec->ops;
>> +    else
>> +        ops = iommu_ops_from_fwnode(NULL);
> 
> I'm imagining if Intel/AMD/s390 drivers need to give up global ops.
> Is there any way to allow them to make such conversion? I am just
> thinking about whether this is a hard limitation for these drivers.

Yes, they could perhaps bodge into the existing fwnode mechanism, or we 
could make bigger changes to adapt and generalise the whole 
instance-registration-token-lookup concept, or if the driver can resolve 
the correct instance for a device internally, then it could suffice to 
just have all its device ops share a single common .probe_device 
implementation that does the right thing.

The comment is merely noting the fact that we can get away without 
having to worry about those changes just yet, since all the drivers 
*are* currently still built around the hard constraint of a single set 
of device ops per bus.

Thanks,
Robin.