Zhibin Li's GSoC status report - #2 of 12
haoyouab at gmail.com
Sat Jun 22 11:00:55 UTC 2019
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 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 :).
> > 
> 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
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:
The key point to enable i915-specifc decoder is to obtain a valid device
from the fd by calling getfdpath. In this case it's /dev/dri/card0. Only
readlink() will try to read the driver name which links to that device,
readlink("/sys/class/drm/card0/device/driver", ...). So if we use fd = -1
usually do, getfdpath will fail and the decoder will return before readlink
executed. Should we consider subverting getfdpath instead?
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
My first thought is to add something like -e xxx=i915 (that's why I used
-e inject=ioctl:priv=i915 but I was wrong about the 'injection' concept).
Anyway, my point is that there should be a way to tell strace which device
decoder to invoke in the tests because generally we don't use a valid fd.
> Strace-devel mailing list
> Strace-devel at lists.strace.io
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Strace-devel