Messages in this thread | | | Date | Tue, 29 Jul 1997 21:33:10 +0200 | From | Pavel Machek <> | Subject | Re: Pentium emulation |
| |
Hi!
> The issue with kernel threads is that they share the same address space, > which means that one thread can change the mapping of another thread in > the middle of some operation. > > In particular, one thread can change the mapping of another thread in > between that other thread testing the i386 WP bit by hand and actually > writing to the page. It's a small window, and probably _very_ hard to > actually take advantage of, but it's there.
Hmm, would not that be solved by placing cli()/sti() pair in there? If it is small window, this will not hurt that much, no?
> I'd be more than happy to say somewhere that "a i386-based machine works > fine, but you shouldn't NOT allow logins on them in security-conscious > areas".
And you should not allow cgi scripts. They are dangerous even running as nobody. And yes, buffer overflow in forum server running on nobody can be fatal, also. :-(.
> There are other reasons for not using i386-class machines: most of the > 386's that I've seen had the so-called "popad bug". The popad bug is > deadly in protected mode - in real mode it only trashed the %eax register, > but in protected mode will actually lock up the CPU under the right > circumstances.
There's probably no way to defend this one :-(. Popad is clearly fatal, and clearly bug. WP bit behaviour was ment to be this way. It probably is broken. But this WP bit behaviour should be at least work-aroundable.
> I haven't really considered this to be a Linux problem - both of the > problems are due to hardware bugs (although the WP bit behaviour is > classified by intel as a "feature"). And if you allow interactive logins > to your machine, you probably want to have more horsepower than a i386 > will give you anyway.
Problem is, that some programmers expect that if daemon is running on nobody, it can do no harm... But yes, this probably is not _real_ big problem (I have not seen exploit on bugtraq, yet :-).
> I also wouldn't consider this a problem on a portable computer: it really > is a problem only for computers where you allow foreign logins from people > you don't trust. If you give a portable computer to somebody, you > implicitly trust them with the hardware (and any software measures are > moot at that point with any portably _I_ have seen so far).
This is not issue if you connect your portable via ethernet to really big network. I like to provide guest account...
> Note that a cracker cannot misuse the i386 bugs without being able to run > his own programs on the machine. He has to be able to run a program he has > written (because none of the standard installation programs will even try > to do anything nasty).
Hmm - buffer overflows are too common to say this.
Pavel -- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
| |