linux-kernel - Re: [PATCH] LANDLOCK: use kmem_cache for landlock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZgUh7cIQIsOgvWpw@ayush-HP-Pavilion-Gaming-Laptop-15-ec0xxx>
Date: Thu, 28 Mar 2024 13:23:17 +0530
From: Ayush Tiwari <ayushtiw0110@...il.com>
To: Paul Moore <paul@...l-moore.com>
Cc: alison.schofield@...el.com, mic@...ikod.net,
	fabio.maria.de.francesco@...ux.intel.com,
	linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
	gregkh@...uxfoundation.org, outreachy@...ts.linux.dev,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH] LANDLOCK: use kmem_cache for landlock_object

Hello Paul
Thanks a lot for the feedback. Apologies for the mistakes. Could you
help me in some places so that I can correct the errors, like:
On Wed, Mar 27, 2024 at 07:43:36PM -0400, Paul Moore wrote:
> On Wed, Mar 27, 2024 at 7:26 PM Ayush Tiwari <ayushtiw0110@...il.com> wrote:
> >
> > Use kmem_cache replace kzalloc() calls with kmem_cache_zalloc() for
> > struct landlock_object and update the related dependencies.
> >
> > Signed-off-by: Ayush Tiwari <ayushtiw0110@...il.com>
> > ---
> >  security/landlock/fs.c     |  2 +-
> >  security/landlock/object.c | 14 ++++++++++++--
> >  security/landlock/object.h |  4 ++++
> >  security/landlock/setup.c  |  2 ++
> >  4 files changed, 19 insertions(+), 3 deletions(-)
> 
> Hi Ayush,
> 
> Mickaël has the final say on Landlock patches, but I had a few
> comments that I've included below ...
> 
> > diff --git a/security/landlock/fs.c b/security/landlock/fs.c
> > index fc520a06f9af..227dd67dd902 100644
> > --- a/security/landlock/fs.c
> > +++ b/security/landlock/fs.c
> > @@ -124,7 +124,7 @@ static struct landlock_object *get_inode_object(struct inode *const inode)
> >         if (unlikely(rcu_access_pointer(inode_sec->object))) {
> >                 /* Someone else just created the object, bail out and retry. */
> >                 spin_unlock(&inode->i_lock);
> > -               kfree(new_object);
> > +               kmem_cache_free(landlock_object_cache, new_object);
> 
> See my comment below, but you may want to wrap this in a Landlock
> object API function.
Sure. I will definitely implement this.
> 
> >                 rcu_read_lock();
> >                 goto retry;
> > diff --git a/security/landlock/object.c b/security/landlock/object.c
> > index 1f50612f0185..df1354215617 100644
> > --- a/security/landlock/object.c
> > +++ b/security/landlock/object.c
> > @@ -17,6 +17,15 @@
> >
> >  #include "object.h"
> >
> > +struct kmem_cache *landlock_object_cache;
> > +
> > +void __init landlock_object_init(void)
> > +{
> > +       landlock_object_cache = kmem_cache_create(
> > +               "landlock_object_cache", sizeof(struct landlock_object), 0,
> > +               SLAB_PANIC, NULL);
> 
> The comments in include/linux/slab.h suggest using the KMEM_CACHE()
> macro, instead of kmem_cache_create(), as a best practice for creating
> slab caches.
> 
Sure. Apologies I didn't see that, I tried to implement it from scratch
using the reference from linux memory management APIs.
> > +}
> > +
> >  struct landlock_object *
> >  landlock_create_object(const struct landlock_object_underops *const underops,
> >                        void *const underobj)
> > @@ -25,7 +34,8 @@ landlock_create_object(const struct landlock_object_underops *const underops,
> >
> >         if (WARN_ON_ONCE(!underops || !underobj))
> >                 return ERR_PTR(-ENOENT);
> > -       new_object = kzalloc(sizeof(*new_object), GFP_KERNEL_ACCOUNT);
> > +       new_object =
> > +               kmem_cache_zalloc(landlock_object_cache, GFP_KERNEL_ACCOUNT);
> 
> If the line is too long, you might want to consider splitting the
> function parameters like this:
> 
>   new_object = kmem_cache_zalloc(landlock_object_cache,
>                                  GFP_KERNEL_ACCOUNT);
> 

Sure. I didn't do as it was below the 100 columns limit, but will
definitely implement it.
> >         if (!new_object)
> >                 return ERR_PTR(-ENOMEM);
> >         refcount_set(&new_object->usage, 1);
> > @@ -62,6 +72,6 @@ void landlock_put_object(struct landlock_object *const object)
> >                  * @object->underobj to @object (if it still exists).
> >                  */
> >                 object->underops->release(object);
> > -               kfree_rcu(object, rcu_free);
> > +               kmem_cache_free(landlock_object_cache, object);
> >         }
> >  }
> > diff --git a/security/landlock/object.h b/security/landlock/object.h
> > index 5f28c35e8aa8..8ba1af3ddc2e 100644
> > --- a/security/landlock/object.h
> > +++ b/security/landlock/object.h
> > @@ -13,6 +13,10 @@
> >  #include <linux/refcount.h>
> >  #include <linux/spinlock.h>
> >
> > +extern struct kmem_cache *landlock_object_cache;
> 
> This really is a decision for Mickaël, but you may want to make
> @landlock_object_cache private to object.c and create functions to
> manage it as needed, e.g. put/free operations.
> 
Okay. I didn't make it private as I was using it in fs.c to use
kmem_cache_free, but if this is supposed to be private, I can modify the
approach and expose it via some function, not directly exposing
landlock_object_cache.
> > +void __init landlock_object_init(void);
> > +
> >  struct landlock_object;
> >
> >  /**
> > diff --git a/security/landlock/setup.c b/security/landlock/setup.c
> > index f6dd33143b7f..a5fca4582ee1 100644
> 
> -- 
> paul-moore.com
I will make all the changes you mentioned, and as you said, I will
wait for Mickael's say.