linux-fsdevel.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).