Re: Pentium emulation

Pavel Machek (
Tue, 29 Jul 1997 21:33:10 +0200


> 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

> 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.


I'm really 	   Pavel
Look at ;-).