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

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

[Blaisorblade]

Ok, SYSEMU has been in -mm during 2.6.13 development and is now being merged 
in mainline, without many problems - it should be in Linus's git repository.

However, the point is that *I* have a problem with its current API.

Charles P. Wright expressed interest in using the interface, on private mail, 
however had problems with it - and actually, I cannot disagree with him, 
because the current API happened to be just "use the 2.4 API, and be 
compatible bug-to-bug".

When we intercept a syscall entry, we go to the trouble of saving the current 
kind of tracing (whether SYSEMU or SYSCALL) and then using it after notifying 
the ptracer. There's no actual need to do that, except compatibility with 
2.4, and I'd like to rip it out entirely.

Charles needs to check the syscall type before deciding whether to emulate it 
or not (he says he's working on a filesystem project, so I guess that he 
wants to intercept only some filesystem-related calls).

For UML, if we switch the syscall interception type, we can switch 
interception type one stop later.

I.e., if the user switches to SYSCALL, we resume the process still with 
SYSEMU, then at next stop we use SYSCALL. There's no increase in the number 
of system calls of or context switches.

Actually, /proc/sysemu is just a debugging toy, and supporting it is not that 
important (even if this helps excercising the code, i.e. finding those subtle 
bugs on switching).

Now, the point is: should I ask Linus to drop it for now, clean the interface, 
and resend the cleaned up one, with different ptrace call codes?

The changes aren't that big (a couple of lines), and UML can even keep 
supporting the old interface with a not-so-big cost (apart that 
if /proc/sysemu is not used, UML doesn't care which interface is used).

On the host side, instead, supporting both the broken API and the new one is 
more difficult.

What's your opinion on this? The options are:
1) merge it as-is
2) take it back for now, fix it and merge it for 2.6.15.

And then

2a) drop the trick, and avoid changing ptrace call numbers. Old UMLs will run 
fast, but crash with /proc/sysemu (only root-accessible).

2b) drop the trick and change the ABI - old UMLs will become slower, newer 
ones will support both things, and there will be no "same ABI but different 
behaviour" case.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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] SYSEMU getting merged - but I'm in doubt

[Jeff Dike]

On Sun, Sep 04, 2005 at 05:02:18PM +0200, Blaisorblade wrote:
> Now, the point is: should I ask Linus to drop it for now, clean the 
> interface, and resend the cleaned up one, with different ptrace call codes?

I would be tempted to leave it in and fix it before 2.6.14.  We need different
ptrace codes so that UML knows how to switch interception types, I take it?

UML is the only user, so there aren't really any compatibility issues.

> On the host side, instead, supporting both the broken API and the new one is 
> more difficult.

Yeah, and it shouldn't be done.  This is one reason I'd like to use the same
ptrace codes - it doesn't leave a hole in the codes that says there was a 
broken ABI there once.

> What's your opinion on this? The options are:
> 1) merge it as-is
> 2) take it back for now, fix it and merge it for 2.6.15.

Merge as-is, fix it before 2.6.13, and you get the same thing, except
a release earlier.  I think this shouldn't be a problem, as after the
floodgates close, you still get to fix things you merged early.  This
came about as a result of feedback received because after it went into
-mm, and it seems to me that this is a legitimate change for 2.6.14.

> And then
> 
> 2a) drop the trick, and avoid changing ptrace call numbers. Old UMLs
> will run fast, but crash with /proc/sysemu (only root-accessible).

We should drop /proc/sysemu, if it's there at all, since it's only for
debugging sysemu, and maintain it as a private patch.  So this doesn't
seem like much of an issue.

				Jeff


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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] SYSEMU getting merged - but I'm in doubt

[Bodo Stroesser]

Jeff Dike wrote:
> On Sun, Sep 04, 2005 at 05:02:18PM +0200, Blaisorblade wrote:
> 
>>Now, the point is: should I ask Linus to drop it for now, clean the 
>>interface, and resend the cleaned up one, with different ptrace call codes?
> 
> 
> I would be tempted to leave it in and fix it before 2.6.14.  We need different
> ptrace codes so that UML knows how to switch interception types, I take it?
> 
> UML is the only user, so there aren't really any compatibility issues.
> 
> 
>>On the host side, instead, supporting both the broken API and the new one is 
>>more difficult.
> 
> 
> Yeah, and it shouldn't be done.  This is one reason I'd like to use the same
> ptrace codes - it doesn't leave a hole in the codes that says there was a 
> broken ABI there once.
> 
> 
>>What's your opinion on this? The options are:
>>1) merge it as-is
>>2) take it back for now, fix it and merge it for 2.6.15.
> 
> 
> Merge as-is, fix it before 2.6.13, and you get the same thing, except
> a release earlier.  I think this shouldn't be a problem, as after the
> floodgates close, you still get to fix things you merged early.  This
> came about as a result of feedback received because after it went into
> -mm, and it seems to me that this is a legitimate change for 2.6.14.
> 
> 
>>And then
>>
>>2a) drop the trick, and avoid changing ptrace call numbers. Old UMLs
>>will run fast, but crash with /proc/sysemu (only root-accessible).
> 
> 
> We should drop /proc/sysemu, if it's there at all, since it's only for
> debugging sysemu, and maintain it as a private patch.  So this doesn't
> seem like much of an issue.
> 
> 				Jeff
It would be enough to make /proc/sysemu readonly.
But we need to change check_sysemu(). The current implementation will work
with the old API only.

	Bodo


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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] SYSEMU getting merged - but I'm in doubt

[Blaisorblade]

[-- Attachment #1: Type: text/plain, Size: 2789 bytes --]

On Tuesday 13 September 2005 18:51, Bodo Stroesser wrote:
> Jeff Dike wrote:
> > On Sun, Sep 04, 2005 at 05:02:18PM +0200, Blaisorblade wrote:

> > I would be tempted to leave it in and fix it before 2.6.14.  We need
> > different ptrace codes so that UML knows how to switch interception
> > types, I take it?
Yes, that's the idea.
> > UML is the only user, so there aren't really any compatibility issues.
> >
> >>On the host side, instead, supporting both the broken API and the new one
> >> is more difficult.
> >
> > Yeah, and it shouldn't be done.  This is one reason I'd like to use the
> > same ptrace codes - it doesn't leave a hole in the codes that says there
> > was a broken ABI there once.
Do you see contiguos codes? We jump from 24 to 31-32 (it was done for 
something like having a common ABI with 2.4 and 2.6 hosts - don't ask me what 
filled previous slots, however), so you shouldn't worry for this.

> >>What's your opinion on this? The options are:
> >>1) merge it as-is
> >>2) take it back for now, fix it and merge it for 2.6.15.

> > Merge as-is, fix it before 2.6.13, and you get the same thing, except
> > a release earlier.  I think this shouldn't be a problem, as after the
> > floodgates close, you still get to fix things you merged early.  This
> > came about as a result of feedback received because after it went into
> > -mm, and it seems to me that this is a legitimate change for 2.6.14.

> >>And then

> >>2a) drop the trick, and avoid changing ptrace call numbers. Old UMLs
> >>will run fast, but crash with /proc/sysemu (only root-accessible).

> > We should drop /proc/sysemu, if it's there at all, since it's only for
> > debugging sysemu, and maintain it as a private patch.  So this doesn't
> > seem like much of an issue.

> > 				Jeff

> It would be enough to make /proc/sysemu readonly.
Yes, but my main concern is compatibility with existing binaries. They'll work 
as long as nobody tries to write on /proc/sysemu if the API is changed.

However, I've put something together, so I've attached the host patch (I'm 
also a bit ill this days, so I want to make sure there's at least the 
possibility for anybody else to fix it).

This has not yet been tested (I'm gonna do it) - but it seems that it's little 
enough to make the new behaviour a ptrace option, if needed.

I wouldn't like to break in *anything* behaviour of old binaries, if possible.

> But we need to change check_sysemu(). The current implementation will work
> with the old API only.
Would it refuse using sysemu or refuse to run at all? That's another 
interesting point.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

[-- Attachment #2: sysemu-new-interface.patch --]
[-- Type: text/x-diff, Size: 932 bytes --]

sysemu-new-interface


Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 linux-2.6.git-paolo/arch/i386/kernel/ptrace.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletion(-)

diff -puN arch/i386/kernel/ptrace.c~sysemu-new-interface arch/i386/kernel/ptrace.c
--- linux-2.6.git/arch/i386/kernel/ptrace.c~sysemu-new-interface	2005-07-27 20:38:35.000000000 +0200
+++ linux-2.6.git-paolo/arch/i386/kernel/ptrace.c	2005-07-27 20:40:25.000000000 +0200
@@ -749,7 +749,9 @@ int do_syscall_trace(struct pt_regs *reg
 		send_sig(current->exit_code, current, 1);
 		current->exit_code = 0;
 	}
-	ret = is_sysemu;
+	/* The debugger might have changed the syscall intercepting mode. Apply
+	 * this update now, rather than at next syscall. */
+	ret = test_thread_flag(TIF_SYSCALL_EMU);
  out:
 	if (unlikely(current->audit_context) && !entryexit)
 		audit_syscall_entry(current, AUDIT_ARCH_I386, regs->orig_eax,
_

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

[Bodo Stroesser]

Blaisorblade wrote:
> On Tuesday 13 September 2005 18:51, Bodo Stroesser wrote:
> 
>>Jeff Dike wrote:
>>
>>>On Sun, Sep 04, 2005 at 05:02:18PM +0200, Blaisorblade wrote:
> 
> 
>>>I would be tempted to leave it in and fix it before 2.6.14.  We need
>>>different ptrace codes so that UML knows how to switch interception
>>>types, I take it?
> 
> Yes, that's the idea.
> 
>>>UML is the only user, so there aren't really any compatibility issues.
>>>
>>>
>>>>On the host side, instead, supporting both the broken API and the new one
>>>>is more difficult.
>>>
>>>Yeah, and it shouldn't be done.  This is one reason I'd like to use the
>>>same ptrace codes - it doesn't leave a hole in the codes that says there
>>>was a broken ABI there once.
> 
> Do you see contiguos codes? We jump from 24 to 31-32 (it was done for 
> something like having a common ABI with 2.4 and 2.6 hosts - don't ask me what 
> filled previous slots, however), so you shouldn't worry for this.
> 
> 
>>>>What's your opinion on this? The options are:
>>>>1) merge it as-is
>>>>2) take it back for now, fix it and merge it for 2.6.15.
> 
> 
>>>Merge as-is, fix it before 2.6.13, and you get the same thing, except
>>>a release earlier.  I think this shouldn't be a problem, as after the
>>>floodgates close, you still get to fix things you merged early.  This
>>>came about as a result of feedback received because after it went into
>>>-mm, and it seems to me that this is a legitimate change for 2.6.14.
> 
> 
>>>>And then
> 
> 
>>>>2a) drop the trick, and avoid changing ptrace call numbers. Old UMLs
>>>>will run fast, but crash with /proc/sysemu (only root-accessible).
> 
> 
>>>We should drop /proc/sysemu, if it's there at all, since it's only for
>>>debugging sysemu, and maintain it as a private patch.  So this doesn't
>>>seem like much of an issue.
> 
> 
>>>				Jeff
> 
> 
>>It would be enough to make /proc/sysemu readonly.
> 
> Yes, but my main concern is compatibility with existing binaries. They'll work 
> as long as nobody tries to write on /proc/sysemu if the API is changed.
> 
> However, I've put something together, so I've attached the host patch (I'm 
> also a bit ill this days, so I want to make sure there's at least the 
> possibility for anybody else to fix it).
> 
> This has not yet been tested (I'm gonna do it) - but it seems that it's little 
> enough to make the new behaviour a ptrace option, if needed.
> 
> I wouldn't like to break in *anything* behaviour of old binaries, if possible.
> 
> 
>>But we need to change check_sysemu(). The current implementation will work
>>with the old API only.
> 
> Would it refuse using sysemu or refuse to run at all? That's another 
> interesting point.

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?

	Bodo
> 
> 
> ------------------------------------------------------------------------
> 
> sysemu-new-interface
> 
> 
> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
> ---
> 
>  linux-2.6.git-paolo/arch/i386/kernel/ptrace.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff -puN arch/i386/kernel/ptrace.c~sysemu-new-interface arch/i386/kernel/ptrace.c
> --- linux-2.6.git/arch/i386/kernel/ptrace.c~sysemu-new-interface	2005-07-27 20:38:35.000000000 +0200
> +++ linux-2.6.git-paolo/arch/i386/kernel/ptrace.c	2005-07-27 20:40:25.000000000 +0200
> @@ -749,7 +749,9 @@ int do_syscall_trace(struct pt_regs *reg
>  		send_sig(current->exit_code, current, 1);
>  		current->exit_code = 0;
>  	}
> -	ret = is_sysemu;
> +	/* The debugger might have changed the syscall intercepting mode. Apply
> +	 * this update now, rather than at next syscall. */
> +	ret = test_thread_flag(TIF_SYSCALL_EMU);
>   out:
>  	if (unlikely(current->audit_context) && !entryexit)
>  		audit_syscall_entry(current, AUDIT_ARCH_I386, regs->orig_eax,
> _


-------------------------------------------------------
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

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

[Bodo Stroesser]

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

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

[Blaisorblade]

On Wednesday 14 September 2005 13:48, Bodo Stroesser wrote:
> Bodo Stroesser wrote:
> > 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). 
Nobody implemented sysemu for x86_64, at least to my knowledge.

I hoped to finish skas first, but stopped on that problem.
> > 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.

> Some more points:

> The new API must have PTRACE_SYSEMU _and_ PTRACE_SYSEMU_SINGLESTEP.
Granted.
> 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.
Hmm, I hadn't looked at this detail...
> 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.
Ok, I think it's enough to warrant keeping the current behaviour and adding 
later an option, and/or removing it for now and merging it later.

Unless somebody manages to fix all this in time. I don't think I'm likely to 
accomplish this, sorry.
> 	Bodo

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
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

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

[Jeff Dike]

On Tue, Sep 13, 2005 at 08:23:10PM +0200, Blaisorblade wrote:
> Do you see contiguos codes? We jump from 24 to 31-32 (it was done for 
> something like having a common ABI with 2.4 and 2.6 hosts - don't ask me what 
> filled previous slots, however), so you shouldn't worry for this.

Whoops, didn't notice this.

				Jeff


-------------------------------------------------------
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