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

[serue]

Quoting Chris Wright (chrisw@xxxxxxxx):
> * serue@xxxxxxxxxx (serue@xxxxxxxxxx) wrote:
> > +#if 0
> > +	printk(KERN_NOTICE "__get_value: %s (%d): head %lx p %lx idx %d returning %lx at %lx\n",
> > +		__FUNCTION__, __LINE__, (long)head, (long)p, idx, (long)p[idx], (long)&p[idx]);
> > +#endif
> > +	return p[idx];
> 
> pr_debug

Thanks.

> > +config SECURITY_STACKER_NUMFIELDS
> > +	int "Number of security fields to reserve"
> > +	depends on SECURITY_STACKER
> > +	default 1
> 
> Not sure config is worth it, also, James had suggested smth like 3
> slots.

I misread that.  I'd latched onto the "selinux+capability" (again),
which combined would need only one spot.

> >  		INIT_HLIST_HEAD(&inode->i_security);
> > +		memset(&inode->i_security_p, 0,
> > +			CONFIG_SECURITY_STACKER_NUMFIELDS*sizeof(void *));
> 
> This CONFIG... is a bit rough.  Can we use a simple name, and if config
> is necessary, assign config to simple name?

Will do.

> > Index: linux-2.6.12/include/linux/fs.h
> > ===================================================================
> > --- linux-2.6.12.orig/include/linux/fs.h	2005-08-01 20:00:50.000000000 -0500
> > +++ linux-2.6.12/include/linux/fs.h	2005-08-01 20:24:55.000000000 -0500
> > @@ -486,6 +486,7 @@ struct inode {
> >  
> >  	atomic_t		i_writecount;
> >  	struct hlist_head	i_security;
> > +	void			*i_security_p[CONFIG_SECURITY_STACKER_NUMFIELDS];
> 
> 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?

Any comments on the added argument to register_security and
mod_reg_security to request a static 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...

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/