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, 10 Jan 2019 10:34:28 +0100
From:   Michel Dänzer <michel@...nzer.net>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        linux-kernel@...r.kernel.org
Cc:     Carsten.Haitzler@....com, David Airlie <airlied@...ux.ie>,
        will.deacon@....com, dri-devel@...ts.freedesktop.org,
        Huang Rui <ray.huang@....com>,
        Junwei Zhang <Jerry.Zhang@....com>,
        Christian Koenig <christian.koenig@....com>,
        linux-arm-kernel@...ts.infradead.org,
        Bernhard.Rosenkranzer@...aro.org
Subject: Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote:
> ARM systems do not permit the use of anything other than cached
> mappings for system memory, since that memory may be mapped in the
> linear region as well, and the architecture does not permit aliases
> with mismatched attributes.
> 
> So short-circuit the evaluation in ttm_io_prot() if the flags include
> TTM_PL_SYSTEM when running on ARM or arm64, and just return cached
> attributes immediately.
> 
> This fixes the radeon and amdgpu [TBC] drivers when running on arm64.
> Without this change, amdgpu does not start at all, and radeon only
> produces corrupt display output.
> 
> Cc: Christian Koenig <christian.koenig@....com>
> Cc: Huang Rui <ray.huang@....com>
> Cc: Junwei Zhang <Jerry.Zhang@....com>
> Cc: David Airlie <airlied@...ux.ie>
> Reported-by: Carsten Haitzler <Carsten.Haitzler@....com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
> ---
>  drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 046a6dda690a..0c1eef5f7ae3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -530,6 +530,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
>  	if (caching_flags & TTM_PL_FLAG_CACHED)
>  		return tmp;
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +	/* ARM only permits cached mappings of system memory */
> +	if (caching_flags & TTM_PL_SYSTEM)
> +		return tmp;
> +#endif
>  #if defined(__i386__) || defined(__x86_64__)
>  	if (caching_flags & TTM_PL_FLAG_WC)
>  		tmp = pgprot_writecombine(tmp);
> 

Apart from Christian's concerns, I think this is the wrong place for
this, because other TTM / driver code will still consider the memory
uncacheable. E.g. the amdgpu driver will program the GPU to treat the
memory as uncacheable, so it won't participate in cache coherency
protocol for it, which is unlikely to work as expected in general if the
CPU treats the memory as cacheable.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ