logo       

performance tests: kernel obj ->security sharing: msg#00008

linux.kernel.lsm

Subject: performance tests: kernel obj ->security sharing

Attached are a series of patches and performance results I had
promised some time ago, comparing two methods of allowing stacked
modules to share the kernel ->security objects like inode->i_security.
The first, identified as chaining in all the patches, redefines the
security objects to hlists, which lsm's can attach and detach objects
to. The assumption is of course that they will use objects of a
common format containing a hlist_node and a unique (per LSM) id. In
the attached patches this is the "struct gen_struct". The second
method, referred to as builtin, redefines each ->security object to
be an array. Upon module registration with mod_reg_security, a
negative return value still means an error, while a positive value
defines the index into the array to be used by that module.

I also plan to test a third approach, which gets rid of the security
objects altogether, replacing them with a global lsm hash table.
A module will call get_security_object(void *, int module_id) and
set_security_object(void *, int module_id, void *) where the first
argument is the inode, superblock, file, etc.

The modules used for testing were, in order:
stacker
bsdjail
digsig
dte

I ran lmbench four times, and unixbench three times, under a jail in
the root domain, where all installed libraries and binaries were
signed. This means digsig was exercising the inode and file
security objects, dte was using inode, file, task, and sb and file
security objects, and bsd jail was using task, file, ipc, inode, and
sock security objects. At least the inode and task objects were
heavily shared. (bsdjail and dte use file->f_security only in case
of file_sigio).

The built-in approach does appear to outperform the chaining
approach. However it suffers the problems of taking quite a bit
more memory per kernel object, and requiring a maximum number of
modules to be a kernel compile time (Kconfig) option.

I frankly am most excited about the potential of the hashing
approach :)

-serge

Attachment: bsdjail.c.diff.builtin
Description: Text document

Attachment: bsdjail.c.diff.chain
Description: Text document

Attachment: digsig.diff.builtin
Description: Text document

Attachment: digsig.diff.chain
Description: Text document

Attachment: dte.diff.builtin
Description: Text document

Attachment: dte.diff.chain
Description: Text document

Attachment: linux-2.6.8.1.diff.builtin
Description: Text document

Attachment: linux-2.6.8.1.diff.chain
Description: Text document

Attachment: lmbench.builtin
Description: Text document

Attachment: lmbench.chain
Description: Text document

Attachment: report.builtin
Description: Text document

Attachment: report.builtin2
Description: Text document

Attachment: report.builtin3
Description: Text document

Attachment: report.chain
Description: Text document

Attachment: report.chain2
Description: Text document

Attachment: report.chain3
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise