[Openchrome-devel] Chrome9 kernel DRM

[Thomas Hellström]

Benjamin, and others.

BenjaminPan at viatech.com wrote:
> Xavier and Harald,
>
> I don't see why not to move the discussion to an open area. The source code of Chrome9's DRM driver is on our web site. So it is already open. We are just trying to find a way to bring it to the compliance level by the kernel standard to go upstream.
>
> Thanks,
>
> Benjamin Pan
>
> -----Original Message-----
> From: Xavier Bachelot [mailto:xavier at bachelot.org] 
> Sent: Wednesday, July 30, 2008 7:27 AM
> To: Harald Welte
> Cc: Benjamin Pan (Fremont); Bruce Chang; Thomas Hellstr?m
> Subject: Re: Chrome9 kernel DRM / David Airlie
>
> Harald Welte wrote:
>   
>> Hi Benjamin, Xavier, Bruce,
>>
>> I've heard from Bruce and read in the openchrome IRC meeting log that
>> Benjamin also mentioned it:  VIA has a hard time getting Chrome9 DRM
>> merged into the kernel
>>
>> I had a discussion with David Airlie and some private conversations with
>> other related kernel folks.  There are a set of issues:
>>
>> 1) With the driver and without any knowledge on how the hardware works, it
>>    is impossible for the kernel developers to find out if the driver
>>    causes any security problems (apparently the old unichrome DRM driver
>>    for years caused serious security problems by allowing userspace
>>    programs to program the DMA engine to overwrite kernel memory!!)
>>  
>>     
> True, Thomas worked hard to clean up the via drm driver that is 
> currently in the kernel.
>
>   
I have now had a quick look at the command submission mechanisms of the 
Chrome9 engine.
 From what I can understand, it's quite similar to the unichrome series 
but with some extended capabilities.

In particular, I've noticed the following security hazards (numbers) 
with suggested remedies (letters).
Note that a user space program below means a non-root program ( a 
typical DRI client ).

1) The PCI dma engines can access all of memory.
a) Make sure the register space is not exported to user-space.
b) Make sure the PCI dma engines can not be programmed using the AGP- or 
VQ command submission mechanisms.
c) Make sure PCI dma engines cannot transfer data into the VQ command 
buffer space.

2) Fence sequenes can be written to arbitrary memory locations.
a) Make sure user-space programs can not emit fence commands in the 
command packets they submit.

3) Textures and rendering surfaces can be set to arbitrary locations in 
system memory, as well as page-flipping base adresses.
a) The DRM must make sure user-space does not attempt to set up 
rendering to or texturing from system memory.

Unless the hardware is capable of blocking all these hazards
(For example, Intel hardware has a concept of "secure" batch buffers 
where hazardous commands are rejected by the hardware),
the DRM must parse the command stream and reject it if there are any 
commands emanating from user-space attempting to read from or write to 
arbitrary system pages. If pixel shader programs are able to read from 
arbitrary system pages, such programs must be blocked by the DRM as well.

The reason for all this is that
a) A user must not be able to access private data of other users on the 
same computer.
b) A user must not be able to patch the kernel code using the GPU, and 
thus gain access to the computer.

The unichrome (via) drm has a command stream verifier that perhaps can 
be used as a starting point for this, given that the command format 
seems rather similar. This will unfortunately make 3D programs use a bit 
more CPU than otherwise.

It turns out that manufacturers of embedded solutions often doesn't care 
much about security features like this, so a compile option to disable 
the command stream verifier for these solutions could come in handy.

Regards,
/Thomas