On 6/3/2020 10:37 AM, Linus Torvalds wrote: > On Wed, Jun 3, 2020 at 10:20 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >> We could have inode->i_security be the blob, rather than a pointer to it. >> That will have its own performance issues. > It wouldn't actually really fix anything, because the inode is so big > and sparsely accessed that it doesn't even really help the cache > density issue. Yeah, it gets rid of the pointer access, but that's > pretty much it. The fact that we randomize the order means that we > can't even really try to aim for any cache density. Well, it was a thought. > And it would actually not be possible with the current layered > security model anyway, since those blob sizes are dynamic at runtime. The model would have to change. The dynamic blob size is an artifact of the model, not a driver. > If we had _only_ SELinux, we could perhaps have hidden the > sid/sclass/task_sid directly in the inode (it would be only slightly > larger than the pointer is, anyway), but even that ship sailed long > long ago due to the whole "no security person can ever agree with > another one on fundamentals". Not to mention that the security landscape keeps changing. > So don't try to blame the rest of the system design. That wasn't my intent. Apologies. > This is on the > security people. We've been able to handle other layers fairly well > because they generally agree on fundamentals (although it can take > decades before they then end up merging their code - things like the > filesystem people standardizing on iomap and other core concepts). And > as mentioned, when there is agreed-upon security rules (ie "struct > cred") we've been able to spend the effort to architect it so that it > doesn't add unnecessary overheads. > > Linus
