linux-kernel - Re: [PATCH 01/19] vfs: syscall: Add fsinfo() to query filesystem information [ver #16]

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 linux-cve-announce 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]

Message-ID: <20200220153118.GE9496@magnolia>
Date:   Thu, 20 Feb 2020 07:31:18 -0800
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Jann Horn <jannh@...gle.com>
Cc:     David Howells <dhowells@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>, raven@...maw.net,
        Miklos Szeredi <mszeredi@...hat.com>,
        Christian Brauner <christian@...uner.io>,
        Linux API <linux-api@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 01/19] vfs: syscall: Add fsinfo() to query filesystem
 information [ver #16]

On Thu, Feb 20, 2020 at 03:54:25PM +0100, Jann Horn wrote:
> On Thu, Feb 20, 2020 at 12:04 PM David Howells <dhowells@...hat.com> wrote:
> > Jann Horn <jannh@...gle.com> wrote:
> >
> > > > +int fsinfo_string(const char *s, struct fsinfo_context *ctx)
> > > ...
> > > Please add a check here to ensure that "ret" actually fits into the
> > > buffer (and use WARN_ON() if you think the check should never fire).
> > > Otherwise I think this is too fragile.
> >
> > How about:
> >
> >         int fsinfo_string(const char *s, struct fsinfo_context *ctx)
> >         {
> >                 unsigned int len;
> >                 char *p = ctx->buffer;
> >                 int ret = 0;
> >                 if (s) {
> >                         len = strlen(s);
> >                         if (len > ctx->buf_size - 1)
> >                                 len = ctx->buf_size;
> >                         if (!ctx->want_size_only) {
> >                                 memcpy(p, s, len);
> >                                 p[len] = 0;
> 
> I think this is off-by-one? If len was too big, it is set to
> ctx->buf_size, so in that case this effectively becomes
> `ctx->buffer[ctx->buf_size] = 0`, which is one byte out of bounds,
> right?
> 
> Maybe use something like `len = min_t(size_t, strlen(s), ctx->buf_size-1)` ?
> 
> Looks good apart from that, I think.
> 
> >                         }
> >                         ret = len;
> >                 }
> >                 return ret;
> >         }
> [...]
> > > > +       return ctx->usage;
> > >
> > > It is kind of weird that you have to return the ctx->usage everywhere
> > > even though the caller already has ctx...
> >
> > At this point, it's only used and returned by fsinfo_attributes() and really
> > is only for the use of the attribute getter function.
> >
> > I could, I suppose, return the amount of data in ctx->usage and then preset it
> > for VSTRUCT-type objects.  Unfortunately, I can't make the getter return void
> > since it might have to return an error.
> 
> Yeah, then you'd be passing around the error separately from the
> length... I don't know whether that'd make things better or worse.
> 
> [...]
> > > > +struct fsinfo_attribute {
> > > > +       unsigned int            attr_id;        /* The ID of the attribute */
> > > > +       enum fsinfo_value_type  type:8;         /* The type of the attribute's value(s) */
> > > > +       unsigned int            flags:8;
> > > > +       unsigned int            size:16;        /* - Value size (FSINFO_STRUCT) */
> > > > +       unsigned int            element_size:16; /* - Element size (FSINFO_LIST) */
> > > > +       int (*get)(struct path *path, struct fsinfo_context *params);
> > > > +};
> > >
> > > Why the bitfields? It doesn't look like that's going to help you much,
> > > you'll just end up with 6 bytes of holes on x86-64:
> >
> > Expanding them to non-bitfields will require an extra 10 bytes, making the
> > struct 8 bytes bigger with 4 bytes of padding.  I can do that if you'd rather.
> 
> Wouldn't this still have the same total size?
> 
> struct fsinfo_attribute {
>   unsigned int attr_id;        /* 0x0-0x3 */
>   enum fsinfo_value_type type; /* 0x4-0x7 */
>   u8 flags;                    /* 0x8-0x8 */
>   /* 1-byte hole */
>   u16 size;                    /* 0xa-0xb */
>   u16 element_size;            /* 0xc-0xd */
>   /* 2-byte hole */
>   int (*get)(...);             /* 0x10-0x18 */
> };
> 
> But it's not like I really care about this detail all that much, feel
> free to leave it as-is.

I was thinking, why not just have unsigned int flags from the start?
That replaces the padding holes with usable flag space, though I guess
this is in-core only so I'm not that passionate.  I doubt we're going to
have millions of fsinfo attributes. :)

--D