[LUCID] drm/radeon: r6xx/r7xx possible security issue, system ram access

[Tim Gardner]

Amit Kucheria wrote:
> On 10 Feb 11, Manoy Iyer wrote:
>> Found this patch wile looking into another issue related to radeon, I 
>> think it will be nice to have this hole plugged. Please review and pull 
>> for lucid. I built a kernel with this patch & have no compile errors.
>>
>> The following changes since commit 
>> 6bc5a94051303f7a902760b4927ce73b63443044:
>>    Jerome Glisse (1):
>>          drm/radeon: r6xx/r7xx possible security issue, system ram access
>>
>> are available in the git repository at:
>>
>>
>> ssh://zinc.canonical.com/srv/kernel.ubuntu.com/git/manjo/ubuntu-lucid.git 
>> drm_security
>>
>>
>> From 6bc5a94051303f7a902760b4927ce73b63443044 Mon Sep 17 00:00:00 2001
>> From: Jerome Glisse <jglisse at redhat.com>
>> Date: Mon, 18 Jan 2010 13:01:36 +0100
>> Subject: [PATCH] drm/radeon: r6xx/r7xx possible security issue, system ram access
>>
>> 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 at redhat.com>
>> Signed-off-by: Dave Airlie <airlied at linux.ie>
>> Signed-off-by: Manoj Iyer <manoj.iyer at canonical.com>
> 
> 
> Given the patch writer's own comments on how hard it is to exploit this
> perceived security issue, should we really consider it for an LTS?
> 
> It is fairly significant in size. Is this upstream yet? Would it hamper our ability
> to apply other fixes to this driver?
> 
> /Amit
> 

Yeah - what Amit says. Lets wait for this to trickle in via stable updates.

rtg
-- 
Tim Gardner tim.gardner at canonical.com