On 995516422 seconds since the Beginning of the UNIX epoch
Charles Shannon Hendrix wrote:
>

>> Worse, because the device registers are mapped, too, and many of these
>> devices can DMA to/from arbitrary addresses, even if the kernel provided
>> a framebuffer handle this approach would *still* leave you totally hosed.
>
>How would an X program cause this to happen, even a malicious one? I
>mean outside of something like direct rendering?  What would it
>take for an OpenGL or X program to cause this?
>
>> The problem with what the XFree86 architecture puts in userland as
>> opposed to the kernel is that it guarantees that you can't have X and
>> have any meaningful kind of security at the same time.  
>
>I have meaningful security and X.  

To clarify what Thor was saying here, and to try to bring up the point about
security that most security people take for granted and most other people
simply miss:

	``The problem is not X, the problem is what the system must
	allow any arbitrary root process to do in order that if that
	root process just happens to be X it can work.''

And, to clarify that statement a little bit, there are certain memory
protections that reasonable Unices put even on root level processes, i.e.
you can't look at memory in other processes.  This protection allows a
user to safely do RSA on a machine without worrying that root might be
scanning his memory.  Or at least makes it a lot less likely.  :-)  There
are in fact a number of said restrictions on what a root process can do
and these restrictions increase as you increase the secure level and/or
tweak a few sysctl(2)s.

>> Bear in mind that on most _modern_ Unix systems, there's an effort to ensure
>> that even a rogue process running as root can be prevented from doing
>> lasting damage to the system; XFree sidesteps all of that.
>
>Off-topic, but the effort is pretty weak so far. You can cripple an
>enterprise-class Sun server with vi on a large file, let along a monster
>bug-beast like Seagate Reports. I can kill NetBSD with nothing more than
>a stream of sendmail startups.

This is a DOS not an arbitrary scanning of all memory.  Sure a DOS
is bad, but there are much worse things out there.

>> Contrary to what's been said earlier in this thread, there *have* been
>> reasonable interfaces between the kernel and X server implemented in
>> X11 in the past, with reasonable performance and without the security
>> problems of the XFree86 approach; the most obvious example is probably
>> what DEC did in Ultrix and, I believe, in OSF/1.  I realize that the
>> incredible variety of hardware that XFree86 supports makes this difficult
>> if not downright impractical, but it's silly to pretend that it's never
>> been done.

In fact, what OSF/1 does is similar to what we do for the TGA/TGA2
cards on alpha (and probably i386 after I get a peecee soon.)  The
tga driver only allows one to mmap(2) the actual graphics card
interface into userland.

This has one problem which is that one can still cause DMA to occur,
by using device registers, but the TGA2 card addresses this by
exporting two register address spaces only one of which can do DMA
(and is presumed to be the one exported to userland---I would guess
that they supplement it with a kernel PutImage-type function that
does the dithered-color-converted-scaled-DMA stuff for you.)

Unfortunately to properly export the device registers into userland
while maintaining system security the device itself has to have
some understanding of the security implications.  This is probably
not the case for a majority of the cards out there, and WinNT simply
side-steps this issue by having a kernel-level interface to the
cards.

IN RESPONSE TO OTHER OPINIONS ON THIS THREAD

``X is fast enough for me already''

	I'll actually agree that when I was doing the accelerations
	for the TGA on my multia, once I got the screen to screen
	copy done, my major incentive was gone.  It was fast enough.
	I don't really run any terribly graphics intensive
	applications---probably the most would be Netscape, or
	dvdview.  And for those simple memory bandwith seems to
	suffice, except perhaps screen to screen copy.  In fact,
	I can't think of anything that I'd really like to be able
	to run on Unix that the combination of screen to screen
	copy and a decent scale/dither/color converted DMA wouldn't
	adress.

	I have heard people talk about game support and the like,
	but let's indulge in a little realism:  implement GDI and
	Direct3d.  There is little incentive, IMO, for game
	manufacturers to port their games to Unix.  If you consider
	the game market and the gamers in it, they will in general
	conform to the OS that their games run on not vice versa.
	And with cheap peecees starting at around $300, I would
	say that if you really want that $100 game, and maybe a
	couple more it isn't much of an issue to also get a peecee.

	Or just get a dreamcast.

	On the other hand, my opinion on the game subject is rather
	slanted as I decided a while ago to not do anything
	non-productive on a computer---I spend more than half my
	life on them to begin with, I can't imagine wasting my free
	time playing games on 'em.

 == Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/  ==
 == The Unofficial NetBSD Web Pages        http://www.Imrryr.ORG/NetBSD/  ==
 == The NetBSD Project                            http://www.NetBSD.ORG/  ==
 == Ponte, Inc.                                    http://www.ponte.com/  ==