mirror of
https://github.com/torvalds/linux
synced 2024-09-24 13:31:12 +00:00
c8c15ff1e9
This patch workaround a possible security issue which can allow user to abuse drm on r6xx/r7xx hw to access any system ram memory. This patch doesn't break userspace, it detect "valid" old use of CB_COLOR[0-7]_FRAG & CB_COLOR[0-7]_TILE registers and overwritte the address these registers are pointing to with the one of the last color buffer. This workaround will work for old mesa & xf86-video-ati and any old user which did use similar register programming pattern as those (we expect that there is no others user of those ioctl except possibly a malicious one). This patch add a warning if it detects such usage, warning encourage people to update their mesa & xf86-video-ati. New userspace will submit proper relocation. Fix for xf86-video-ati / mesa (this kernel patch is enough to prevent abuse, fix for userspace are to set proper cs stream and avoid kernel warning) : http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=95d63e408cc88b6934bec84a0b1ef94dfe8bee7b http://cgit.freedesktop.org/mesa/mesa/commit/?id=46dc6fd3ed5ef96cda53641a97bc68c3bc104a9f Abusing this register to perform system ram memory is not easy, here is outline on how it could be achieve. First attacker must have access to the drm device and be able to submit command stream throught cs ioctl. Then attacker must build a proper command stream for r6xx/r7xx hw which will abuse the FRAG or TILE buffer to overwrite the GPU GART which is in VRAM. To achieve so attacker as to setup CB_COLOR[0-7]_FRAG or CB_COLOR[0-7]_TILE to point to the GPU GART, then it has to find a way to write predictable value into those buffer (with little cleverness i believe this can be done but this is an hard task). Once attacker have such program it can overwritte GPU GART to program GPU gart to point anywhere in system memory. It then can reusse same method as he used to reprogram GART to overwritte the system ram through the GART mapping. In the process the attacker has to be carefull to not overwritte any sensitive area of the GART table, like ring or IB gart entry as it will more then likely lead to GPU lockup. Bottom line is that i think it's very hard to use this flaw to get system ram access but in theory one can achieve so. Side note: I am not aware of anyone ever using the GPU as an attack vector, nevertheless we take great care in the opensource driver to try to detect and forbid malicious use of GPU. I don't think the closed source driver are as cautious as we are. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@linux.ie> |
||
|---|---|---|
| .. | ||
| i2c | ||
| i810 | ||
| i830 | ||
| i915 | ||
| mga | ||
| nouveau | ||
| r128 | ||
| radeon | ||
| savage | ||
| sis | ||
| tdfx | ||
| ttm | ||
| via | ||
| vmwgfx | ||
| ati_pcigart.c | ||
| drm_agpsupport.c | ||
| drm_auth.c | ||
| drm_bufs.c | ||
| drm_cache.c | ||
| drm_context.c | ||
| drm_crtc.c | ||
| drm_crtc_helper.c | ||
| drm_debugfs.c | ||
| drm_dma.c | ||
| drm_dp_i2c_helper.c | ||
| drm_drawable.c | ||
| drm_drv.c | ||
| drm_edid.c | ||
| drm_encoder_slave.c | ||
| drm_fb_helper.c | ||
| drm_fops.c | ||
| drm_gem.c | ||
| drm_hashtab.c | ||
| drm_info.c | ||
| drm_ioc32.c | ||
| drm_ioctl.c | ||
| drm_irq.c | ||
| drm_lock.c | ||
| drm_memory.c | ||
| drm_mm.c | ||
| drm_modes.c | ||
| drm_pci.c | ||
| drm_proc.c | ||
| drm_scatter.c | ||
| drm_sman.c | ||
| drm_stub.c | ||
| drm_sysfs.c | ||
| drm_vm.c | ||
| Kconfig | ||
| Makefile | ||
| README.drm | ||
************************************************************
* For the very latest on DRI development, please see: *
* http://dri.freedesktop.org/ *
************************************************************
The Direct Rendering Manager (drm) is a device-independent kernel-level
device driver that provides support for the XFree86 Direct Rendering
Infrastructure (DRI).
The DRM supports the Direct Rendering Infrastructure (DRI) in four major
ways:
1. The DRM provides synchronized access to the graphics hardware via
the use of an optimized two-tiered lock.
2. The DRM enforces the DRI security policy for access to the graphics
hardware by only allowing authenticated X11 clients access to
restricted regions of memory.
3. The DRM provides a generic DMA engine, complete with multiple
queues and the ability to detect the need for an OpenGL context
switch.
4. The DRM is extensible via the use of small device-specific modules
that rely extensively on the API exported by the DRM module.
Documentation on the DRI is available from:
http://dri.freedesktop.org/wiki/Documentation
http://sourceforge.net/project/showfiles.php?group_id=387
http://dri.sourceforge.net/doc/
For specific information about kernel-level support, see:
The Direct Rendering Manager, Kernel Support for the Direct Rendering
Infrastructure
http://dri.sourceforge.net/doc/drm_low_level.html
Hardware Locking for the Direct Rendering Infrastructure
http://dri.sourceforge.net/doc/hardware_locking_low_level.html
A Security Analysis of the Direct Rendering Infrastructure
http://dri.sourceforge.net/doc/security_low_level.html