Re: SVGA kernel chipset drivers.

Albert Cahalan (albert@ccs.neu.edu)
Fri, 7 Jun 1996 14:30:16 -0400 (EDT)

From: Kenneth Albanowski <kjahds@kjahds.com>
> On Thu, 6 Jun 1996, Jonathan H. Pickard wrote:
>
>> Okay, that _might_ handle security, if you have a daemon of some sort that
>> sits there and monitors those port accesses. It certainly does not address
>> performance (made even worse by the fact that the programs now talk to a
>> daemon, which now lessens the burden for security on the device driver), the
>> ability of any schmoe to cat something evil into /dev/ioports, the need for
>> the graphics-using program to be setuid root (at least partially) to get
>> access to /dev/ioports, cards that has resources outside the "likely"
>> address space, or multiple VC's _at all_.
>
> I think you missed one think: the driver itself would perform locking.
> Only one task could open "/dev/ioports" (or whatever) at a time. No
> deamons, and no schmoes allowed, assuming that something has already
> grabbed the driver.

It is not good if only one task can use video. We can switch VCs while
in text mode, and graphics mode should not be any different that way.

> As for cards with resources outside the "likely" address space: obviously
> this can't be guessed. So a program would have to open up /dev/ioports,
> play around with the card enough to figure out what resources are needed,
> and then tell the driver to allocate those resouces.

So I tell the driver "I want these really nice ports HERE." and it
gives me the IO ports to control the ICBM launch controller.

> As for multiple VC's, I don't think this would be a problem. Two programs
> cannot control the video card simulatenously. So to perform a cross-task
> VC switch, the first task would close /dev/ioports when it gets told to
> background itself, and the second task opens up /dev/ioports when it wakes

What if the task is stuck in for(;;)? What if it is malicious?

>> No need for this to be in the kernel; a simple daemon with
>> iopl() could do it as badly (and, with a different design,
>> could do it better).

The daemon won't work unless it knows the complete video state.

> Indeed, since this mini-video-driver approach wouldn't help the kernel
> shift back into textmode (and perform similar tricks) there isn't any
> need to have a kernel driver in the first place...

Wrong conclusion. The mini-video-driver is not adequate, so we need
full video support. Locked up consoles are OK for Linux 0.99.pl15,
not a modern Linux. There are enough Linux programmers now to make
a large video project possible. XFree86 is a temporary solution.