From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Gabriel Krisman Bertazi <krisman@collabora.com>,
Jan Kara <jack@suse.com>, Linux API <linux-api@vger.kernel.org>,
Ext4 <linux-ext4@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Khazhismel Kumykov <khazhy@google.com>,
David Howells <dhowells@redhat.com>,
Dave Chinner <david@fromorbit.com>, Theodore Tso <tytso@mit.edu>,
"Darrick J. Wong" <djwong@kernel.org>,
Matthew Bobrowski <repnop@google.com>,
kernel@collabora.com
Subject: Re: [PATCH v6 12/21] fanotify: Encode invalid file handle when no inode is provided
Date: Mon, 16 Aug 2021 16:06:57 +0200 [thread overview]
Message-ID: <20210816140657.GE30215@quack2.suse.cz> (raw)
In-Reply-To: <CAOQ4uxgwuJ4hv8Dp1v40K5qdnnwa7n9MYyvuh2tkb4gkpZv2Yw@mail.gmail.com>
On Fri 13-08-21 11:27:48, Amir Goldstein wrote:
> On Fri, Aug 13, 2021 at 12:41 AM Gabriel Krisman Bertazi
> <krisman@collabora.com> wrote:
> >
> > Instead of failing, encode an invalid file handle in fanotify_encode_fh
> > if no inode is provided. This bogus file handle will be reported by
> > FAN_FS_ERROR for non-inode errors.
> >
> > When being reported to userspace, the length information is actually
> > reset and the handle cleaned up, such that userspace don't have the
> > visibility of the internal kernel representation of this null handle.
> >
> > Also adjust the single caller that might rely on failure after passing
> > an empty inode.
> >
> > Suggested-by: Amir Goldstein <amir73il@gmail.com>
> > Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
> >
> > ---
> > Changes since v5:
> > - Preserve flags initialization (jan)
> > - Add BUILD_BUG_ON (amir)
> > - Require minimum of FANOTIFY_NULL_FH_LEN for fh_len(amir)
> > - Improve comment to explain the null FH length (jan)
> > - Simplify logic
> > ---
> > fs/notify/fanotify/fanotify.c | 27 ++++++++++++++++++-----
> > fs/notify/fanotify/fanotify_user.c | 35 +++++++++++++++++-------------
> > 2 files changed, 41 insertions(+), 21 deletions(-)
> >
> > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> > index 50fce4fec0d6..2b1ab031fbe5 100644
> > --- a/fs/notify/fanotify/fanotify.c
> > +++ b/fs/notify/fanotify/fanotify.c
> > @@ -334,6 +334,8 @@ static u32 fanotify_group_event_mask(struct fsnotify_group *group,
> > return test_mask & user_mask;
> > }
> >
> > +#define FANOTIFY_NULL_FH_LEN 4
> > +
> > /*
> > * Check size needed to encode fanotify_fh.
> > *
> > @@ -345,7 +347,7 @@ static int fanotify_encode_fh_len(struct inode *inode)
> > int dwords = 0;
> >
> > if (!inode)
> > - return 0;
> > + return FANOTIFY_NULL_FH_LEN;
> >
> > exportfs_encode_inode_fh(inode, NULL, &dwords, NULL);
> >
> > @@ -367,11 +369,23 @@ static int fanotify_encode_fh(struct fanotify_fh *fh, struct inode *inode,
> > void *buf = fh->buf;
> > int err;
> >
> > - fh->type = FILEID_ROOT;
> > - fh->len = 0;
> > + BUILD_BUG_ON(FANOTIFY_NULL_FH_LEN < 4 ||
> > + FANOTIFY_NULL_FH_LEN > FANOTIFY_INLINE_FH_LEN);
> > +
> > fh->flags = 0;
> > - if (!inode)
> > - return 0;
> > +
> > + if (!inode) {
> > + /*
> > + * Invalid FHs are used on FAN_FS_ERROR for errors not
> > + * linked to any inode. The f_handle won't be reported
> > + * back to userspace. The extra bytes are cleared prior
> > + * to reporting.
> > + */
> > + type = FILEID_INVALID;
> > + fh_len = FANOTIFY_NULL_FH_LEN;
>
> Please memset() the NULL_FH buffer to zero.
>
> > +
> > + goto success;
> > + }
> >
> > /*
> > * !gpf means preallocated variable size fh, but fh_len could
> > @@ -400,6 +414,7 @@ static int fanotify_encode_fh(struct fanotify_fh *fh, struct inode *inode,
> > if (!type || type == FILEID_INVALID || fh_len != dwords << 2)
> > goto out_err;
> >
> > +success:
> > fh->type = type;
> > fh->len = fh_len;
> >
> > @@ -529,7 +544,7 @@ static struct fanotify_event *fanotify_alloc_name_event(struct inode *id,
> > struct fanotify_info *info;
> > struct fanotify_fh *dfh, *ffh;
> > unsigned int dir_fh_len = fanotify_encode_fh_len(id);
> > - unsigned int child_fh_len = fanotify_encode_fh_len(child);
> > + unsigned int child_fh_len = child ? fanotify_encode_fh_len(child) : 0;
> > unsigned int size;
> >
> > size = sizeof(*fne) + FANOTIFY_FH_HDR_LEN + dir_fh_len;
> > diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> > index c47a5a45c0d3..4cacea5fcaca 100644
> > --- a/fs/notify/fanotify/fanotify_user.c
> > +++ b/fs/notify/fanotify/fanotify_user.c
> > @@ -360,7 +360,10 @@ static int copy_info_to_user(__kernel_fsid_t *fsid, struct fanotify_fh *fh,
> > return -EFAULT;
> >
> > handle.handle_type = fh->type;
> > - handle.handle_bytes = fh_len;
> > +
> > + /* FILEID_INVALID handle type is reported without its f_handle. */
> > + if (fh->type != FILEID_INVALID)
> > + handle.handle_bytes = fh_len;
>
> I know I suggested those exact lines, but looking at the patch,
> I think it would be better to do:
> + if (fh->type != FILEID_INVALID)
> + fh_len = 0;
> handle.handle_bytes = fh_len;
>
> > if (copy_to_user(buf, &handle, sizeof(handle)))
> > return -EFAULT;
> >
> > @@ -369,20 +372,22 @@ static int copy_info_to_user(__kernel_fsid_t *fsid, struct fanotify_fh *fh,
> > if (WARN_ON_ONCE(len < fh_len))
> > return -EFAULT;
> >
> > - /*
> > - * For an inline fh and inline file name, copy through stack to exclude
> > - * the copy from usercopy hardening protections.
> > - */
> > - fh_buf = fanotify_fh_buf(fh);
> > - if (fh_len <= FANOTIFY_INLINE_FH_LEN) {
> > - memcpy(bounce, fh_buf, fh_len);
> > - fh_buf = bounce;
> > + if (fh->type != FILEID_INVALID) {
>
> ... and here: if (fh_len) {
>
> > + /*
> > + * For an inline fh and inline file name, copy through
> > + * stack to exclude the copy from usercopy hardening
> > + * protections.
> > + */
> > + fh_buf = fanotify_fh_buf(fh);
> > + if (fh_len <= FANOTIFY_INLINE_FH_LEN) {
> > + memcpy(bounce, fh_buf, fh_len);
> > + fh_buf = bounce;
> > + }
> > + if (copy_to_user(buf, fh_buf, fh_len))
> > + return -EFAULT;
> > + buf += fh_len;
> > + len -= fh_len;
> > }
> > - if (copy_to_user(buf, fh_buf, fh_len))
> > - return -EFAULT;
> > -
> > - buf += fh_len;
> > - len -= fh_len;
> >
> > if (name_len) {
> > /* Copy the filename with terminating null */
> > @@ -398,7 +403,7 @@ static int copy_info_to_user(__kernel_fsid_t *fsid, struct fanotify_fh *fh,
> > }
> >
> > /* Pad with 0's */
> > - WARN_ON_ONCE(len < 0 || len >= FANOTIFY_EVENT_ALIGN);
> > + WARN_ON_ONCE(len < 0);
>
> According to my calculations, FAN_FS_ERROR event with NULL_FH is expected
> to get here with len == 4, so you can change this to:
> WARN_ON_ONCE(len < 0 || len > FANOTIFY_EVENT_ALIGN);
>
> But first, I would like to get Jan's feedback on this concept of keeping
> unneeded 4 bytes zero padding in reported event in case of NULL_FH
> in order to keep the FID reporting code simpler.
Dunno, it still seems like quite some complications (simple ones but
non-trivial amount of them) for what is rather a corner case. What if we
*internally* propagated the information that there's no inode info with
FILEID_ROOT fh? That means: No changes to fanotify_encode_fh_len(),
fanotify_encode_fh(), or fanotify_alloc_name_event(). In
copy_info_to_user() we just mangle FILEID_ROOT to FILEID_INVALID and that's
all. No useless padding, no specialcasing of copying etc. Am I missing
something?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2021-08-16 14:07 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-12 21:39 [PATCH v6 00/21] File system wide monitoring Gabriel Krisman Bertazi
2021-08-12 21:39 ` [PATCH v6 01/21] fsnotify: Don't insert unmergeable events in hashtable Gabriel Krisman Bertazi
2021-08-12 21:39 ` [PATCH v6 02/21] fanotify: Fold event size calculation to its own function Gabriel Krisman Bertazi
2021-08-12 21:39 ` [PATCH v6 03/21] fanotify: Split fsid check from other fid mode checks Gabriel Krisman Bertazi
2021-08-12 21:39 ` [PATCH v6 04/21] fsnotify: Reserve mark flag bits for backends Gabriel Krisman Bertazi
2021-08-13 7:28 ` Amir Goldstein
2021-08-16 13:15 ` Jan Kara
2021-08-23 14:36 ` Gabriel Krisman Bertazi
2021-08-12 21:39 ` [PATCH v6 05/21] fanotify: Split superblock marks out to a new cache Gabriel Krisman Bertazi
2021-08-16 13:18 ` Jan Kara
2021-08-12 21:39 ` [PATCH v6 06/21] inotify: Don't force FS_IN_IGNORED Gabriel Krisman Bertazi
2021-08-12 21:39 ` [PATCH v6 07/21] fsnotify: Add helper to detect overflow_event Gabriel Krisman Bertazi
2021-08-12 21:39 ` [PATCH v6 08/21] fsnotify: Add wrapper around fsnotify_add_event Gabriel Krisman Bertazi
2021-08-12 21:39 ` [PATCH v6 09/21] fsnotify: Allow events reported with an empty inode Gabriel Krisman Bertazi
2021-08-13 7:58 ` Amir Goldstein
2021-08-25 18:40 ` Gabriel Krisman Bertazi
2021-08-25 19:45 ` Amir Goldstein
2021-08-25 21:50 ` Gabriel Krisman Bertazi
2021-08-26 10:44 ` Amir Goldstein
2021-08-27 2:26 ` Paul Moore
2021-08-12 21:39 ` [PATCH v6 10/21] fsnotify: Support FS_ERROR event type Gabriel Krisman Bertazi
2021-08-13 7:48 ` Amir Goldstein
2021-08-16 13:23 ` Jan Kara
2021-08-12 21:40 ` [PATCH v6 11/21] fanotify: Allow file handle encoding for unhashed events Gabriel Krisman Bertazi
2021-08-13 7:59 ` Amir Goldstein
2021-08-12 21:40 ` [PATCH v6 12/21] fanotify: Encode invalid file handle when no inode is provided Gabriel Krisman Bertazi
2021-08-13 8:27 ` Amir Goldstein
2021-08-16 14:06 ` Jan Kara [this message]
2021-08-16 15:54 ` Amir Goldstein
2021-08-16 16:11 ` Jan Kara
2021-08-12 21:40 ` [PATCH v6 13/21] fanotify: Require fid_mode for any non-fd event Gabriel Krisman Bertazi
2021-08-13 8:28 ` Amir Goldstein
2021-08-12 21:40 ` [PATCH v6 14/21] fanotify: Reserve UAPI bits for FAN_FS_ERROR Gabriel Krisman Bertazi
2021-08-13 8:29 ` Amir Goldstein
2021-08-12 21:40 ` [PATCH v6 15/21] fanotify: Preallocate per superblock mark error event Gabriel Krisman Bertazi
2021-08-13 8:40 ` Amir Goldstein
2021-08-16 15:57 ` Jan Kara
2021-08-27 18:18 ` Gabriel Krisman Bertazi
2021-09-02 21:24 ` Gabriel Krisman Bertazi
2021-09-03 4:16 ` Amir Goldstein
2021-09-15 10:31 ` Jan Kara
2021-08-12 21:40 ` [PATCH v6 16/21] fanotify: Handle FAN_FS_ERROR events Gabriel Krisman Bertazi
2021-08-13 9:35 ` Amir Goldstein
2021-08-12 21:40 ` [PATCH v6 17/21] fanotify: Report fid info for file related file system errors Gabriel Krisman Bertazi
2021-08-13 9:00 ` Amir Goldstein
2021-08-13 9:03 ` Amir Goldstein
2021-08-16 16:18 ` Jan Kara
2021-08-12 21:40 ` [PATCH v6 18/21] fanotify: Emit generic error info type for error event Gabriel Krisman Bertazi
2021-08-13 8:47 ` Amir Goldstein
2021-08-16 16:23 ` Jan Kara
2021-08-16 21:41 ` Darrick J. Wong
2021-08-17 9:05 ` Jan Kara
2021-08-17 10:08 ` Amir Goldstein
2021-08-18 0:16 ` Darrick J. Wong
2021-08-18 3:24 ` Amir Goldstein
2021-08-18 9:58 ` Jan Kara
2021-08-19 3:58 ` Darrick J. Wong
2021-08-18 0:10 ` Darrick J. Wong
2021-08-24 16:53 ` Gabriel Krisman Bertazi
2021-08-25 4:09 ` Darrick J. Wong
2021-08-12 21:40 ` [PATCH v6 19/21] ext4: Send notifications on error Gabriel Krisman Bertazi
2021-08-16 16:26 ` Jan Kara
2021-08-12 21:40 ` [PATCH v6 20/21] samples: Add fs error monitoring example Gabriel Krisman Bertazi
2021-08-18 13:02 ` Jan Kara
2021-08-23 14:49 ` Gabriel Krisman Bertazi
2021-08-12 21:40 ` [PATCH v6 21/21] docs: Document the FAN_FS_ERROR event Gabriel Krisman Bertazi
2021-08-16 16:40 ` Jan Kara
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=20210816140657.GE30215@quack2.suse.cz \
--to=jack@suse.cz \
--cc=amir73il@gmail.com \
--cc=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=djwong@kernel.org \
--cc=jack@suse.com \
--cc=kernel@collabora.com \
--cc=khazhy@google.com \
--cc=krisman@collabora.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=repnop@google.com \
--cc=tytso@mit.edu \
/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).