On 29/05/15 15:44, Patrick Welche wrote:
Ah, you're right, you do need to blanket /tmp/foo.img since the path is
passed to syscalls both via opendisk (which I assume uses open() or
something like that) and via ioctl() which just hides the path in some
covert ioctl protocol. Since rumphijack doesn't see inside the ioctl
parameter -- and let's not start teaching hijack about all gazillion ioctl
parameters -- it cannot adjust the path.
In my original hijack.sh, I had /tmp/foo.img in blanket - I see that
it is my changes to vnd.c which broke things. Original vnd.c
passes the above with the extra /tmp/foo.img. My vnd.c fails with
$ vnconfig -l
vnconfig: open: vnd0: Unknown error: 32639
Well, vnconfig -l does a readdir on /dev, so you need to blanket /dev/
for that to work.
Hijack or not, the syscall path on the client side is exactly the same
(through rumpclient_syscall), so using a different route to get there will
do nothing for solving the problem.
Oddly, with original (working) vnd.c, I get
$ obj.amd64/rump.vnconfig -l
rump.vnconfig: VNDIOCGET: Bad file descriptor
Why oddly?
What am I missing? I expect rump.vnconfig to connect to RUMP_SERVER and
DTRT without the need for hijacking - is that correct? rump.vnconfig gives
me an error about VNDIOCGET, so I should expect that a breakpoint in
rump_allserver at vndioctl() should fire? I don't see that...
(Tracing rump.vnconfig, I do step into rumpclient_init() and it parses
RUMP_SERVER correctly, unit fd is now 11, vn_ioctl -> rump__sysimpl_ioctl,
rsys_syscall returns an error, and breakpoint in vndioctl doesn't fire)
(probably should try again that this really is with the original vnd.c...)
If you modify code, you have to modify it correctly for TRT to happen.
If you get EBADF, your call in the kernel most likely never reaches the
vnd driver. Did you convert vnconfig to use opendisk1()?
For future reference, put a breakpoint earlier along the callpath. All
remote syscalls go through hyp_syscall, so that's a good place to start.
