Alan Cox wrote:
On Mer, 2004-08-11 at 13:53, Thomas HellstrÃm wrote:
  
When I did some cleaning up of the via drm code I noticed that the memory
manager seems identical to the SiS one, so if there is a problem with
that, then there is a problem with the via driver.
    

Yeah I know about one.

  
Also the unichrome 2d driver allows XvMC dri clients to map (RW) the
framebuffer and the whole register space, and I know that at certain video
register write combinations will lock my machine hard. From my point of
view, however,  this is a deficiency in the unichrome 2d driver rather
than in the via drm driver.
    

DRI allows for locking the box. I can lock the radeon, I can lock the
matrox. Its supposed to not allow worse than that. The XvMC slice
registers for mpeg are all in one location - is that too close to other
registers to split up the map ? If not perhaps the slice load should be
in the DRI module ?
  
Unfortunately I think so. Mpeg registers are at offset 0x0c00 from
the register map start. Worse is that some XvMC dri functions use the video
registers for flipping and the 2D blitter for frame copying, but we've
had discussions about moving some parts to the drm module and some
parts to the X server. The biggest problem is that the XvMC X protocol
is incomplete which makes it troublesome to move stuff to the X server.

Also I'm not too sure about how restrictive the via DDX OpenGL dri part is about
allowing clients to map the register space.

None of this makes the drm module in itself insecure IMHO, however. But there
might be other issues that I haven't heard of.

Regards
Thomas

Reply via email to