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

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

-----Message d'origine-----
De: cedric <cedric.bail@free.fr>
A: f-cpu@seul.org
Date: 15/08/02
Objet: Re: [f-cpu] TLB right

> Todays, linux use 1 big page for kernel, so there isn't any page miss
> inside the kernel code. That's speed up things ! If you use many pages
> to protect things, you could lose speed.

The problem isn't with the kernel page (and we can still have a big page
for 
the kernel). The problem is for user page, when you do a malloc you say
that 
the kernel can't execute them, and your kernel will be protected from
all 
attack that want to execute user code with kernel right and in hardware.

>>> Not only. Reread MISC. The last attack use a call to excve with
/bin/sh as argument. There is no malicious code executed, just a call to
a librairy. 

> Maybe, this could be used to create modules with superuser privileges.
> It could be interresting to protect kernel from a bad written driver.
> Usualy it is done by using user space. But you don't prevent anything
if
> the driver touch the tlb stuff.

That's not the problem. You can't protect the kernel from itself, and a
driver 
(in Linux) is a part of the kernel and not from the outside. We can
probably 
do a protection in kernel with a special handler for SR write in kernel
mode, 
but it's still an idea.

> I beleive it's none sense because superuser code could always change
tlb
> entries. And to avoid sending a kernel space adresse to a user call,
you

Not true, you can have a TLB handler on write that make an
authentification of 
the code that want to write data into the TLB. With a SR write handler
and a 
special TLB handler you can have a really securised kernel. 
 At least it will not cost a lot to do that, because the 2 handlers will
only 
be called when they are not in IRQ/TRAP.

>>> So you can't make "delayed" interrupt, so can't really make
preemptive kernel...or you lose time inside a kernel trap. The drivers
could also change the tlb write handler... That's juste a slide of the
problem...And you try to protect the kernel from it-self, too. Maybe we
could add an other ring to protected tlb handler ?
Antoine propose to use different load&store intructions to load user
page or kernel pages. It is a little bit like my proposal to split
load&store for managing the return stack securely. You can use a
specific return stack to avoid buffer overflow, but you could want to be
absolutely sure that the 2 stacks could not be override by using
different load&store instructions.

> only have to check the pointer MSB bit...

And only have to forgot some of them like in OpenBSD... the most secur
OS

>>> You can't prevent the mistake of all the future use of the F-cpu !
Beleiving that the hardware will do all the job for you is a dream of
progammer, but not a reality ! HW+SW are design to realise a task, the
faster, the cheeper, the more flexible way they can. The RICS adventure
said to use more the SW and speed up dumb thing in the HW and do the
clever thing in SW. 

> > So if we port an OS,
> > we need to do a lot of change, and we can forget some of them (like
the
> > last local bug in OpenBSD).
>
> Every kernel call should be check, so what ?

If in OpenBSD they have forgotten one, they can forget it in other OS,
so more 
security you have better it is. And it's easy to write a TLB handler and
a SR 
handler than to modify all the kernel call and not to forget any of
them.

>>> We can't work to avoid future possible mistaks of OS writers !! We
try to give enough tools to do it cleanly (and not by trying to
*emulate* the none excution bit of the stack).

Cedric
----

>>> I try to resume what we want to avoid :
1- give kernel page to kernel function call to access kernel page from
user process.
2- execute user code in kernel mode 
3- execute librairy call to execute excve with /bin/sh to have a shell
access.
4- diseable any possiblity of buffer overflow.
5- Protect part of the kernel (driver) from it-self

My proposal :
1- memory check by the OS like today's OS.
2- I can't see how it could possible.
3- if buffer overflow isn't possible any more, this problem is over,
too.

4- You can split the return stack of the function, and use specific
write instruction to write on this stack. Such instruction are placed by
the compiler at the call of the function only, so typical strcpy() could
not be used to scratch this area. Maybe this could be done by a "tagged"
memory (a flag in tlb and in the instruction write) and could be reused
for split user from kernel pages.
But there is always the problem of function pointer (i hate C ! ;p).(the
pointer could still be overridden by buffer overflow, we could try to
make 2 indirections to use such pointer (the pointer are a pointer to
the table of the pointer of fonction). We could also try to put the
pointer before any array in a function. And we could use a canary, it's
a random number put before any function pointer, if this number change
the program die. It's very hard for a buffer overflow attack to preserve
the canary but always possible)

(our main discussion)
5- Could be an interresting feature, but most of the time the OS use
user land to do it. Maybe we could use the idea of the "tagged" memory
and "tagged" write.


______________________________________________________________________________
Pour mieux recevoir vos emails, utilisez un PC plus performant !
Découvrez la nouvelle gamme DELL en exclusivité sur i (france)
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/