<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 21, 2019 at 7:13 PM Dmitry V. Levin <<a href="mailto:ldv@altlinux.org">ldv@altlinux.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jun 19, 2019 at 09:31:25AM +0800, Zhibin Li wrote:<br>
> Just FYI I write a demo[1] of priv qualifier for -e inject.<br>
> It can be used like:<br>
> # strace -eioctl -e inject=ioctl:retval=42:priv=i915 ./a.out<br>
> Basically it works as I expect but this is a experimental patch.<br>
> The way it makes things work may be ugly so any commnets/suggestions are<br>
> welcomed :).<br>
> <br>
> [1]<br>
> <a href="https://github.com/haoyouab/strace/commit/9c915fe7ed66f08b41b5d9c72e3d03b09c8ca9a3" rel="noreferrer" target="_blank">https://github.com/haoyouab/strace/commit/9c915fe7ed66f08b41b5d9c72e3d03b09c8ca9a3</a><br>
<br>
Well, this is not even an injection into the tracee, it's an overwriting<br>
of strace internal tcp->_priv_data with arbitrary data.<br>
<br></blockquote><div>Yes, it's actually an overwriting.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Yes, it's notoriously difficult to implement a positive testing of ioctl<br>
decoders.  In this case you need to convince strace to enable i915-specific<br>
decoder.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you could subvert e.g. readlink("/sys/class/drm/null/device/driver", ...)<br>
to return something that ends with /i915, this would be enough for<br>
drm_is_driver(tcp, "i915") to return true.<br></blockquote><div>Currently in drm.c[1] the execution sequence is:</div><div>getfdpath(...);<br></div><div>readlink(...);</div><div>The key point to enable i915-specifc decoder is to obtain a valid device path</div><div>from the fd by calling getfdpath. In this case it's /dev/dri/card0. Only after that</div><div>readlink() will try to read the driver name which links to that device, which is</div><div>readlink("/sys/class/drm/card0/device/driver", ...). So if we use fd = -1 like we</div><div>usually do, getfdpath will fail and the decoder will return before readlink is</div><div>executed. Should we consider subverting getfdpath instead?</div><div><br></div><div>[1] <a href="https://github.com/haoyouab/strace/blob/stuff/drm.c#L33">https://github.com/haoyouab/strace/blob/stuff/drm.c#L33</a></div><div><br></div><div>My question here is that in order to convince strace when we run tests, a<br>string that explicitly specifies the device name (e.g. "i915", "nouveau")<br>has to be used along with an option and passed to strace, right? Because<br>there are many other device specific ioctls like amdgpu, nouveau. When the<br>tests are running, strace has to know which device specific decoder to<br>enable.<br><br>My first thought is to add something like -e xxx=i915 (that's why I used<br>-e inject=ioctl:priv=i915 but I was wrong about the 'injection' concept).<br>Anyway, my point is that there should be a way to tell strace which device<br>decoder to invoke in the tests because generally we don't use a valid fd.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
ldv<br>
-- <br>
Strace-devel mailing list<br>
<a href="mailto:Strace-devel@lists.strace.io" target="_blank">Strace-devel@lists.strace.io</a><br>
<a href="https://lists.strace.io/mailman/listinfo/strace-devel" rel="noreferrer" target="_blank">https://lists.strace.io/mailman/listinfo/strace-devel</a><br>
</blockquote></div></div>