lkml.org 
[lkml]   [1998]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: GGI Project Unhappy On Linux
On Thu, 26 Mar 1998, Richard B. Johnson wrote:

> Since the X-Server is BIG, it operates entirely in user-mode. The
> kernel just lets it have access to the graphics chip registers and
> screen RAM. There is no security problem that an alternate interface
> would eliminate.

_This_ is the key statement, as far as I'm concerned. The kernel does
_not_ "just [let] it have access to the graphics chip registers and screen
RAM". It gives X complete access to all system functionality (via the
graphics chip registers and screen RAM, most likely), the ability to
cli/sti, and other various things needed to manipulate the hardware.

Personally, I don't really care which of KGI/GGI/FBCON/whatever comes to
the fore, just as long as it is fully functional (how many different times
are people going to rewrite SVGALIB?), and fully reliable. I'm quite sick
and tired of being able to crash a PC by quicking switching to/from X, and
_that_ is what KGI stands to improve.

Some time ago someone else drew the analogy of controlling a SCSI adapter
via user-code, vs. a kernel driver, and I feel the analogy is quite
appropriate. _Yes_, there is a wide variety of SCSI controllers, some of
them much worse then others, and yes, there is a wide variety of devices
that can be connected to them, but nonetheless reliable kernel drivers
(that even reset themselves automatically!) are possible. The same should,
_and must_ be available for graphics drivers, if only to match Windows in
reliability.

Another reason for KGI (or a similar project) is the complete support for
binary-only drivers, which is probably the only way to woo the
manufacturers of WinWhatever hardware.

> Further, an alternate interface adds another layer of code between the
> real hardware and the User Interface. User's of graphics-capable
> machines won't accept a slower write to the screen for some alleged
> improvement in 'security' If you have physical access to a machine,
> there IS no security period. Use of the graphics capability of the
> machine requires physical access.

I can only disagree. I have complete physical access to my machine.
(Indeed, if I wanted to, I could use a development machine that I probably
could rebuild from scratch.) Nonetheless, I would most certainly accept
slightly slower screen writes in exchange for an 'alleged' improvement in
security.

Likewise, I normally use machines with MMU exception handing, operate my
machines as non-root users, with IO perms disabled, and without
permissions to access to raw disk partitions, for an equally 'alleged'
improvement in security.

To put it in different terms, just because I have the physical ability to
rip my CPU and hard drives out of their case, and jump up and down on them
until they are ground into shards does not mean that I desire the programs
I regularly use to have the same ability. In all sincerity, I would
suggest that Windows follows the model of "physical access = why bother
having security", a model which we are trying to avoid.

To put it in more concrete terms: _all_ recent crashes of my computer have
been related to X. A few of those crashes were complete deadlocks, more
were ones where the display adapter simply refused to display anything.
_All_ occurred on transition from X, and _none_ were recoverable without
rebooting (cleanly or not). I simply am interested in removing the source,
and future possibility, of those crashes. Yes, X clearly is buggy in this
instance, but that should no more place the kernel in an unstable state
then a buggy GCC or EMACS.

> Were are talking about PERSONAL computers here, not some secure
> server locked away in a room.

The difference, please? (Other then the obvious one that people won't be
playing games on the server's console.) How, fundamentally, is Linux
different from the OS running on that secure server? Or is it only that
human-interface hardware is assumed to be "less important" and less
reliable then computer-interface hardware?

I'm using Linux (and contributing to various development efforts)
primarily because Linux is a development platform that _does not crash_.
Period. The Mac crashes regularly. So does Windows (any variety). Linux
does not. _Except for X_.

This is the sort of discussion where I feel the words "this is
non-negotiable" floating in to mind.

--
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.202 / U:22.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site