> 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/ ;-).