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] [day] [month] [year] [list]
Message-ID: <20200220173213.moynvygrdzc66zqg@cantor>
Date:   Thu, 20 Feb 2020 10:32:13 -0700
From:   Jerry Snitselaar <jsnitsel@...hat.com>
To:     Lu Baolu <baolu.lu@...ux.intel.com>,
        Joerg Roedel <joro@...tes.org>,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: question about iommu_need_mapping

On Thu Feb 20 20, Jerry Snitselaar wrote:
>On Thu Feb 20 20, Lu Baolu wrote:
>>Hi Jerry,
>>
>>On 2020/2/20 7:55, Jerry Snitselaar wrote:
>>>Is it possible for a device to end up with dev->archdata.iommu == NULL
>>>on iommu_need_mapping in the following instance:
>>>
>>>1. iommu_group has dma domain for default
>>>2. device gets private identity domain in intel_iommu_add_device
>>>3. iommu_need_mapping gets called with that device.
>>>4. dmar_remove_one_dev_info sets dev->archdata.iommu = NULL via 
>>>unlink_domain_info.
>>>5. request_default_domain_for_dev exits after checking that 
>>>group->default_domain
>>>   exists, and group->default_domain->type is dma.
>>>6. iommu_request_dma_domain_for_dev returns 0 from 
>>>request_default_domain_for_dev
>>>   and a private dma domain isn't created for the device.
>>>
>>
>>Yes. It's possible.
>>
>>>The case I was seeing went away with commit 9235cb13d7d1 ("iommu/vt-d:
>>>Allow devices with RMRRs to use identity domain"), because it changed
>>>which domain the group and devices were using, but it seems like it is
>>>still a possibility with the code. Baolu, you mentioned possibly
>>>removing the domain switch. Commit 98b2fffb5e27 ("iommu/vt-d: Handle
>>>32bit device with identity default domain") makes it sound like the
>>>domain switch is required.
>>
>>It's more "nice to have" than "required" if the iommu driver doesn't
>>disable swiotlb explicitly. The device access of system memory higher
>>than the device's addressing capability could go through the bounced
>>buffer implemented in swiotlb.
>>
>>Best regards,
>>baolu
>
>Hi Baolu,
>
>Would this mean switching to bounce_dma_ops instead?
>

Never mind. I see that it would go into the dma_direct code.

>Regards,
>Jerry
>
>>_______________________________________________
>>iommu mailing list
>>iommu@...ts.linux-foundation.org
>>https://lists.linuxfoundation.org/mailman/listinfo/iommu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ