linux-kernel - Re: [PATCH] drm/vc4: Add a pad field to align drm_vc4_submit

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] [day] [month] [year] [list]

Message-ID: <CAOZHkRyboQ2uPmv6EXZSnKFLEchBavRYy1jAzm6VzxfqSEgQkw@mail.gmail.com>
Date:   Tue, 1 May 2018 02:11:37 +0200
From:   Stefan Schake <stschake@...il.com>
To:     Eric Anholt <eric@...olt.net>
Cc:     dri-devel <dri-devel@...ts.freedesktop.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/vc4: Add a pad field to align drm_vc4_submit_cl to 64 bits.

On Tue, May 1, 2018 at 1:59 AM, Eric Anholt <eric@...olt.net> wrote:
> I had originally asked Stefan Schake to drop the pad field from the
> syncobj changes that just landed, because I couldn't come up with a
> reason to align to 64 bits.
>
> Talking with Dave Airlie about the new v3d driver's submit ioctl, we
> came up with a reason: sizeof() on 64-bit platforms may align to 64
> bits, in which case the userspace will be submitting the aligned size
> and the final 32 bits won't be zero-padded by the kernel.  If
> userspace doesn't zero-fill, then a future ABI change adding a 32-bit
> field at the end could potentially cause the kernel to read undefined
> data from old userspace (our userspace happens to use structure
> initialization that zero-fills, but as a general rule we try not to
> rely on that in the kernel).
>

Did a quick sizeof check on arm64 and that indeed came to 176 mod 8 = 0,
suggesting we need this additional pad. So fwiw

Reviewed-by: Stefan Schake <stschake@...il.com>

Thanks,
Stefan