Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume

[Michael Riepe <michael@stud.uni-hannover.de>]

On Fri, Aug 09, 2002 at 08:26:50AM +0000, Nicolas Boulay wrote:
[...]
> >>> Kernel does not have it's own ASI. It is in the memory space in
> every process. 

That depends on the OS.

> Note that it may be possible to use a single set of access bits - if
> they are valid for both user and supervisor mode (I'll have to think
> that over). 
> 
> >>> there is always the same conceptual probleme : the kernel decide the
> right to put in the tlb. It's one of it's role. Usually kernel is always
> trusted.

And exactly that is the problem.

> But `supervisor mode is allowed to access everything' is a
> BIG mistake.
> 
> >>> Maybe. x86 is a big shit in this topic, but i have never heard about
> tricks to compromise the kernel that way. Kernel hacker meet at lsm does
> not speak about that (grsecurity patch maintainer (who mainly try to
> simulate a true none executing bit in x86), VM designer of the hurd).
> Maybe you discover a new concept of cracking. But i think it's really
> easy to verify the pointer given by the user process.

Depends on the OS, again.

> >>>Because the kernel is trusted, i can't imagine that you could
> compromise it's security by a call to it's own API. Because kernel could
> change the right in the tlb it could access what ever he want. If you
> want to make things like chmod (that could unallowed to access a file
> but a run of chmod could change that), how could the kernel be run
> without virtual adress. I think that should be done during task switch
> (christophe ?).

*Because* the kernel ist trusted, it is one of the main targets for
attacks. If you manage to hack the kernel, you can do everything
(compare root kits and `trojan' kernel modules). Therefore, the kernel
needs *more* protection than a (user) process with root privileges,
not less.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/