Re: [PATCH] Stacker - single-use static slots

[serge]

Quoting Chris Wright (chrisw@xxxxxxxx):
> * serue@xxxxxxxxxx (serue@xxxxxxxxxx) wrote:
> > > James had suggested to effectively stash the list in the last slot, so
> > > there's only the array with one reserved slot.
> > 
> > Oh, I didn't catch that.  I like it.  Will do.
> > 
> > So you mean 3 slots total including the shared one?
> 
> Yeah, i.e. common case is $LSM and capabilities.  Stack slot is last
> one, and gets put to use only if needed.
> 
> > Any comments on the added argument to register_security and
> > mod_reg_security to request a static slot?
> 
> Why would you not request a static slot?

Capability wouldn't use it, though, so that slot would be wasted.  In my
patch, capability, cap_stack, and root_plug don't ask for a slot.

> > +	spin_lock(&security_field_spinlock);
> > +	if (idx && *idx) {
> > +		int i;
> > +
> > +		*idx = -1;
> 
> So, I guess this means you request one, but who knows which one you'll
> get?

If you get -1 back, you didn't get a static slot.  But you don't have to
care as a module writer, the security_*_value functions will default to
using the shared slot if idx==-1.

> > +		for (i=0; i<CONFIG_SECURITY_STACKER_NUMFIELDS; i++) {
> > +			if (security_field_owners[i] == NULL) {
> > +				security_field_owners[i] = ops;
> > +				*idx = i;

This (idx != -1) means you got a static slot.

Of course this can now switch to idx==num_slots meaning you use the
shared slot.

> > Given the likelyhood of
> > capability/cap_stack being registered, it seemed worthwhile not to have
> > it waste a spot, but it is an API change...
> 
> API change is no big deal.  Seems useful to get index value so you can
> do optimized retrieve later.  But, I don't see it useful to request that
> way.  Just register, get index, if index == last slot, lookup hits list.

If we do switch to all LSMs getting a slot, should we just have the
return value for register_security and mod_reg_security be the slot#, or
-error?

thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/