Xegl lives!

[Jon Smirl]

On 5/29/05, Adam Jackson <ajax at nwnk.net> wrote:
> This didn't answer the question.  You have stated before that the danger in
> allowing the driver to set arbitrary modes is that you can request a mode
> outside of what the monitor is capable of.  99.44% of monitors made in the
> past ten years will reject these modes (refuse to sync, blank screen).  The
> other ones are broken by design.
> 
> Setting the mode to something the monitor does not support, does not represent
> a privilege escalation.  It does not represent a way for the user to get
> access to data they do not normally have.  All it represents is the ability
> to turn broken hardware into non-functional hardware.

Alan Cox specifically requested that setting arbitrary modes be
restricted to root. This is to stop a virus vector that could attempt
to destroy older monitors. With older monitors is is possible to set
modes that will physically destroy the monitor.

> So as far as I can see, your assertion that userspace mode setting requires
> root depends solely on the assumption that it is the job of the privilege
> model to protect the hardware.  And it's not.  The job of the privilege model
> is to protect the software.

I'm also a believer in the OS being there to stop an unprivileged user
from destroying things. That includes burning out monitors and asking
a disk to low level format itself. For example, should the OS prevent
an unprivileged user from turning on disk level encryption? What if
the user is a virus and doesn't tell you the password?

> The only case I can see where you really do need to restrict this kind of
> access to the kernel is when modesetting for a given card is only available
> through the legacy x86 I/O space.  Even then that's not because it can damage
> the hardware, but because the only way to restrict access to the VGA range is
> with ioperm(3).

This is a bigger can of worms being addressed by BenH's new kernel
level VGA arbitration code.

-- 
Jon Smirl
jonsmirl at gmail.com