linux-kernel - Re: [PATCH v7 1/7] iommu/vt-d: Don't switch off swiotlb if use direct dma

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: <20190823083956.GB24194@8bytes.org>
Date:   Fri, 23 Aug 2019 10:39:56 +0200
From:   Joerg Roedel <joro@...tes.org>
To:     Lu Baolu <baolu.lu@...ux.intel.com>
Cc:     David Woodhouse <dwmw2@...radead.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Christoph Hellwig <hch@....de>, ashok.raj@...el.com,
        jacob.jun.pan@...el.com, alan.cox@...el.com, kevin.tian@...el.com,
        mika.westerberg@...ux.intel.com, Ingo Molnar <mingo@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        pengfei.xu@...el.com,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Robin Murphy <robin.murphy@....com>,
        Jonathan Corbet <corbet@....net>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>
Subject: Re: [PATCH v7 1/7] iommu/vt-d: Don't switch off swiotlb if use
 direct dma

On Fri, Aug 23, 2019 at 03:17:29PM +0800, Lu Baolu wrote:
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -4569,9 +4569,6 @@ static int __init platform_optin_force_iommu(void)
>  		iommu_identity_mapping |= IDENTMAP_ALL;
>  
>  	dmar_disabled = 0;
> -#if defined(CONFIG_X86) && defined(CONFIG_SWIOTLB)
> -	swiotlb = 0;
> -#endif
>  	no_iommu = 0;
>  
>  	return 1;
> @@ -4710,9 +4707,6 @@ int __init intel_iommu_init(void)
>  	}
>  	up_write(&dmar_global_lock);
>  
> -#if defined(CONFIG_X86) && defined(CONFIG_SWIOTLB)
> -	swiotlb = 0;
> -#endif

So this will cause the 64MB SWIOTLB aperture to be allocated even when
there will never be an untrusted device in the system, right? I guess
this will break some kdump setups as they need to resize their low
memory allocations to make room for the aperture because of this
patch-set.

But I also don't see a way around this for now as untrusted devices are
usually hotplugged and might not be present at boot. So we can't make
the decision about the allocation at boot time.

But this mechanism needs to be moved to the dma-iommu implementation at
some point, and then we should allocate the bounce memory pages
on-demand. We can easily do this in page-size chunks and map them
together with iommu page-tables. This way we don't need to pre-allocate
a large memory-chunk at boot.

Regards,

	Joerg