Xegl lives!

[Jon Smirl]

On 5/29/05, Adam Jackson <ajax at nwnk.net> wrote:
> On Saturday 28 May 2005 11:25, Jon Smirl wrote:
> > EGL provides a user space API for mode setting. It is up to the
> > implementer to pick you to implement it. In my case I am trying to fix
> > the Xserver to not run as root. So I pushed mode setting down into a
> > device driver.
> >
> > Someone else may chose to implement mode setting in the user library.
> > Since setting a mode requires root priv this implies that your server
> > will have to run as root.
> 
> You're predicating this on the assumption that the ability to break broken
> monitors even further has something to do with the unix privilege model.  I
> remain thoroughly unconvinced of this.

During boot a hotplug driven, root priv app reads the DDC from the
monitor. This DDC info is merged with user adjustments from /etc to
end up with a list of valid modes.  The /etc merge is used to adjust
for broken monitors. This list of valid modes is stored in the driver.

User priv apps can read this list of valid modes and then pick one and
set it via a sysfs variable. User priv apps can not set arbitrary
modes. If you want a non-standard mode you need to be root so that you
can edit the /etc file and add it to the list. Code for doing all of
this has been in the Linux kernel for about four months now but it
still has a few issues.

Disconnecting the monitor and reconnecting it triggers a hotplug event
which causes the mode list to be rebuilt. But this is not a common
case.

> And you really are wishing the problem away, unless you can guarantee that the
> registers controlling mode setting never get mapped into userspace, and that
> the DMA you trigger from the DRM never writes to those registers.  Can you
> make that claim?

Anyone with root priv can map anything they want on the system and
bring it down.

I am slowly working my way through the user space DRI code and
removing the need to access registers. Until those accesses are
removed the DRI code still needs to run as root. Once those access are
gone I can remove the ability to map the registers.

The model is simple: anything that touches the registers has to be in
a device driver where it can be audited and protected. Doing this lets
the rest of the code run in user space. DMA is triggered via the DRM
driver which contains command verification code.

-- 
Jon Smirl
jonsmirl at gmail.com