Re: framebuffer (was As86?)
This is rapidly drifting off-topic, but...
Graeme Mathieson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Adam C Powell IV <hazelsct@mit.edu> writes:
>
> > There are other reasons to use the framebuffer, like security: if you
> > have untrusted users, you only need to audit the small bit of code in
> > the fb, then you can run X non-suid, instead of counting on all of X
> > to be free of security holes.
>
> Granted. That's quite an important issue. Although, AIUI, the Xserver
> is now run from a wrapper which drops root privileges anyway does it not?
I don't know, is it possible to access hardware without root priviledges?
> And if you're running from a Display Manager, it will be run as root
> anyway, unless it explicitly drops it's privileges?
AFAIK you're right, to take advantage of the non-root X, there would have to be
changes made to *dm.
> > Also, a correction: X on framebuffer *is* accelerated for many
> > chipsets, primarily for those arches which use framebuffers
> > exclusively, like PPC (e.g. there's atyfb and clgenfb acceleration
> > support in X; Debian uses fb exclusively though there's also Xpmac).
>
> Ah, yes. I should have qualified that with 'In terms of the x86 ...'.
> ISTR Linus has specifically stated that acceleration code will never make
> it into the kernel, as that's a user-space issue. I don't know however
> if the current architecture allows acceleration to be handled in
> user mode[1].
Whether that's true is a matter of definitions. The acceleration of Xfb is
specific to a given board and requires calls into hooks in the fb kernel code.
In 2.4, the hooks will be more uniform across the fbs, making it a ton easier to
accelerate Xfb for a wider variety of boards... which has to be done all over
again for X 4.0 (where AFAIK there are no accels in the fb backend yet :-). So
some of it is in the kernel, and some in userland.
> You're right. It's heading in the right direction. What's the architecture
> of XFree86 4.0 in terms of security? I've heard good things about the
> performance, especially for DRI-related work.
All I know about 4.0 is what I've heard second-hand...
The security of the DRI stuff is what I was talking about in the last post.
There's been a little debate on the linux-fbdev email list as to whether
framebuffers should be allowed to be opened more than once. DRI requires "yes"
with userland locking to prevent conflicting commands from being sent to the
accel engine, but this comes at the cost of allowing other users to access the
accel engine, access which could trivially be used to crash the card.
At some point there will be a kernel patch with the single-open approach (one
open per card, that is) and /dev/gfx to abstract access to accels, and maybe it
will get into 2.6 as an option. If it proves to have equivalent performance to
today's DRI, then the extra security will eventually make this approach "win".
This is my last post to this list on this topic; unfortunately the only
documentation for this stuff is the fbdev list archive at
http://www.linux-fbdev.org/ .
Zeen,
-Adam P.
Reply to: