[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
kernel execute arbitrary data. Note that we're not talking about becoming
`root' (which also runs with user privileges) but compromising the kernel.

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

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

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