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
This archive was generated by hypermail 2.1.3 : Fri Sep 03 2004 - 19:26:35 PDT