Messages in this thread | | | Date | Sun, 29 Mar 1998 04:39:07 +0100 (BST) | From | Chris Evans <> | Subject | Re: GGI and cli/sti in X |
| |
On 29 Mar 1998, Linus Torvalds wrote:
> 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
| |