Re: [f-cpu] TLB right

[cedric <cedric.bail@free.fr>]

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

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

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

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

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

Cedric

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