linux-kernel - Re: [PATCH 1/1] iommu: Avoid races around default domain allocations

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: Thu, 8 Feb 2024 20:47:42 +0530
From: Nikhil V <quic_nprakash@...cinc.com>
To: Robin Murphy <robin.murphy@....com>, Jason Gunthorpe <jgg@...pe.ca>
CC: Will Deacon <will@...nel.org>, Joerg Roedel <joro@...tes.org>,
        "Charan
 Teja Kalla" <quic_charante@...cinc.com>,
        <iommu@...ts.linux.dev>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] iommu: Avoid races around default domain allocations



On 2/8/2024 7:07 AM, Robin Murphy wrote:
> On 2024-02-08 1:13 am, Jason Gunthorpe wrote:
>> On Thu, Feb 08, 2024 at 12:04:44AM +0000, Robin Murphy wrote:
>>>> Frankly, I'd suggest just proposing the necessary (and tested)
>>>> upstream patches to 6.1, however large they are, and see what Greg and
>>>> Sasha say. This is the usual working model they have, as I understand
>>>> it.
>>>
>>> To be blunt, hell no. Stable is far enough from its namesake already; 
>>> the
>>> ongoing bordering-on-ridiculous brokenness of your mainline changes 
>>> where
>>
>> What on earth are you even talking about? POWER?
> 
> I mean you're literally getting bug reports for your fix for your fix 
> for your grand idea, so what should we figure, that reality not aligning 
> with your expectations is all reality's fault?
> 
>>> That said, I also don't think there would be any harm in applying 
>>> this to
>>> mainline as a belt-and-braces thing either,
>>
>> Really?
> 
> "at 12:04:44AM +0000, Robin Murphy wrote:"
> 
> It's late, I should have gone to bed hours ago, so I apologise for any 
> lack of clarity; that was very much meant to be an implication of 
> agreement with the overall approach, not the exact patch as is, which if 
> you read the rest of my response you will see I still had questions 
> about and did not formally ack or review.
> 
>> Now that you've made me look, this patch breaks the
>> iommu_group_store_type() flow both on latest and on v6.1 from what I
>> can see.
>>
>> On v6.1:
>>
>> iommu_change_dev_def_domain():
>>          prev_dom = group->default_domain;
>>          if (!prev_dom) {
>>                  ret = -EINVAL;
>>                  goto out;
>>          }
>> [..]
>>          /* Sets group->default_domain to the newly allocated domain */
>>          ret = iommu_group_alloc_default_domain(dev->bus, group, type);
>>          if (ret)
>>                  goto out;
>>
>> But this patch changes iommu_group_alloc_default_domain() to succeed
>> always without doing anythiing.
>>
>> So this patch needs some fixing.
> 
> Hurrah! Please apply that kind of rigour to your own patches also.
> 
> Thanks,
> Robin.
> 
> [ you get two responses this week since I admit I ran out of patience 
> and motivation to finish last week's on time ]


Hi Robin,

Bunch of issues were reported on 6.1 because that is where we do master 
testing. The change proposed was fixing the reported issues.

On your query regarding 5.15, from code perspective, looks like this fix 
is applicable on 5.15 as well. However, as mentioned, we have done 
master testings on 6.1 codebase and hence could see the issues there only.

Also, as Jason pointed out, this fix would not allow changing the 
default domain for an iommu group. We didn't have any usecase for 
changing default domain, hence couldn't see any issues with the fix 
proposed. So, we would have to rework the patch for it to be upstream 
ready. Any suggestions for this would be really helpful and
appreciated. Thanks!!!

Thanks
Nikhil V