linux-kernel - Re: [PATCH 1/1] iommu/vt-d: Fix RID2PASID setup failure

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: <868f515e-a4ea-8c34-7317-5aba18f8d5f0@linux.intel.com>
Date:   Mon, 20 Jun 2022 16:57:51 +0800
From:   Baolu Lu <baolu.lu@...ux.intel.com>
To:     Yi Liu <yi.l.liu@...el.com>, Joerg Roedel <joro@...tes.org>,
        Kevin Tian <kevin.tian@...el.com>,
        Ashok Raj <ashok.raj@...el.com>
Cc:     baolu.lu@...ux.intel.com, Chenyi Qiang <chenyi.qiang@...el.com>,
        Jacob jun Pan <jacob.jun.pan@...el.com>,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH 1/1] iommu/vt-d: Fix RID2PASID setup failure

On 2022/6/20 16:31, Yi Liu wrote:
> Hi Baolu,
> 
> On 2022/6/20 16:17, Lu Baolu wrote:
>> The IOMMU driver shares the pasid table for PCI alias devices. When the
>> RID2PASID entry of the shared pasid table has been filled by the first
>> device, the subsequent devices will encounter the "DMAR: Setup RID2PASID
>> failed" failure as the pasid entry has already been marke as present. As
> 
> s/marke/marked/

Updated. Thanks!

>> the result, the IOMMU probing process will be aborted.
>>
>> This fixes it by skipping RID2PASID setting if the pasid entry has been
>> populated. This works because the IOMMU core ensures that only the same
>> IOMMU domain can be attached to all PCI alias devices at the same time.
> 
> nit. this sentence is a little bit to interpret. :-) I guess what you want
> to describe is the PCI alias devices should be attached to the same domain
> instead of different domain. right?

Yes.

> 
> also, does it apply to all domain types? e.g. the SVA domains introduced 
> in "iommu: SVA and IOPF refactoring"

No. Only about the RID2PASID.

> 
>> Therefore the subsequent devices just try to setup the RID2PASID entry
>> with the same domain, which is negligible.
>>
>> Fixes: ef848b7e5a6a0 ("iommu/vt-d: Setup pasid entry for RID2PASID 
>> support")
>> Reported-by: Chenyi Qiang <chenyi.qiang@...el.com>
>> Cc: stable@...r.kernel.org
>> Signed-off-by: Lu Baolu <baolu.lu@...ux.intel.com>
>> ---
>>   drivers/iommu/intel/iommu.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
>> index 44016594831d..b9966c01a2a2 100644
>> --- a/drivers/iommu/intel/iommu.c
>> +++ b/drivers/iommu/intel/iommu.c
>> @@ -2564,7 +2564,7 @@ static int domain_add_dev_info(struct 
>> dmar_domain *domain, struct device *dev)
>>               ret = intel_pasid_setup_second_level(iommu, domain,
>>                       dev, PASID_RID2PASID);
>>           spin_unlock_irqrestore(&iommu->lock, flags);
>> -        if (ret) {
>> +        if (ret && ret != -EBUSY) {
>>               dev_err(dev, "Setup RID2PASID failed\n");
>>               dmar_remove_one_dev_info(dev);
>>               return ret;
> 

--
Best regards,
baolu