All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack3000@gmail.com>
To: Paul Moore <paul@paul-moore.com>
Cc: "Mickaël Salaün" <mic@digikod.net>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Casey Schaufler" <casey@schaufler-ca.com>,
	"James Morris" <jmorris@namei.org>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	"Konstantin Meskhidze" <konstantin.meskhidze@huawei.com>
Subject: Re: [PATCH v9 00/11] landlock: truncate support
Date: Tue, 18 Oct 2022 20:06:55 +0200	[thread overview]
Message-ID: <Y07rP/YNYxvQzOei@nuc> (raw)
In-Reply-To: <CAHC9VhR8SQo9x_cv6BZQSwt0rrjeGh-t+YV10GrA3PbC+yHrxw@mail.gmail.com>

On Tue, Oct 18, 2022 at 01:12:48PM -0400, Paul Moore wrote:
> On Mon, Oct 17, 2022 at 5:16 AM Mickaël Salaün <mic@digikod.net> wrote:
> > On 16/10/2022 22:07, Günther Noack wrote:
> 
> ...
> 
> > > Proposed fix
> > > ------------
> > >
> > > I think the LSM framework should ensure that security blobs are
> > > pointer-aligned.
> > >
> > > The LSM framework takes the role of a memory allocator here, and
> > > memory allocators should normally return aligned addresses, in my
> > > understanding. -- It seems reasonable for AppArmor to make that
> > > assumption.
> > >
> > > The proposed one-line fix is: Change lsm_set_blob_size() in
> > > security/security.c, where the positions of the individual security
> > > blobs are calculated, so that each allocated blob is aligned to a
> > > pointer size boundary.
> > >
> > > if (*need > 0) {
> > >    *lbs = ALIGN(*lbs, sizeof(void *));   // NEW
> > >
> > >    offset = *lbs;
> > >    *lbs += *need;
> > >    *need = offset;
> > > }
> >
> > This looks good to me. This fix should be part of patch 4/11 since it
> > only affects Landlock for now.
> 
> Hi Günther,
> 
> Sorry for not seeing this email sooner; I had thought the landlock
> truncate work was largely resolved with just a few small things for
> you to sort out with Mickaël so I wasn't following this thread very
> closely anymore.
> 
> Regarding the fix, yes, I think the solution is to fixup the LSM
> security blob allocator to properly align the entries.  As you already
> mentioned, that's common behavior elsewhere and I see no reason why we
> should deviate from that in the LSM allocator.  Honestly, looking at
> the rest of the allocator right now I can see a few other things to
> improve, but those can wait for a later time so as to not conflict
> with this work (/me adds a new entry to my todo list).
> 
> Other than that, I might suggest the lsm_set_blob_size()
> implementation below as it seems cleaner to me and should be
> functionally equivalent ... at least on quick inspection, if I've done
> something dumb with the code below please feel free to ignore me ;)
> 
>   static void __init lsm_set_blob_size(int *need, int *lbs)
>   {
>     if (*need <= 0)
>       return;
> 
>     *need = ALIGN(*need, sizeof(void *));
>     *lbs += *need;
>   }

Hello Paul,

thanks for the reply. Sounds good, I'll go forward with this approach
then and send a V10 soon.

Implementation-wise for this function, I think this is the closest to
your suggestion I can get:

static void __init lsm_set_blob_size(int *need, int *lbs)
{
  int offset;

  if (*need <= 0)
    return;

  offset = ALIGN(*lbs, sizeof(void *));
  *lbs = offset + *need;
  *need = offset;
}

This differs from your suggestion in that:

- *need gets assigned to the offset at the end. (It's a bit unusual:
  *need is both used to specify the requested blob size when calling
  the function, and for returning the allocated offset from the
  function call.)

- This implementation aligns the blob's start offset, not the end
  offset. (probably makes no real difference in practice)

As suggested by Mickaël, I'll make this fix part of the "Landlock:
Support file truncation" patch, so that people backporting it won't
accidentally leave it out.

—Günther

-- 

  reply	other threads:[~2022-10-18 18:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-08 10:09 [PATCH v9 00/11] landlock: truncate support Günther Noack
2022-10-08 10:09 ` [PATCH v9 01/11] security: Create file_truncate hook from path_truncate hook Günther Noack
2022-10-08 10:09 ` [PATCH v9 02/11] landlock: Refactor check_access_path_dual() into is_access_to_paths_allowed() Günther Noack
2022-10-08 10:09 ` [PATCH v9 03/11] landlock: Document init_layer_masks() helper Günther Noack
2022-10-08 10:09 ` [PATCH v9 04/11] landlock: Support file truncation Günther Noack
2022-10-08 10:09 ` [PATCH v9 05/11] selftests/landlock: Test file truncation support Günther Noack
2022-10-08 10:09 ` [PATCH v9 06/11] selftests/landlock: Test open() and ftruncate() in multiple scenarios Günther Noack
2022-10-08 10:09 ` [PATCH v9 07/11] selftests/landlock: Locally define __maybe_unused Günther Noack
2022-10-08 10:09 ` [PATCH v9 08/11] selftests/landlock: Test FD passing from restricted to unrestricted processes Günther Noack
2022-10-08 10:09 ` [PATCH v9 09/11] selftests/landlock: Test ftruncate on FDs created by memfd_create(2) Günther Noack
2022-10-08 11:18 ` [PATCH v9 10/11] samples/landlock: Extend sample tool to support LANDLOCK_ACCESS_FS_TRUNCATE Günther Noack
2022-10-08 11:18   ` [PATCH v9 11/11] landlock: Document Landlock's file truncation support Günther Noack
2022-10-10 10:35 ` [PATCH v9 00/11] landlock: truncate support Mickaël Salaün
2022-10-13 16:35   ` Nathan Chancellor
2022-10-13 16:36     ` Nathan Chancellor
2022-10-16 18:11     ` Günther Noack
2022-10-16 20:07       ` Günther Noack
2022-10-17  9:16         ` Mickaël Salaün
2022-10-18 17:12           ` Paul Moore
2022-10-18 18:06             ` Günther Noack [this message]
2022-10-18 18:32               ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y07rP/YNYxvQzOei@nuc \
    --to=gnoack3000@gmail.com \
    --cc=casey@schaufler-ca.com \
    --cc=jmorris@namei.org \
    --cc=konstantin.meskhidze@huawei.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    --cc=nathan@kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.