> On Tue, 11 Aug 1998, Tigran Aivazian wrote:
>
> >Hello guys,
> >
> >Yes, it *is* very much a kernel issue. What happens if you kill -9 the X
>
> It' s not a kernel issue.
Unfortunately for us, that's true.
> If the X server run in iopl() and own the video
> card, _it_ must care that everything will return OK when it' s killed.
Yes. But this is not a simple problem, to put it mildly. See
below.
> It' s possible using a X wrapper that run as root (not as user) and wait
> for the child to die (once the X child is died the wrapper can restore the
> text console fine).
Not in all cases. There is no magic way to reset any video card
into a known good state, no matter what state it is currently in. This
can only be done if you know what state the video card is in, and only the
X server knows that. Therefore, the X server *must* clean up the hardware
state before it is killed. And that requirementopens up a whole can of
worms.
> >server? The machine hangs because the kernel does not sanify the
>
> The machine doesn' t hang.
In most cases. Not all. I have locked my machine hard by killing
the X server. It usually doesn't happen, but occasionally it does. In
particular, most video cards do not take well to being interrupted midway
through an accelerator command FIFO fill. Other cards have wierd timing
issues, and still others may be capable of bus mastering and if the card
is not told to relenquish its lock on the bus, the machine will hang. In
general, there are many cases where atomicity must be preserved during
video card programming. XFree86 is not designed to have to worry about
this, and neither is Linux.
This is another illustration of why userspace video drivers can
never be made to work 100% properly and reliably. Just giving iopl()
privs to a task isn't enough. You also have to ensure atomicity of
hardware programming and coherent maintenance of hardware state knowledge.
XFree86 isn't set up for this because it isn't designed to be preempted.
It controls VC switches, which allows it to cleanly hand off control of
the video card to the controller of another VC, be that SVGALib or another
X server or the kernel itself. It can execute the VT switch after card
programming is finished.
But if the X server must respond to a kill -9 in the same manner
as other tasks, it cannot guarantee atomicity and coherent state anymore.
A signal handler would have to be able to finish whatever programming was
necessary to bring the hardware to a known sane state, no matter where the
original programming was interrupted, which is basically impossible.
Nothing but a scheduling lock around the critical sections will do, to
ensure that the signal cannot be recieved until it can safely be handled.
Coding such locks would entail a massive amount of recoding of XFree86's
driver structure to avoid having to throw locks around a lot of code that
wouldn't need them. XFree86 is not designed to have to worry about this
issue.
I don't know how an suid root program would go about doing this (I
am assuming that this is possible in the first place), but let's assume it
is done. Now, when the X server's VC is active, you have it preempting
the scheduler every single time it needs to fire an acceleration. This
loses you the benefit of using hardware acceleration in the first place,
which is that the accel op can run in parallel with the CPU. Also, you'd
better not be trying to run anything timing-critical in the kernel or
userspace, because all those scheduler locks will suck up a lot of CPU
time and may throw off existing kernel timing guarantees. Packet loss,
here we come! Fire up a bunch of X apps which use XAA and watch the rest
of the system come to a grinding halt. Fun fun fun.
You could get around this problem by coding into the kernel a
special process type for the X server. The kernel would either have to
block signals (some or all) from the X server process, or it would have to
thunk the appropriate signals into a fake VT switch notification/kill
signal combination. That last, grotesque hack though it would be, might
be the easiest solution to this problem. I don't know for sure. What I
DO know is that whatever the solution, it involves giving the X server
even more kernel-level powers and responsibilities (special signal
handling or scheduling manipulation) in addition to those it already has
(direct IO port access, raw keyboard access, VT switch handling).
But sooth! Look at fbcon! Critical sections are not a problem
because the drivers are in the kernel and are not tasks, subject to
signals and scheduling. Maintaining coherent state is not a problem,
because of the same reasons. No special permissions are needed, because
the code is a kernel device driver. VT switching coordination is not an
issue, because that is handled elsewhere. Everything just works right
from the get-go, and if it doesn't you have a hell of a lot less code to
wade through to fix the problem. Your X server can be just another task,
too. Funny how **ALL** problems associated with suid root graphics apps
just melt away in the sun.
You _can_ ensure safety with less in the kernel than KGI or even
fbcon has. But you **MUST** have hardware locking, access control and
state maintenance in the kernel, with each device controlled by one driver
and no other code. Nothing else can guarantee safety and consistency of
behavior. In the stacksmashing thread, I claimed that suid root code, if
it must be used, must take responsibility for ensuring that it does not
compromise the stability or security of the system. XFree86 CANNOT DO
THIS BY ITSELF. It doesn't have the needed tools, even with suid root
privs.
Either use XF86_FBDev, do a massive recoding of both XFree86 and
the kernel, or live with the possibility of crashes. There aren't any
other choices.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html