Zhibin Li's GSoC status report - #2 of 12
haoyouab at gmail.com
Sun Jun 23 06:44:16 UTC 2019
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>
> > > On Wed, Jun 19, 2019 at 09:31:25AM +0800, Zhibin Li wrote:
> > > > Just FYI I write a demo 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
> > > > welcomed :).
> > > >
> > > > 
> > > >
> > >
> > >
> > > Well, this is not even an injection into the tracee, it's an
> > > 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
> > > decoders. In this case you need to convince strace to enable
> > > 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 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
> > is
> > executed. Should we consider subverting getfdpath instead?
> >  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
> > 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
but what about adding another option, may be something like -e priv=i915. I
not sure what the option should look like, but there should be a way to
specific device when running strace command, right? Any thoughts?
> Strace-devel mailing list
> Strace-devel at lists.strace.io
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Strace-devel