> Quite frankly, I will continue to consider the "nuke the whole thing"
> proponents to be of questionable intelligence until somebody shows me a
> bug that is so fundamentally big that we'd better use a few tactical
> warheads. So far people have shown me a lot of ants.
Here's a "bug": the general concept of a user level program doing port
hacks/iopl(3)/etc. It should not be allowed. If we get on theoretical
highground we could moan about it being the kernel's responsibility to
manage hardware. But I'm not going to whinge about that.
What I _am_ going to whinge about it the impact of X's broken userland i/o
port hacking on trying to implement "securelevel". To be secure,
securelevel when enable must disable port-io and iopl() for userland
processes. This breaks X. And it's not the securelevel conecept that's
broken, it's X. If the hardware management were where it theoretically
should be, the kernel, I could happily enable securelevel, feel safe that
hackers can't erase their tracks even if they break root, and STILL USE X.
Note: I'm not too impressed with GGI either, they've aimed too high, tried
to redesign too much thinking their way is 'better' when it isn't, etc.
They have however written some drivers. I doubt it would be much work to
pilfer these and get X running non-suid, once we've got support for
a) ioctl(mode_change) b) ioctl(gimme_a_mmaped_buffer)
c) ioctl(mmap_me_mmio_regs)
And finally, and I'll shout this: "IF ITS TRUE THE NEXT GENERATION OF
VIDEO CARDS WILL HAVE NO TEXTMODE THEN THE KERNEL will NEED TO KNOW HOW TO
CHANGE INTO A GFX MODE". Even if we use a VESA bios hack, that's still
mode-setting code going into the Linux sources :)
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu