Xen devel - May 2006 - RE: Is Xen affected by this x86 hardware security hole?

> A better solution would be to have a kernel module that 
> provides services to the X server, but this would require 
> more code per platform, which is partly why it wasn''t done 
> like this...  *sigh*
Isn''t this what the kernel /dev/fbdev driver does? 

If you''re running an fbdev Xserver you shouldn''t need to give
the
Xserver io or mmio permissions.

Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > A better solution would be to have a kernel module that
> > provides services to the X server, but this would require
> > more code per platform, which is partly why it wasn''t done
> > like this...  *sigh*
>
> Isn''t this what the kernel /dev/fbdev driver does?
>
> If you''re running an fbdev Xserver you shouldn''t need to
give the
> Xserver io or mmio permissions.
Yes, I think that''s the idea behind it.  Does anyone know if it works
in the
general case, or only for specific graphics cards / specific display modes?  
I''ve not used it myself.

The real problem is that X servers can generally call iopl() / ioperm() and 
thus get access to stupid things.  Deprivileging the process (or preferably 
terminating the existence of those syscalls with extreme prejudice) is really 
the right fix.

That said, they can usually only call those things because they''re
root, and
if they''re root a root exploit doesn''t seem so bad *shrug*? 
Does anyone
actually use fine grained access control for X servers in modern distros?

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel