[Mesa-dev] [PATCH] dri/kms: Always zero out struct drm_mode_create_dumb

[Thierry Reding]

On Sun, Nov 16, 2014 at 01:37:52AM +0000, Emil Velikov wrote:
> On 13/11/14 18:05, Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > The DRM_IOCTL_MODE_CREATE_DUMB (and others) IOCTL isn't very rigorously
> > specified, which has the effect that some kernel drivers do not consider
> > the .pitch and .size fields of struct drm_mode_create_dumb outputs only.
> > Instead they will use these as lower bounds and overwrite them only if
> > the values that they compute are larger than what userspace provided.
> > 
> > This works if and only if userspace initializes the fields explicitly to
> > either 0 or some meaningful value. However, if userspace just leaves the
> > values uninitialized and the struct drm_mode_create_dumb is allocated on
> > the stack for example, the driver may try to overallocate buffers.
> > 
> > Fortunately most userspace does zero out the structure before passing it
> > to the IOCTL, but there are rare exceptions. Mesa is one of them. In an
> > attempt to rectify this situation, kernel drivers are being updated to
> > not use the .pitch and .size fields as inputs. However in order to fix
> > the issue with older kernels, make sure that Mesa always zeros out the
> > structure as well.
> > 
> > Future IOCTLs should be more rigorously defined so that structures can
> > be validated and IOCTLs rejected if output fields aren't set to zero.
> > 
> Thanks Thierry.
> 
> I'm pretty sure the intent here was not to misuse the API, yet again
> zeroing the struct sounds like a good idea. I've added Daniel's r-b and
> pushed this to master.

I didn't mean to imply that there were any such intentions. In fact the
API documents that these fields are outputs so it shouldn't be necessary
to set them. As such, the Mesa code wasn't doing anything wrong. But it
turns out this documentation wasn't sufficient and some drivers used the
fields nevertheless.

> Do you think it's of any use if we push this for the stable branches ?
> I've not checked your drm changes, this I don't know if we actually
> check/validate pitch & size. Is the ioctl going to carry on, throw a
> warning or just error out ?

I don't think this needs to go into stable branches. The only drivers
that were using this were ones that are unlikely to be used with Mesa.
The only reason I noticed is because I've been working on a patch that
lets Nouveau integrate better on Tegra, which has the side-effect of
these dumb buffer allocations going through the Tegra DRM driver.

The DRM changes happened in two parts: first all drivers that were
abusing these fields were changed not to do that anymore. The second
change was to zero out these fields in the DRM core before the IOCTL
data is passed into drivers so that new drivers won't fall into the
same trap. That means even for the rare cases where this is actually
relevant new kernels will be able to cope with older Mesa releases.

For future IOCTLs the decision was made to better document inputs and
outputs as well as require outputs to be zeroed out by userspace so that
the kernel can run some sanity checks and refuse an IOCTL with invalid
input/output.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141117/a5b57d2e/attachment.sig>