?

Log in

No account? Create an account
airlied
airlied
:.:..:.
airlied [userpic]
running X as non-root - almost like the future or something...

So X servers run as root, and this isn't good, for many many reason, and it wasn't always this way on other UNIXes.

So as part of my quick hacks work I got an accelerated X server on intel hw that ran as a user today.

The hacked up patches were around 300 lines total, one bit in the xserver, lots of non-root ioctl hacks to the drm and the intel driver had to register it wasn't a hw driver with X, and then fix up its buffer allocations to be non-evicted.

Surprisingly it mostly seems to work, I can start the server + gnome-session + DRI2 + compiz + glxgears on a cube, granted it oopses soon afterwards but it does show we are very close to realising the dream.

The xserver patch is in master, the drm patches are in modesetting-101 and the intel hacks are in the intel-kernelmode branch of my personal repo, as they are very hacky.

Lots of things need to be fixed so this can be done properly but it nice to just see what it looked like e.g. the frontbuffer isn't pinned properly or the cursors etc.

I have to log in on the console on vt2 and then run the following.

/opt/xorg/bin/Xorg -logfile ~/xorglog -sharevts -novtswitch vt02

Granted I'm not sure how reproducible this is, it was afternoon hacks to get over the F9 bugfixing :)

Comments
Page 1 of 2[1][2]

Will this only require changes to the X stack or will other applications have to adapt to X not running as root?

no its purely on the X server side, no X client apps should ever need the server running as root, except security exploits :-)

(Anonymous)
What about proprietary drivers ?

If I unterstand, there are some changes needed on video drivers to make Xorg run as non root, isn't it? (and the DRM).

So what about proprietary video drivers? (like nvidia) Is there a risk from them to "slow down" the process of making Xorg running as non root? Because many distros can't really ship a non-root Xorg if some video drivers can't do it this way... (except gNewSense :-))

Re: What about proprietary drivers ?


I can't really say. I don't ever factor their existence into anything I do.

We'll also have lots of older X.org drivers for which nobody is ever going to port to kernel modesetting so they face the same problem.

It'll be most likely that gdm or something will need to know if the X server can run as non-root or not before starting it.

Fedora would be quite happy to ship a non-root Xorg as it saves us a lot of security holes, and we don't ship binary drivers, but we do have to worry about older drivers. Perhaps eventually we will get most useable chipsets moved over.

Older drivers - (Anonymous)   Expand  
(Anonymous)

wow...

Fucking champion. I thought it'd be at least another year or two before this saw the light of day.

I've got to say I'm impressed. I didn't think this was coming for quite some time (2 years or so). I guess this is just another post of encouragement saying "keep up the good work!".

(Anonymous)

By the way, have you considered adding your tree to linux-next? I run it, and i'd be happy to try the TTM stuff :)

(Anonymous)

Is there any word if this will be included (once the quality has been improved)?

(Anonymous)
Just do it

Create an exploit, a live working exploit that will effect the xserver, and I may bite and say this is needed. Until that day comes, nice experiment.

Re: Just do it

we have a fair few of them, we fixed them a lot and release security updates.

lots of X.org security updates are for priv escalation type things, granted they have a lot of DoS as well.

Re: Just do it - (Anonymous)   Expand  
(Anonymous)
Good job!

I think that running as a user is the right way of running X. Linux is so much layered and that was a missing piece.
Keep up the good work

That's a great step forward

Wow, this is huge! you appear to have solved a so ancient, so long standing problem on x86 (and amd64 and ppc right ?) linux desktop! Thank you so much.

Now, I hope someone will find, at least in the long run, a way to adapt/redo this in a clean workable/mergeable way. It maybe will take some time, but still this first step is so exciting!

(Anonymous)
Re: That's a great step forward

In fact this problem has been solved only for Intel GPUs.

(Anonymous)
Amazing

Keep up the good work :D

X rocks! :D

What about DMA?

Isn't it a bit dangerous to give non-privileged users access to hardware devices that can DMA to and from arbitrary physical memory locations?

I was under the impression that this was one of the reasons that X ran as root. Or do you have some way of intercepting all of operations that the user process sends to the hardware in the driver to validate them?

Re: What about DMA?

the X server is now just a DRI client, the validation is pretty much the same in the kernel. The kernel has object handles for every piece of info in memory and only allows transfers in/out of the objects the server has access to.

Lots of new hardware also has features to make this stuff a lot easier.

(Anonymous)

Glucose (http://www.osnews.com/story/15511) - is what *really* important now. XServer is still magnitudes of order slower than Win 3.11 GUI.

Windows' resizing, windows moving and windows repainting still resemble a slide show.

And you are making XServer run under not root user ... Is it that crucial?

// Artem S. Tashkinov

and you are helping how?

if you understood what glucose was you would know its not going to help make the server faster, and it really won't help resizing... so it isn't important to work on.

There are other people in Red Hat working on making X go fast my job is to work on making a proper GPU architecture for Linux, which includes making X not run as root.


(no subject) - (Anonymous)   Expand  
(no subject) - (Anonymous)   Expand  
(Anonymous)

Hi. So you are the Linux developer, and this work is primary aimed to be used under Linux systems... But waht is you version about it cross platform use? Do you code implements this functionality using Linux specific calls/etc? Can it be merged into main X.org code tree and later ported into BSD's for example? Thanks.

the code should be portable in theory if other OSes have developers interested in doing the work. All the new code in the DRM is MIT licensed.

however I think BSDs will need some quite serious work by a few committed folks to get any of this stuff working. Thats fine they don't lose anything, they just stay where they are.

But I've no intention of holding Linux back to wait for other OSes to catch up, they can stand on their own two feet if they are serious about it.

As far as I understood your patches are not available to the public. Do you plan to publish them?

The xserver patch is in master, the drm patches are in modesetting-101 and the intel hacks are in the intel-kernelmode branch of my personal repo, as they are very hacky.

(Anonymous)
Great work!

This is just awesome Dave! Keep the patches coming... :-)

Page 1 of 2[1][2]