Re: [uml-devel] Kernel panic: check_ptrace : child exited with status 0x100

[BlaisorBlade <bla...@ya...>]

On Friday 08 October 2004 13:59, bod...@fu... wrote:
> ca...@th... said:
> > Ok, so a new combination.  This is 2.4.27 + 2.4.26-um + all the
> > incremental + Bodo's sysemu-panic patch.  It works fine on non-sysemu
> > hosts, and on a host with the original version of sysemu.

> > I think the key here is that this host has the latest (v5) SKAS patch,
> > whereas the 2.6.7 host kernel used the standard sysemu patch.
Yes, and I'm sorry for that.
> Please note, my knowledge about this only comes from reading the source
> code only. Thus, if I'm wrong, tell me.

> AFAICS, the behavior of the latest skas patches for 2.4 and 2.6 regarding
> sysemu is *very* different. And I believe, the 2.6 is wrong!

Yes, I have now finished studying well all the code acting here. And I now 
understand by myself almost every single word you said, and agree on all.

> Problem:
> On both host versions a process will stop, if it is started with
> PTRACE_SYSEMU and if it tries to execute a systemcall. But what happens
> with the traced systemcall when it is resumed differs between the two host
> versions.

> On host 2.4 the syscall will immediately return to user presenting the
> result that had been written to the stack via ptrace(). This is done no
> matter if the process is resumed with PTRACE_SYSEMU, PTRACE_SYSCALL,
> PTRACE_SINGLESTEP or PTRACE_CONT. On host 2.6 the syscall will immediately
> return to user only if the process is restarted with PTREACE_SYSEMU! In the
> other cases the syscall will be executed on the host, the result from this
> will overwrite the result written via ptrace().
Yes, I confirm the patch I sent in my previous email for the host. I still 
need to test that, but I'll do this soon. It's reattached as 
"fix-sysemu-when-changing-state.patch".

> The check for host's 
> sysemu-support done in UML differs between the sysemu-patches for UML-2.4
> and UML-2.6:
> - In UML-2.4 "getpid()" is written as result (eax) of the systemcall, which
> fakes the syscall-result on a 2.4-host, but does nothing on a 2.6, where it
> again is overwritten by running the syscall on the host! Thus, a UML-2.4
> will run on hosts with sysemu-support only, if it is a 2.4 host!

I.e. UML-2.4 will run on everything but a 2.6 sysemu-supporting host, unless 
the host has the patch I sent in the last mail (supposing it does what it 
should do). I.e. the 2.4 UML check is written the right way. Compliments to 
Jeff for this. However, you did not realize he was fixing it, or I'll flame 
you Jeff, for fixing it without notice in the description.

And the test will fail because it _exit(os_getpid() == pid); will become 
_exit(1);. Btw, with Jeff Dike I don't feel really the danger of comment 
bloat!

> - In UML-2.6 "getpid()" is written to the number of the systemcall! But the
> result in eax is not written, it still contains the original syscall
> number. On a 2.4-host this number is returned. In most cases this will let
> the further checks in UML succeed, but no guarantee...

Well, instead of checking simply that getpid() != truePid, we should also 
check that it either returns either the real getpid() value or the real 
getppid() value (the parent thread makes sure that it gets either one, 
doesn't it?), and have a special failure case when this is false. However, 
this is a separate patch, named uml-more-careful-test-startup.patch.

Instead, the fix for this (against the 2.6.9-rc2 tree; the version Jeff Dike 
included in his tree was correct in this regard) is attached as 
"uml-fix-sysemu-test-startup".

Also, the same difference applies also for 2.4: the original um-sysemu patch 
from Laurent Vivier has the same bug you see on 2.6 - Jeff Dike fixed both 
versions in his trees (I guess he didn't notice the difference, and was 
probably just making it portable; he didn't think that the code used 
orig_eax, he just read Laurent Vivier's mind :-@ ).

>   On a 2.6-host the systemcall with the faked number now will be processed
> on the host. In most cases the number should be invalid, thus the result is
> -ENOSYS, the checks in UML will succeed. But what happens, if the faked
> syscall number is a number known on the host ...
>   Thus a UML-2.6 will run on all host versions (in most cases ...)

> Solution:
> - the host-patch for 2.6 should be modified. Before calling ptrace_notify()
>   do_syscall_trace() should save the state of the PTRACE_SYSEMU
> (true/false) and should use that saved state as return value.
> - check_sysemu() in UML-2.6 should be modified to write the result, not the
> sycall number. And it should do it in a portable way.
You refer to the usage of regs.orig_eax, instead of the portable 
PT_SYSCALL_RET_OFFSET used elsewhere (or in general PT_SYSCALL_*_OFFSET)

> By the way: it is not enough to change the checks only. The 2.6-host's
> behavior will cause problems as well, if a process in UML is singlestepped.

> And there will be problems, if someone switches off sysemu while UML is
> running.
Experienced them, as I said.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729