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

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



Well for other reason, I'm not against those three bits sr,sw,sx since it
can help even for the kernel to separate data and code pages.

An example for "pipe" :

For different AS, we can even a write-only page for one process and the same
page as read-only for the other process for a memory pipe (indeed we need
for one process at least two pages, one as read-only and the other as
write-only, while the other process have the same pages but with inversed
rights).



----- Original Message -----
From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>
To: <f-cpu@seul.org>
Sent: Friday, August 09, 2002 10:26 AM
Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume


I would like to have the opinion of Christophe or Cedric but it seems
that they are in vacation.

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

On Fri, Aug 09, 2002 at 12:52:33AM +0200, nico wrote:
[...]
> > Consider this system call:
> >
> >         read(fd, &kernel_page, page_length);
> >
>
> Why you're read can't check if the given pages are a real user one ?
> It's easy under linux 0-2Gb is for process, 2-4 Gb AS is for kernel.

It's not always so easy. You'll have to check the memory mappings of
the user process (in software) which may become quite expensive.

>>>It's not easy it's a choice of the OS designer. If the split is so
strong it's to ease this kind of test. And in this case, it cost almost
nothing.

> How you're 3 bits right for superuser could avoid this ?

By turning off supervisor access rights for pages that are mapped in
user
mode (or maybe set the supervisor privileges to the same value). If the
kernel is really going to do something that the user is not permitted
to do,

>>>Usually it the kernel code that decided what could be done by the
process. Checking it's input must be done. Most of the time the process
could only annoying it-self, there is no real probleme of protection.

it will have to a) temporarily raise its own privileges, or b)
establish its own TLB entry with appropriate access rights (but its
own ASI).

>>> Kernel does not have it's own ASI. It is in the memory space in
every process.

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.

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.

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

nicO, who need a lot more precise explanation.

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

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