Re: framebuffer (was As86?)
-----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?
And if you're running from a Display Manager, it will be run as root
anyway, unless it explicitly drops it's privileges?
> 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].
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.
[1] I don't know how it could be achieved in user-mode at all, come to
think of it - any benefit you reaped from increased video acceleration
would be countered by the dramatic increase in context switches. AIUI.
- --
Graeme.
graeme+sig@mathie.cx
"Life's not fair," I reply. "But the root password helps." - BOFH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
iD8DBQE5IAiQPjGH3lNt65URAq52AKCqQwtrAsz0yA4btvsh01F/dRFLtgCfWoTo
r0GwqP61agyNLGUE1LcG8YU=
=mtLq
-----END PGP SIGNATURE-----
Reply to: