You are viewing airlied

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

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.

(Anonymous)
Older drivers

Most older cards support VESA. Would it be possible to have a kernel port for that? I don't know how well Linus would take to having an 8086 emulator in the kernel, but it can't be much worse than KVM...

(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.

(Anonymous)
Re: Just do it

It's pretty obvious that having X as root is a bad design.

Internet ---> Browser/Email/Whatever --> Flash/GTK/Gecko/QT/etc --> Xlib/DDX/OpenGL... running as root.

That's a lot of code to audit.

Especially on top of that when your taking advantage of X11 over the network. It's like taking Firefox and designing it so that it needs to run under the root user in order to render webpages. This is bad news.

(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.

Re: That's a great step forward

thankfully the problem isn't unsolveable for other GPUs, its just Intel provided the open-source driver and documentation and support first.

I'm hoping for F10 to be able to get radeon support done and nouveau are following progress of modesetting quite closely.

(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.


(Anonymous)

You are right - I'm whining more than helping but I cannot imagine Linux desktop to be alternative to MacOS or Windows when everything still works this way. And sometimes I feel sad that there are in fact many open source developers whose efforts are spent on things which are not really important in a short term.

If I'm not mistaken Glucose was meant to accelerate all X.org rendering routines, thus it could in fact make all those things faster.

we can accelerate all X.org rendering routines now using EXA, we just don't have enough drivers supporting this at decent speeds yet. EXA on ATI r300/r500 is quite fast for me now.

glucose is just an accel architecture on top of a GL driver, which basically means you can avoid writing two drivers. However most people seem to be convinced this isn't the best idea and doing Render accel with EXA specific code, or maybe doing an Render state tracker for something like gallium3D might be a more effective solution.

(Anonymous)

"whose efforts are spent on things which are not really important in a short term."


Keep in mind that the short term is only relevent for a short while. We live the rest of our lives in the 'long term'. :)

All this stuff ties together. Glucose, running as non-root, OpenGL, DRI2, Gallium3D, kernel level modesetting. The reason why they go all step-wise on this sort of thing is because if they try to 'modernize' all at once it's going to be 3 years before anybody can benefit from those improvements.. if at all. And even then it will be full of bad design decisions and bugs that would take a few years beyond that to work out.

By moving X to userspace today we gain the ability to significantly improve the security, error handling (X will have much less chance to take out a entire system), and hopefully make making quality drivers much more simplier. One step at a time.

(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... :-)

I wonder does OpenBSD have X being run as root?

Unbelievable if so. ;-)

(Anonymous)
Re: I wonder does OpenBSD have X being run as root?


For any useful acceleration they do, I think you can have a simple fbdev X that doesn't need root, but that doesn't intersect with a useful X server.

(Anonymous)
Re: I wonder does OpenBSD have X being run as root?

They do privilege separation.

Rock on!

Amazing work! Rock on! :)

Thanks for great work :)!