[PATCH 03/48] staging: etnaviv: remove compat MMU code

[Russell King - ARM Linux]

On Wed, Oct 21, 2015 at 04:53:50PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 21.10.2015, 14:37 +0100 schrieb Russell King - ARM
> Linux:
> > On Wed, Oct 21, 2015 at 02:37:16PM +0200, Lucas Stach wrote:
> > > Am Mittwoch, den 21.10.2015, 12:35 +0100 schrieb Russell King - ARM
> > > Linux:
> > > > On Fri, Sep 25, 2015 at 01:18:48PM +0100, Russell King - ARM Linux wrote:
> > > > > On Fri, Sep 25, 2015 at 01:57:15PM +0200, Lucas Stach wrote:
> > > > > > There is no point in keeping backwards compatibility to older
> > > > > > kernel versions in a driver destined to mainline.
> > > > > 
> > > > > You are correct, however the repository I keep is always based on the
> > > > > previous non-rc kernel release, and I want it to work not only with
> > > > > that release, but also the future -rc's as well.  It means that from
> > > > > time to time, I will include compatibility across a merge window, but
> > > > > I do intend to drop it.
> > > > 
> > > > I'm not sure what version you've generated this patch against, but I
> > > > can't apply it without significant changes to your patch.
> > > > 
> > > > I think instead, I'm going to create a patch removing the v4.1 code
> > > > from my commit myself, and merge it into my original commit as the
> > > > 4.1 code is no longer relevant.
> > > > 
> > > 
> > > That's fine with me.
> > 
> > Applying these patches on top of my drm-etnaviv-devel branch:
> > 
> > staging: etnaviv: debugfs: add possibility to dump kernel buffer
> > staging: etnaviv: change etnaviv_buffer_init() to return prefetch
> > staging: etnaviv: remove submit type
> > staging: etnaviv: rewrite submit interface to use copy from user
> > 
> > with the corresponding DDX changes results in a kernel which silently
> > locks solid when Xorg starts up.
> > 
> For the ML records:
> 
> As discussed on IRC this is another case of missing input validation
> with userspace passing in wrong reloc offsets, the kernel omitting
> proper validation and consequently stomping over unrelated memory.

I think it wasn't stomping on unrelated memory, but on parts of the
command buffer which were part of valid commands for the GPU - and
changing them to be invalid commands.

I wonder how many GPU drivers that's possible - how many verify that
the list of relocations points to places that need addresses filled
in and not GPU commands... and can relocations be used to exploit the
GPU to do something it shouldn't.

I guess that's less of a problem where the GPU sits behind an IOMMU
which prevents it getting at random bits of user memory, but allowing
userspace to trample over the command stream in this way can't be good.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.