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

["Nicolas Boulay" <nicolas.boulay@ifrance.com>]

-----Message d'origine-----
De: Michael Riepe <michael@stud.uni-hannover.de>
A: f-cpu@seul.org
Date: 07/08/02
Objet: Re: Rep:Re: [f-cpu] TLB resume

On Wed, Aug 07, 2002 at 07:31:40AM +0000, Nicolas Boulay wrote:
> -----Message d'origine-----
> De: Michael Riepe <michael@stud.uni-hannover.de>
> A: f-cpu@seul.org
> Date: 07/08/02
> Objet: Re: [f-cpu] TLB resume
> 
> On Wed, Aug 07, 2002 at 12:54:32AM +0200, nico wrote:
> [...]
> > > If supervisor mode is allowed to always access everything, you
have
> a
> > > big security hole.
> > 
> > Could you explain why ?
> 
> Because when a user process calls the OS kernel, the system call is
> executed with supervisor access rights. That is, you can take an
address
> that you're not allowed to access and pass it to the kernel, and the
> kernel *is* allowed to access it. You'll have to add rather expensive
> memory bounds checks to almost every system call in order to prevent
> that.
> Sacrificing three bits per TLB entry is cheaper (and more secure).
> ---
> >>> ??? In an adress space, the process could see what ever he want.
> Kernel are just mapped in the same adress in each AS to avoid trashing
> of the caches. (Christophe speak about a "global" that come from the
x86
> world. It say that virual adresse is OK for every AS. It avoid tlb
> miss.)
> 
> In the AS, there is only data relevant to the user, to the librairy
and
> to the kernel. Kernel page have none of the RWE bit set. To change the
> ring (pass from the user mode to the superuser one), you need
something
> as trap, a specific call using vector adress. The adress are well
known
> and defined as OS call.

[hacking tricks deleted]

You forgot some: User processes may try to modify kernel pages, or let
the

>>> They can't. They doesn't have write right on the kernel pages.

kernel execute arbitrary data. 

>>> Impossible ! OS call are made thought somethink like interrupt and
the use of a vector table. Only API could be called that way.

Note that we're not talking about becoming
`root' (which also runs with user privileges) but compromising the
kernel.

>>> Even with stupid right on x86 you can't compromise the kernel code.
user process have no right on the kernel pages.

> Our API are very less smart for crackers than those from x86. Most of
> the time the return adresse are on the register set. Because we need
for
> none leaf function to save the return adress, i have proposed to use a
> specific return adress stack that could'nt be erased by buffer
overflow.
> 
> I don't understand why we need 3 superuser bits for that. The process
> does not know about other AS and kernel page could not be accessed. So
?

Because user and supervisor mode should have an independent view.

>>> You don't convince me. You're protection scheme unallowed the kernel
to touch to some user page. But kernel have the ability to change the
content of the tlb. So it could change it's own adress right. So ? 

Your assumption is wrong. When the kernel executes a system call (on
behalf of a process), it will run in the processes AS but with
supervisor
privileges. 

>>>Yep !

If you only make a difference between `user' and `supervisor'
pages and allow supervisor mode to access user pages regardless of the
permission bits in the TLB, you have a problem.

>>> Nop ! Give me an exemple.
nicO

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



______________________________________________________________________________
i (france), c'est aussi une gamme complète de PC en exclusivité avec DELL 
http://www.ifrance.com/_reloc/signhdell

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/