On Sun, May 21, 2017 at 08:14:05PM +0900, Tetsuo Handa wrote: > A sealable memory allocator patch was proposed at > http://lkml.kernel.org/r/20170519103811.2183-1-igor.stoppa@xxxxxxxxxx , > and is waiting for a follow-on patch showing how any of the kernel > can be changed to use this new subsystem. So, here it is for LSM hooks. > > The LSM hooks ("struct security_hook_heads security_hook_heads" and > "struct security_hook_list ...[]") will benefit from this allocator via > protection using set_memory_ro()/set_memory_rw(), and it will remove > CONFIG_SECURITY_WRITABLE_HOOKS config option. > > This means that these structures will be allocated at run time using > smalloc(), and therefore the address of these structures will be > determined at run time rather than compile time. > > But currently, LSM_HOOK_INIT() macro depends on the address of > security_hook_heads being known at compile time. But we already > initialize security_hook_heads as an array of "struct list_head". > > Therefore, let's use index number (or relative offset from the head > of security_hook_heads) instead of absolute address of > security_hook_heads so that LSM_HOOK_INIT() macro does not need to > know absolute address of security_hook_heads. Then, security_add_hooks() > will be able to allocate and copy "struct security_hook_list ...[]" using > smalloc(). > > Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> > Cc: Kees Cook <keescook@xxxxxxxxxxxx> > Cc: Paul Moore <paul@xxxxxxxxxxxxxx> > Cc: Stephen Smalley <sds@xxxxxxxxxxxxx> > Cc: Casey Schaufler <casey@xxxxxxxxxxxxxxxx> > Cc: James Morris <james.l.morris@xxxxxxxxxx> > Cc: Igor Stoppa <igor.stoppa@xxxxxxxxxx> > Cc: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > --- > include/linux/lsm_hooks.h | 6 +++--- > security/security.c | 10 ++++++++-- > 2 files changed, 11 insertions(+), 5 deletions(-) > > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h > index 080f34e..865c11d 100644 > --- a/include/linux/lsm_hooks.h > +++ b/include/linux/lsm_hooks.h > @@ -1884,8 +1884,8 @@ struct security_hook_heads { > */ > struct security_hook_list { > struct list_head list; > - struct list_head *head; > union security_list_options hook; > + const unsigned int idx; > char *lsm; > }; > > @@ -1896,9 +1896,9 @@ struct security_hook_list { > * text involved. > */ > #define LSM_HOOK_INIT(HEAD, HOOK) \ > - { .head = &security_hook_heads.HEAD, .hook = { .HEAD = HOOK } } > + { .idx = offsetof(struct security_hook_heads, HEAD) / \ > + sizeof(struct list_head), .hook = { .HEAD = HOOK } } > > -extern struct security_hook_heads security_hook_heads; > extern char *lsm_names; > > extern void security_add_hooks(struct security_hook_list *hooks, int count, > diff --git a/security/security.c b/security/security.c > index 54b1e39..d6883ce 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -33,7 +33,7 @@ > /* Maximum number of letters for an LSM name string */ > #define SECURITY_NAME_MAX 10 > > -struct security_hook_heads security_hook_heads __lsm_ro_after_init; > +static struct security_hook_heads security_hook_heads __lsm_ro_after_init; > char *lsm_names; > /* Boot-time LSM user choice */ > static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] = > @@ -152,10 +152,16 @@ void __init security_add_hooks(struct security_hook_list *hooks, int count, > char *lsm) > { > int i; > + struct list_head *list = (struct list_head *) &security_hook_heads; Eww, struct casts. This whole security_hook_heads scheme stink, even with the slight improvements from Tetsuo. It has everything we shouldn't do - function pointers in structures that are not hard read-only, structure casts, etc. What's the reason why can't just have good old const function tables? Yeah, stackable LSM make that a little harder, but they should not be enable by default anyway. But even with those we can still chain them together with a list with external linkage. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
