linux-kernel - Re: [PATCH 0/2] ptrace_vm: ptrace for syscall emulation virtual machines

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090408121851.GE24173@cs.unibo.it>
Date:	Wed, 8 Apr 2009 14:18:51 +0200
From:	Renzo Davoli <renzo@...unibo.it>
To:	Américo Wang <xiyou.wangcong@...il.com>
Cc:	linux-kernel@...r.kernel.org, Jeff Dike <jdike@...toit.com>,
	user-mode-linux-devel@...ts.sourceforge.net,
	mtk.manpages@...il.com, Roland McGrath <roland@...hat.com>
Subject: Re: [PATCH 0/2] ptrace_vm: ptrace for syscall emulation virtual
	machines

> > #endif
> > #ifdef PTRACE_SINGLEBLOCK
> >   case PTRACE_SINGLEBLOCK:
> > #endif
> > #ifdef PTRACE_SYSEMU
> >   case PTRACE_SYSEMU:
> >   case PTRACE_SYSEMU_SINGLESTEP:
> > #endif
> >   case PTRACE_SYSCALL:
> >   case PTRACE_CONT:
> >     return ptrace_resume(child, request, 0, data);
> >+/* statements added for PTRACE_VM management */
> >+#ifdef PTRACE_VM
> >+  case PTRACE_VM:
> >+#ifdef PTRACE_VM_SINGLESTEP
> >+  case PTRACE_VM_SINGLESTEP:
> >+#endif
> >+#ifdef PTRACE_VM_SINGLEBLOCK
> >+  case PTRACE_VM_SINGLEBLOCK:
> >+#endif
> >+    return ptrace_resume(child, PTRACE_VM_TAGS_MAPPING(request), addr, data);
> >+#endif
> >....
> >  
> 
> Hmmm, I see your points. Thanks for your analysis.
> 
The "resume tags" SYSCALL, SINGLESTEP/SINGLEBLOCK, CONT give to ptrace
the command to resume and indicate when ptrace must stop next time.
The VM_SKIPCALL, VM_SKIPEXIT tags refer to the current system call.
The two sets are independent, orthogonal.

I may want to skip this system call and stop either at the next system call
or at the next block, instruction or never.
As usual, everything is possible with or without some tags, the difference
in in this case in terms of clearness of the interface.

If we'd provide only a PTRACE_VM call (namely a PTRACE_VM_SYSCALL)
to resume up to the next syscall it was not possible to use it 
to implement a virtualized "ptrace".
The virtual ptrace call may need to stop the process after an instruction
or a block as it was requested to do so.
In this case the VM monitor should use PTRACE_SINGLE* without the
VM_SKIP* optimization (maybe faking the execution of a getpid
to skip a system call, like in the old times of User mode Linux).
For a similar reason PTRACE_SYSEMY_SINGLESTEP was added in the kernel.

WHy we should make life harder to VM monitor designer?

We could also have a unique PTRACE_VM tag and encode both
SYSCALL/SINGLESTEP/SINGLEBLOCK/BLOCK
and
SKIPCALL/SKIPEXIT
in different bits inside the addr field.

Again, this is a trick to use just one tag.
It is a matter of values.
Efficiency is the meaning of this patch, so it is a conditio
sine qua non.
Apart from efficiency, what do we want most?
Clearness of interface design?
Back compatibility for very improbable cases?

I bet on the former, usually it is an insurance for the future.

	renzo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/