Re: [PATCH v23 02/23] LSM: Create and manage the lsmblob data structure.

On 12/28/2020 9:54 AM, Mimi Zohar wrote: > Hi Casey, > > On Fri, 2020-11-20 at 12:14 -0800, Casey Schaufler wrote: >> When more than one security module is exporting data to >> audit and networking sub-systems a single 32 bit integer >> is no longer sufficient to represent the data. Add a >> structure to be used instead. >> >> The lsmblob structure is currently an array of >> u32 "secids". There is an entry for each of the >> security modules built into the system that would >> use secids if active. The system assigns the module >> a "slot" when it registers hooks. If modules are >> compiled in but not registered there will be unused >> slots. >> >> A new lsm_id structure, which contains the name >> of the LSM and its slot number, is created. There >> is an instance for each LSM, which assigns the name >> and passes it to the infrastructure to set the slot. >> >> The audit rules data is expanded to use an array of >> security module data rather than a single instance. >> Because IMA uses the audit rule functions it is >> affected as well. > This patch is quite large, even without the audit rule change. I would > limit this patch to the new lsm_id structure changes. The audit rule > change should be broken out as a separate patch so that the audit > changes aren't hidden. Breaking up the patch in any meaningful way would require scaffolding code that is as extensive and invasive as the final change. I can do that if you really need it, but it won't be any easier to read.

> In addition, here are a few high level nits: > - The (patch description) body of the explanation, line wrapped at 75 > columns, which will be copied to the permanent changelog to describe > this patch. (Refer Documentation/process/submitting-patches.rst.) Will fix. > - The brief kernel-doc descriptions should not have a trailing period. > Nor should kernel-doc variable definitions have a trailing period. > Example(s) inline below. (The existing kernel-doc is mostly correct.) Will fix. > - For some reason existing comments that span multiple lines aren't > formatted properly. In those cases, where there is another change, > please fix the comment and function description. Can you give an example? There are multiple comment styles used in the various components.

I don't see any comments on the ima code changes. I really don't want to spin a new patch set that does nothing but change two periods in comments only to find out two months from now that the code changes are completely borked. I really don't want to go through the process of breaking up the patch that has been widely Acked if there's no reason to expect it would require significant work otherwise.