On Tue, 2005-06-07 at 23:26 -0500, serue@private wrote: > The fact that stack-noselinux outperforms noselinux shows that stacker > has (at worst, haha :) negligible performance impact. Profiling data > has shown security_get_value to be the main bottleneck. So, to be precise, it has negligible performance impact if you have no real users of LSM (i.e. no users of the security fields, just capabilities), and some (but possibly not large) performance impact if you have a real user of LSM like SELinux, right? > However, > supporting stacker without supporting the sharing of inode->i_security > would be bad for stacking selinux+digsig, selinux+ima, and selinux+ > evm/slim (the tpm-based integrity verification modules), as some of these > modules would have to implement their own hash tables to keep the kernel > object security data. If you are going to have a stacker, then it only makes sense to allow sharing of the security fields IMHO. Not clear that these particular modules are good motivating examples however, given that a) they aren't upstream, b) they likely only need to associate their own data with a small subset of inodes, thus a hash table may be appropriate, and c) at least ima seems to have been rejected as a legitimate user of LSM and the others may run into similar complaints (don't know about evm/slim as it isn't released AFAIK). > At this point I would like to forward stacker to the lkml for comment. > Please let me know if there are any objections to that. Submitting it to lkml for comments seems reasonable to me. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Wed Jun 08 2005 - 09:42:03 PDT