[PATCH v3 22/24] LSM: Return the lsmblob slot on initialization

[Kees Cook]

On Mon, Jun 24, 2019 at 02:39:23PM -0700, John Johansen wrote:
> On 6/22/19 4:13 PM, Kees Cook wrote:
> > On Fri, Jun 21, 2019 at 11:52:31AM -0700, Casey Schaufler wrote:
> >> Return the slot allocated to the calling LSM in the lsmblob
> >> structure. This can be used to set lsmblobs explicitly for
> >> netlabel interfaces.
> >>
> >> Signed-off-by: Casey Schaufler <casey at schaufler-ca.com>
> > 
> > Reviewed-by: Kees Cook <keescook at chromium.org>
> > 
> > (I have some thoughts on refactoring the slot assignment, but that
> > should happen after this series -- it's nothing more than a storage
> > optimization.)
> > 
> > -Kees
> 
> haha so do I, now I am curious as to how close they align

My plan is to create a __ro_after_init "LSM State" structure to hold
various things that are needed after init time. All of the lsm_info
structures are __initdata, so they can't be retained after init
(currently). As far as I can see, there are already a few things that
are retained after init:

LSM name (currently a pointer in every hook)
enabled state (technically optional, currently known internally to each LSM)
blob size details (currently known internally to each LSM)

and now we'll be adding the "slot". So I was thinking something like:

struct lsm_state {
	const char *name;
	int enabled;
	struct blob_sizes lbs;
	int slot;
};

And then change the hooks to each carry a pointer to the lsm_state
(instead of a name pointer). Also I think it'd be cleanest to define
and export the lsm_state instance it via the DEFINE_LSM macro, possibly
instead of the existing blob_size pointer. It's possible that lsm_info
should just gain some fields and no longer be __initdata, too. We'll
see!

-- 
Kees Cook