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: <14a7c534-af3f-43b8-a24c-501a9af97936@suse.de>
Date: Wed, 12 Jun 2024 10:37:14 +0200
From: Thomas Zimmermann <tzimmermann@...e.de>
To: Javier Martinez Canillas <javierm@...hat.com>,
 "Peng Fan (OSS)" <peng.fan@....nxp.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, David Airlie <airlied@...il.com>,
 Daniel Vetter <daniel@...ll.ch>
Cc: Peng Fan <peng.fan@....com>, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/fbdev-dma: fix getting smem_start

Hi Javier

Am 12.06.24 um 09:49 schrieb Javier Martinez Canillas:
> Thomas Zimmermann <tzimmermann@...e.de> writes:
>
> Hello Thomas,
>
>> Hi
>>
>> Am 10.06.24 um 10:47 schrieb Thomas Zimmermann:
>>> Hi
>>>
>>> Am 04.06.24 um 10:03 schrieb Peng Fan (OSS):
>>>> From: Peng Fan <peng.fan@....com>
>>>>
>>>> If 'info->screen_buffer' locates in vmalloc address space, virt_to_page
>>>> will not be able to get correct results. With CONFIG_DEBUG_VM and
>>>> CONFIG_DEBUG_VIRTUAL enabled on ARM64, there is dump below:
>>> Which graphics driver triggers this bug?
>>>
>>>> [    3.536043] ------------[ cut here ]------------
>>>> [    3.540716] virt_to_phys used for non-linear address:
>>>> 000000007fc4f540 (0xffff800086001000)
>>>> [    3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12
>>>> __virt_to_phys+0x68/0x98
>>>> [    3.565455] Modules linked in:
>>>> [    3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted
>>>> 6.6.23-06226-g4986cc3e1b75-dirty #250
>>>> [    3.577310] Hardware name: NXP i.MX95 19X19 board (DT)
>>>> [    3.582452] Workqueue: events_unbound deferred_probe_work_func
>>>> [    3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS
>>>> BTYPE=--)
>>>> [    3.595233] pc : __virt_to_phys+0x68/0x98
>>>> [    3.599246] lr : __virt_to_phys+0x68/0x98
>>>> [    3.603276] sp : ffff800083603990
>>>> [    3.677939] Call trace:
>>>> [    3.680393]  __virt_to_phys+0x68/0x98
>>>> [    3.684067]  drm_fbdev_dma_helper_fb_probe+0x138/0x238
>>>> [    3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0
>>>> [    3.695385]  drm_fb_helper_initial_config+0x4c/0x68
>>>> [    3.700264]  drm_fbdev_dma_client_hotplug+0x8c/0xe0
>>>> [    3.705161]  drm_client_register+0x60/0xb0
>>>> [    3.709269]  drm_fbdev_dma_setup+0x94/0x148
>>>>
>>>> So add a check 'is_vmalloc_addr'.
>>>>
>>>> Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for
>>>> GEM DMA helpers")
>>>> Signed-off-by: Peng Fan <peng.fan@....com>
>>> Reviewed-by: Thomas Zimmermann <tzimmermann@...e.de>
>> I'm taking back my r-b. The memory is expected to by be physically
>> contiguous and vmalloc() won't guarantee that.
>>
> Agreed.

These smem_ fields are clearly designed for PCI BARs of traditional 
graphics cards. So can we even assume contiguous memory for DMA? That 
was my assumption, but with IOMMUs it might not be the case. Fbdev-dma 
only sets smem_start to support a single old userspace driver. Maybe we 
should further restrict usage of this field by making it opt-in for each 
driver. Best regards Thomas
>
>> Best regards
>> Thomas
>>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ