[uml-devel] Syscalls breaking out

[uml-devel] Syscalls breaking out

[Stroesser, Bodo]

Hi Jeff, Hi BlaisorBlade,

as stated in the thread "Minor problems with interrupted sytemcalls",
two cooperating processes running on UML easily can break out and
execute systemcalls on the host system. To do this, the parent process
singlesteps the child, then the child's systemcalls are executed on the
host.
The code in "kern_do_signal()", that should fix this, handles tt-mode
only (before my patch "interrupted systemcalls" the code even was
skipped), and it handles "int 0x80" systemcalls only! Thus, if the host
supports "sysenter", this instruction can be used to break out from
both, tt- and skas-mode. This can be done, because the hosts
vsyscall-page is available to all processes on the host, even UML
processes.

How should this be fixed? Here my idea:

- move the flag "singlestep_syscall" from thread.mode.tt to thread
- remove singlestepping_tt() and singlestepping_skas(). Add
singlestepping() instead which will check thread.singlestep_syscall
- modify kern_do_signal() to check user's next instruction for a syscall
via is_syscall() in tt-mode AND skas-mode. Also it should do this check
after handle_signal() has been called (signal handler starting could
have failed or signal handler starts with a syscall).
- is_syscall() should check for "int 0x80" and "sysenter", but should
check eax too. If eax contains a invalid systemcall number, the host
kernel will skip the syscall tracing and singlestepping is broken.

A related issue: the host's vsyscall-page is visible and executable to
all processes on the host. This means, it is visible to the UML
processes too. AFAIK this cannot be changed. But UML itself doesn't know
about this page. So it cannot be accessed via ptrace from one uml
process to another. Calling copy_from_user() from is_syscall() would
return an error as well, if a UML user process jumps into the
vsyscall-page while it is singlestepped.
This could be solved by using a ptrace( PEEKTEXT, ...)-call to
host-kernel, but I don't like it. We want to read 2 bytes only, while
ptrace always reads 4 bytes. What about UEIP pointing to the last 3
bytes of a page? What I would prefer, is to support "sysenter" /
vsyscall-page in UML. AFAICS the only way to do that, is to make the
hosts syscall-page available in UML. How to do this:

- in UML's main() check the ELF auxiliary vector for information about
the vsyscall-page (I've written a small test, it's easy to acquire the
info).
- modify the macro "ARCH_DLINFO" to use the hosts vsyscall info, if
present. If there is no info from the host, the macro should no longer
insert anything into the auxiliary vector!
- if the host has a vsyscall page, create a fixed entry for it in UML's
page-table (to be done once at UML start).
- if the host has a vsyscall-page and this page contains
"__kernel_sigreturn" and "__kernel_rt_sigreturn", UML could be modified
to use these (instead of the restorer-stub written to users stack)

If I'm right, UML should automatically support sysenter, if the host
supports it!

Do you agree with my ideas?
I could create a patch for this. Would you welcome it?
(It would overlap with my previos patch, should I merge them?)

Greets
Bodo



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

RE: [uml-devel] Syscalls breaking out

[Stroesser, Bodo]

 
Jeff Dike <jdike@addtoit.com> said:

> Bodo.Stroesser@fujitsu-siemens.com said:
> > (It would overlap with my previos patch, should I merge them?)
> 
> I'm looking at your patches and will get back to you on them, but let
me just comment on this issue first.
>
> I'd prefer these patches be split up into as small units as possible.
That'll make it easier to decide whether they are correct.  It's OK if
they overlap and need to be applied in a particular order.
> 
> So, for example, the API changes could be broken out separately.  Even
if it's two lines of change (the caller and the callee), that's a good
way to split it up.  This part of the kernel has some subtleties, so I'd
prefer to be careful here.

O.K., I could create three new patches.

The first will remove the different possibilities to execute a
systemcall on the host, with one exception: if the UML-user directly
calls the vsyscall entry __kernel_vsyscall while being singlestepped, it
will still break out and will be executed on the host.

The second will enable the vsyscall-page in UML, this will remove the
last (known to me) breakout possibility and will enable the
sysenter-syscall for programs that are not linked "-static".

With the third patch UML will use the "restorer"-stubs in the
vsyscall-page. This will *not* change the stack layout for signal
handlers, but will change the restorers address to be from the
syscall-page.

If this is OK for you, I could send the patches next week.

Bodo

> 
> 				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Syscalls breaking out

[Jeff Dike]

Bodo.Stroesser@fujitsu-siemens.com said:
> (It would overlap with my previos patch, should I merge them?) 

I'm looking at your patches and will get back to you on them, but let me just
comment on this issue first.

I'd prefer these patches be split up into as small units as possible.  That'll
make it easier to decide whether they are correct.  It's OK if they overlap
and need to be applied in a particular order.

So, for example, the API changes could be broken out separately.  Even if it's
two lines of change (the caller and the callee), that's a good way to split it
up.  This part of the kernel has some subtleties, so I'd prefer to be careful
here.

				Jeff



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel