linux-kernel - Re: [PATCH 1/2] iommu: add support for drivers that manage iommu explicitly

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: <20190704082001.GD6546@8bytes.org>
Date:   Thu, 4 Jul 2019 10:20:01 +0200
From:   Joerg Roedel <joro@...tes.org>
To:     Rob Clark <robdclark@...il.com>
Cc:     iommu@...ts.linux-foundation.org, dri-devel@...ts.freedesktop.org,
        aarch64-laptops@...ts.linaro.org,
        Jordan Crouse <jcrouse@...eaurora.org>,
        Rob Clark <robdclark@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Vivek Gautam <vivek.gautam@...eaurora.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Joe Perches <joe@...ches.com>,
        Sudeep Holla <sudeep.holla@....com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] iommu: add support for drivers that manage iommu
 explicitly

Hi Rob,

On Tue, Jul 02, 2019 at 01:26:18PM -0700, Rob Clark wrote:
> 1) In some cases the bootloader takes the iommu out of bypass and
>    enables the display.  This is in particular a problem on the aarch64
>    laptops that exist these days, and modern snapdragon android devices.
>    (Older devices also enabled the display in bootloader but did not
>    take the iommu out of bypass.)  Attaching a DMA or IDENTITY domain
>    while scanout is active, before the driver has a chance to intervene,
>    makes things go *boom*

Just to make sure I get this right: The bootloader inializes the SMMU
and creates non-identity mappings for the GPU? And when the SMMU driver
in Linux takes over this breaks display output.

> +	/*
> +	 * If driver is going to manage iommu directly, then avoid
> +	 * attaching any non driver managed domain.  There could
> +	 * be already active dma underway (ie. scanout in case of
> +	 * bootloader enabled display), and interfering with that
> +	 * will make things go *boom*
> +	 */
> +	if ((domain->type != IOMMU_DOMAIN_UNMANAGED) &&
> +	    dev->driver && dev->driver->driver_manages_iommu)
> +		return 0;
> +

When the default domain is attached, there is usually no driver attached
yet. I think this needs to be communicated by the firmware to Linux and
the code should check against that.

> -	bool suppress_bind_attrs;	/* disables bind/unbind via sysfs */
> +	bool suppress_bind_attrs:1;	/* disables bind/unbind via sysfs */
> +	bool driver_manages_iommu:1;	/* driver manages IOMMU explicitly */

How does this field get set?



	Joerg