[rsbac] A few comments/questions on RSBAC

[Amon Ott]

On Mittwoch 06 Juli 2005 18:22, tvrtko.ursulin at sophos.com wrote:
> [btw, kernel 2.6.11, RSBAC 1.2.4]
> 
> I just started looking at RSBAC two days ago so excuse me if 
something I 
> say might be completely wrong.
> 
> 1. There is a rsbac_kmalloc function which allocate in this way:
> 
> #if KERNEL >= 2.6
> kmalloc(size, GFP_ATOMIC)
> #else
> kmalloc(size, GFP_KERNEL)
> #endif
> 
> Why? It looks totally wrong and extremely hackish. It also leads me 
to 
> belive that request hook must not sleep, which I have confirmed with 
> kernel debugging options. Of course, because of that, the whole 
usability 
> is questionable.

Why do you think that requests must not sleep? They may and do, as you 
show yourself under 2.

Only list operations with spinlocks held must not sleep. rsbac_kmalloc 
is mostly called from list functions, which hold a spinlock when 
adding or removing items. In 2.6 memory allocations with spinlocks 
held must be with ATOMIC. In 2.4 it works very will with normal 
GFP_KERNEL.

There are some other uses of rsbac_kmalloc, and it might save some few 
processor cycles to change it to GFP_KERNEL when a function is not 
spinlocked. However, this never really seemed an issue.

> The comment for that function is also wrong, it says that it will 
always 
> allocate GFP_KERNEL.

Sorry for that old comment... I updated it in my tree.
 
> 2. However, DAZ module which is shipped together with RSBAC does 
sleep in 
> it's request hook by waiting on a event, of course it will do that 
since 
> it must communicate with userspace.

Yes, it does.
 
> 3. DAZ subdirectory also holds two completely identical files, 
> dazuko_rsbac.c and dazuko_main.c. One of them is not used. There are 
more 
> unused files in there (FreeBSD?!).

Yes, this is to easily maintain the same code base with original 
Dazuko. Delete dazuko_rsbac.c, if it annoys you.
 
> 4. RSBAC source code is full of enums, unions and structures named 
like 
> struct rsbac_something_t. They are not typedef-ed, so why they have 
_t 
> suffix? I thought that it is a convention that typedef-ed type 
should have 
> _t added to them and this is confusing.

Conventions differ between coders. I guess I broke several conventions 
of Linux kernel hacking, because using my own coding style lets me 
code significantly faster. This may lead to some confusion for 
others, but on the other hand many people said they liked my style 
better. :)
 
> Having noticed all this by only briefly looking at the code, how 
mature 
> and stable do you consider RSBAC to be currently? Especially on 2.6 
> kernels?

I do not use the experimental 2.6 kernels on server systems myself, 
but experience by others and on my workstation shows that RSBAC is 
pretty stable there, too. On 2.4 it has been rock solid for me and 
many others for a long time, except for the odd glitch in pre 
versions or unusual cases.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22