linux-ext4 - Re: [PATCH v7 23/28] fanotify: Report fid info for file related file system errors

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 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]

Date:   Fri, 15 Oct 2021 15:38:11 +0200
From:   Jan Kara <jack@...e.cz>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     Gabriel Krisman Bertazi <krisman@...labora.com>,
        Jan Kara <jack@...e.com>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Theodore Tso <tytso@....edu>,
        David Howells <dhowells@...hat.com>,
        Khazhismel Kumykov <khazhy@...gle.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Ext4 <linux-ext4@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Matthew Bobrowski <repnop@...gle.com>, kernel@...labora.com
Subject: Re: [PATCH v7 23/28] fanotify: Report fid info for file related file
 system errors

On Fri 15-10-21 10:56:38, Amir Goldstein wrote:
> On Fri, Oct 15, 2021 at 12:39 AM Gabriel Krisman Bertazi
> <krisman@...labora.com> wrote:
> >
> > Plumb the pieces to add a FID report to error records.  Since all error
> > event memory must be pre-allocated, we pre-allocate the maximum file
> > handle size possible, such that it should always fit.
> >
> > For errors that don't expose a file handle report it with an invalid
> > FID.
> >
> > Signed-off-by: Gabriel Krisman Bertazi <krisman@...labora.com>
> >
> > ---
> > Changes since v6:
> >   - pass fsid from handle_events
> > Changes since v5:
> >   - Use preallocated MAX_HANDLE_SZ FH buffer
> >   - Report superblock errors with a zerolength INVALID FID (jan, amir)
> > ---
> >  fs/notify/fanotify/fanotify.c | 15 +++++++++++++++
> >  fs/notify/fanotify/fanotify.h |  8 ++++++++
> >  2 files changed, 23 insertions(+)
> >
> > diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> > index 7032083df62a..8a60c96f5fb2 100644
> > --- a/fs/notify/fanotify/fanotify.c
> > +++ b/fs/notify/fanotify/fanotify.c
> > @@ -611,7 +611,9 @@ static struct fanotify_event *fanotify_alloc_error_event(
> >  {
> >         struct fs_error_report *report =
> >                         fsnotify_data_error_report(data, data_type);
> > +       struct inode *inode = report->inode;
> >         struct fanotify_error_event *fee;
> > +       int fh_len;
> >
> >         if (WARN_ON(!report))
> >                 return NULL;
> > @@ -622,6 +624,19 @@ static struct fanotify_event *fanotify_alloc_error_event(
> >
> >         fee->fae.type = FANOTIFY_EVENT_TYPE_FS_ERROR;
> >         fee->err_count = 1;
> > +       fee->fsid = *fsid;
> > +
> > +       fh_len = fanotify_encode_fh_len(inode);
> > +       if (WARN_ON(fh_len > MAX_HANDLE_SZ)) {
> 
> WARN_ON_ONCE please and I rather that this sanity check is moved inside
> fanotify_encode_fh_len() where it will return 0 for encoding failure.

Yeah, that's better.

> > diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
> > index 2b032b79d5b0..b58400926f92 100644
> > --- a/fs/notify/fanotify/fanotify.h
> > +++ b/fs/notify/fanotify/fanotify.h
> > @@ -202,6 +202,10 @@ struct fanotify_error_event {
> >         u32 err_count; /* Suppressed errors count */
> >
> >         __kernel_fsid_t fsid; /* FSID this error refers to. */
> > +       /* object_fh must be followed by the inline handle buffer. */
> > +       struct fanotify_fh object_fh;
> > +       /* Reserve space in object_fh.buf[] - access with fanotify_fh_buf() */
> > +       unsigned char _inline_fh_buf[MAX_HANDLE_SZ];
> >  };
> 
> This struct duplicates most of struct fanotify_fid_event.
> How about:
> 
> #define FANOTIFY_ERROR_FH_LEN \
>              (MAX_HANDLE_SZ - FANOTIFY_INLINE_FH_LEN)
> 
> struct fanotify_error_event {
>          u32 err_count; /* Suppressed errors count */
>          struct fanotify_event ffe;
>          /* Reserve space in ffe.object_fh.buf[] - access with
> fanotify_fh_buf() */
>          unsigned char _fh_buf[FANOTIFY_ERROR_FH_LEN];
> }
> 
> Or leaving out the struct padding and passing
> FANOTIFY_ERROR_EVENT_SIZE as mempool object size?
> 
> #define FANOTIFY_ERROR_EVENT_SIZE \
>             (sizeof(struct fanotify_error_event) + FANOTIFY_ERROR_FH_LEN)

Hrm, I don't like either of these two options too much as IMHO it's rather
hard to understand what's going on. If we want to avoid the duplication,
then I see two relatively clean ways to do it:

a) Remove _inline_fh_buf from fanotify_fid_event (probably just leave a
comment there explaining how space is preallocated) and make sure kmem
cache for fanotify_fid_event has FANOTIFY_INLINE_FH_LEN in each object for
the fh, similarly error event would have MAX_HANDLE_SZ in the object.

b) Define a macro that expands to a struct definition with appropriate
buffer length.

I guess a) seems a bit more obvious to me but I can live with both...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR