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
--
next prev parent 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).