linux-kernel - Re: [PATCH v5 5/5] staging/android: add flags member to sync ioctl structs

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: <CACvgo50tLFe-GdiV1fP_C8M-pg9p=WqO+HC4UprY8jfks-2xzA@mail.gmail.com>
Date:	Wed, 2 Mar 2016 09:38:34 +0000
From:	Emil Velikov <emil.l.velikov@...il.com>
To:	Gustavo Padovan <gustavo@...ovan.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	devel@...verdev.osuosl.org, Daniel Stone <daniels@...labora.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Riley Andrews <riandrews@...roid.com>,
	ML dri-devel <dri-devel@...ts.freedesktop.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	John Harrison <John.C.Harrison@...el.com>
Subject: Re: [PATCH v5 5/5] staging/android: add flags member to sync ioctl structs

On 1 March 2016 at 13:13, Gustavo Padovan <gustavo@...ovan.org> wrote:
> From: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
>
> Play safe and add flags member to all structs. So we don't need to
> break API or create new IOCTL in the future if new features that requires
> flags arises.
>
> v2: check if flags are valid (zero, in this case)
>
> v3: return -EINVAL if flags are not zero'ed
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
> ---
>  drivers/staging/android/sync.c      | 8 ++++++++
>  drivers/staging/android/uapi/sync.h | 6 ++++++
>  2 files changed, 14 insertions(+)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index 3604e453..3c265ed 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file *sync_file,
>                 goto err_put_fd;
>         }
>
> +       if (data.flags) {
> +               err = -EINVAL;
> +               goto err_put_fd;
> +       }
> +
>         fence2 = sync_file_fdget(data.fd2);
>         if (!fence2) {
>                 err = -ENOENT;
> @@ -504,6 +509,9 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>         if (copy_from_user(&in, (void __user *)arg, sizeof(in)))
>                 return -EFAULT;
>
> +       if (in.flags)
> +               return -EINVAL;
> +
>         info = kzalloc(sizeof(*info), GFP_KERNEL);
>         if (!info)
>                 return -ENOMEM;
> diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
> index a122bb5..11e2d28 100644
> --- a/drivers/staging/android/uapi/sync.h
> +++ b/drivers/staging/android/uapi/sync.h
> @@ -19,11 +19,13 @@
>   * @fd2:       file descriptor of second fence
>   * @name:      name of new fence
>   * @fence:     returns the fd of the new fence to userspace
> + * @flags:     merge_data flags
>   */
>  struct sync_merge_data {
>         __s32   fd2;
>         char    name[32];
>         __s32   fence;
> +       __u32   flags;
The comment from last round still stands, struct size must be multiple
of 64bits. As is the struct will be broken whenever/if we decide to
extend it. See [1] for an alternative wording.

>  };
>
>  /**
> @@ -31,12 +33,14 @@ struct sync_merge_data {
>   * @obj_name:          name of parent sync_timeline
>   * @driver_name:       name of driver implementing the parent
>   * @status:            status of the fence 0:active 1:signaled <0:error
> + * @flags:             fence_info flags
>   * @timestamp_ns:      timestamp of status change in nanoseconds
>   */
>  struct sync_fence_info {
>         char    obj_name[32];
>         char    driver_name[32];
>         __s32   status;
> +       __u32   flags;
>         __u64   timestamp_ns;
>  };
>
> @@ -44,6 +48,7 @@ struct sync_fence_info {
>   * struct sync_file_info - data returned from fence info ioctl
>   * @name:      name of fence
>   * @status:    status of fence. 1: signaled 0:active <0:error
> + * @flags:     sync_file_info flags
>   * @num_fences number of fences in the sync_file
>   * @sync_fence_info: pointer to array of structs sync_fence_info with all
>   *              fences in the sync_file
> @@ -51,6 +56,7 @@ struct sync_fence_info {
>  struct sync_file_info {
>         char    name[32];
>         __s32   status;
> +       __u32   flags;
>         __u32   num_fences;
>
>         __u64   sync_fence_info;
Thanks for taking my suggestion and dropping len. Although I fear that
we introduced a hole which we should be explicitly padded [2].

In both cases the pad should be checked for 0 and -EINVAL should be
returned if that's not the case. This will allow us to potentially
reuse in the future.

Other than that I believe the series looks pretty much spot on.

Cheers,
Emil

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt#n37
[2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt#n32