On Tue, Jun 2, 2020 at 8:31 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > Side note since you mention performance work: in the past when I've > looked at SELinux performance (generally as part of pathname lookup > etc VFS loads), the biggest cost by far was that all the SELinux data > structures take a ton of cache misses. > > Yes, some of the hashing shows up in the profiles, but _most_ of it > was loading the data from inode->i_security etc. > > And the reason seemed to be that every single inode ends up having a > separately allocated "struct inode_security_struct" (aka "isec"). Even > if the contents are often all exactly the same for a large set of > inodes that thus _could_ conceptually share the data. > > Now, it used to be - before being able to stack security layers - > SElinux would control that pointer, and it could have done some kind > of sharing scheme with copy-on-write behavior (the way we do 'struct > cred' for processes), and it would have caused a much smaller cache > footprint (and thus likely much fewer cache misses). I believe right about the time that Eric Paris was stepping away from SELinux he was working on a patchset that basically did what you describe: copy-on-write for the SELinux inode blobs (aka inode_security_struct, aka isec, etc.). Unfortunately I don't believe that work was ever finished and the idea was lost many years ago in the maintainer shuffle; I was trying to figure out this whole "maintainer thing" and perhaps didn't push Eric to post those patches as much as I should have. Although it's a big academic now with the LSM stacking work. Most of my SELinux thoughts these days are around the correctness and robustness of the code, making sure we are testing as much as possible (related to the first point), and trying to catch changes in other subsystems which cause us breakage. Not the most glamorous stuff, but it's important. SELinux is lucky enough to have a few active kernel developers, and thankfully a couple of them appear to be looking at some of the performance issues. > These days, that sharing of the i_security pointer across different > security layers makes that sound really really painful. Yeah. It's pretty much impossible now to do copy-on-write with the main security blobs due to the differing nature of the LSMs and the single, shared allocation for each blob. I suppose if you wanted to attempt copy-on-write inside a LSM you could introduce another layer of pointers/allocation, but I'm not sure how much of an improvement that might be. Perhaps a bit more thought will produce a "eureka!" moment, but I'm not overly optimistic. > But I do wonder if anybody in selinux land (or general security > subsystem land) has been thinking of maybe at least having a "this > inode has no special labeling" marker that could possibly avoid having > all those extra allocations. I don't want to get into the "security people can't agree on anything" discussion, but I think for that to work all of the loaded LSMs would need to agree that they don't need to stash anything in the inode (or other object); which I think is pretty much impossible most of the time. At least in the SELinux case, even if we were doing some sort of copy-on-write, we would need to keep a reference back to the inode security blob that does contain our needed info. -- paul moore www.paul-moore.com
