Re: [uml-devel] SYSEMU getting merged - but I'm in doubt

[Bodo Stroesser <bstroesser@fujitsu-siemens.com>]

Bodo Stroesser wrote:
> 
> If we talk about using a new ptrace code for the new API, old UML 
> binaries running
> on a host supporting the new API will recognize that there is no SYSEMU 
> they can
> use. So /proc/sysemu will not allow to switch on or off anything (IIRC, 
> the file
> will not even be created). That means, that an old binary will run safe 
> but slow
> in this case. One could argue, that this is a changed behaviour of the 
> old binary.
> 
> OTOH, if the new API would reuse the same ptrace code, check_sysemu of 
> the old
> binaries will fail on i386 (and I hope on x86_64, too). That means, 
> sysemu again
> will be disabled. AFAICS, it will not refuse to run at all. (Not tested, 
> taken from
> the code only)
> On s390 the check even might succeed accidentally, but that's no 
> problem, as s390
> isn't mainline yet, we can change check_sysemu() to avoid problems. 
> There will
> never be an old binary for s390.
> 
> Resume: it doesn't matter if a new ptrace code is used or the old one is 
> reused.
> Usage of sysemu will be restricted to "new UML on new host" or "old UML 
> on old host"
> as long as host doesn't support _both_ APIs (selectable by two separate 
> ptrace codes
> or by a new flag to PTRACE_SETOPTIONS). AFAICS, there is no reason to 
> change
> /proc/sysemu at all, right?

Some more points:

The new API must have PTRACE_SYSEMU _and_ PTRACE_SYSEMU_SINGLESTEP.
While with the old API SYSEMU_SINGLESTEP was inserted to improve security,
with the new one it will be necessary to allow singlestepping of processes
in UML-SKAS at all. Suppose a singlestepped userspace is stopped at a
syscall interception. Now UML needs to restart it with SYSEMU for syscall
emulation, but also wants to proceed with singlestepping. PTRACE_SYSEMU wouldn't
do the job, as it starts userspace in "normal" mode, no singlestepping.

Also, in tt new API's PTRACE_SYSEMU behaves as PTRACE_SYSCALL does, because tracer
uses PTRACE_CONT after syscall interception. So tt (do_syscall(), ...) needs to be
changed. PTRACE_SYSEMU_SINGLESTEP still should be used, as if it's name were
PTRACE_SYSCALL_SINGLESTEP.

	Bodo


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel