Zhibin Li's GSoC status report - #2 of 12

[Zhibin Li]

On Sat, Jun 22, 2019 at 9:15 PM Dmitry V. Levin <ldv at altlinux.org> wrote:

> On Sat, Jun 22, 2019 at 07:00:55PM +0800, Zhibin Li wrote:
> > On Fri, Jun 21, 2019 at 7:13 PM Dmitry V. Levin <ldv at altlinux.org>
> wrote:
> >
> > > On Wed, Jun 19, 2019 at 09:31:25AM +0800, Zhibin Li wrote:
> > > > Just FYI I write a demo[1] of priv qualifier for -e inject.
> > > > It can be used like:
> > > > # strace -eioctl -e inject=ioctl:retval=42:priv=i915 ./a.out
> > > > Basically it works as I expect but this is a experimental patch.
> > > > The way it makes things work may be ugly so any commnets/suggestions
> are
> > > > welcomed :).
> > > >
> > > > [1]
> > > >
> > >
> https://github.com/haoyouab/strace/commit/9c915fe7ed66f08b41b5d9c72e3d03b09c8ca9a3
> > >
> > > Well, this is not even an injection into the tracee, it's an
> overwriting
> > > of strace internal tcp->_priv_data with arbitrary data.
> > >
> > > Yes, it's actually an overwriting.
> >
> > > Yes, it's notoriously difficult to implement a positive testing of
> ioctl
> > > decoders.  In this case you need to convince strace to enable
> i915-specific
> > > decoder.
> >
> > If you could subvert e.g. readlink("/sys/class/drm/null/device/driver",
> ...)
> > > to return something that ends with /i915, this would be enough for
> > > drm_is_driver(tcp, "i915") to return true.
> > >
> > Currently in drm.c[1] the execution sequence is:
> > getfdpath(...);
> > readlink(...);
> > The key point to enable i915-specifc decoder is to obtain a valid device
> > path
> > from the fd by calling getfdpath. In this case it's /dev/dri/card0. Only
> > after that
> > readlink() will try to read the driver name which links to that device,
> > which is
> > readlink("/sys/class/drm/card0/device/driver", ...). So if we use fd = -1
> > like we
> > usually do, getfdpath will fail and the decoder will return before
> readlink
> > is
> > executed. Should we consider subverting getfdpath instead?
> >
> > [1] https://github.com/haoyouab/strace/blob/stuff/drm.c#L33
> >
> > My question here is that in order to convince strace when we run tests, a
> > string that explicitly specifies the device name (e.g. "i915", "nouveau")
> > has to be used along with an option and passed to strace, right? Because
> > there are many other device specific ioctls like amdgpu, nouveau. When
> the
> > tests are running, strace has to know which device specific decoder to
> > enable.


> We are not bound to use fd == -1, we can use any descriptor in our reach,
> e.g. we can open /dev/null and use it instead.
>
Oh I see.
BTW may I ask what's the problem/concern of convincing strace to call device
specific decoders by overwriting the internal tcp->_priv_data? It is no
injection
but what about adding another option, may be something like -e priv=i915. I
am
not sure what the option should look like, but there should be a way to
specify a
specific device when running strace command, right? Any thoughts?

>
> --
> ldv
> --
> Strace-devel mailing list
> Strace-devel at lists.strace.io
> https://lists.strace.io/mailman/listinfo/strace-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20190623/b026d3da/attachment.html>