user-mode-linux-devel

Re: [User-mode-linux-devel] An irq fix check-in

[William S. <wst...@po...>]

Good afternoon, Jeff,

On Wed, 2 Aug 2000, Jeff Dike wrote:

> > No idea whether that fixes it; both a version patched with the stock
> > sourceforge patch and one overlaid with the cvs tree failt to compile
> > with the following error.
> 
> Don't put your pool in /usr/src/linux.  Put it somewhere else, and those 
> compile problems will go away.

	I really hope you'll forgive me; I'm being terribly dense on
this. :-(

1) I've opened up the pristine 2.4.0-test5 kernel tree in
/usr/uml-source/linux/

2) I've taken the cvs tree (minus the CVS/ directories) and opened it up
on top of the source tree.

	The compile still comes up with:

gcc -D__KERNEL__ -I/usr/uml-source/linux/include -Wall -Wstrict-prototypes -O2  -g   -U__i386__ -Ui386 -D__arch_um__ -DSUBARCH="i386" -DNESTING=0 -fno-strict-aliasing  -I../include  -c -o syscall_kern.o syscall_kern.c
syscall_kern.c: In function `um_mount':
syscall_kern.c:25: warning: implicit declaration of function `sys_mount'
syscall_kern.c: In function `old_select':
syscall_kern.c:191: warning: implicit declaration of function `sys_select'
gcc -D__KERNEL__ -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -g -U__i386__ -Ui386 -D__arch_um__ -DSUBARCH="i386" -DNESTING=0 -fno-strict-aliasing -I../include -I../include -c -o syscall_user.o syscall_user.c
In file included from syscall_user.c:23:
/usr/include/asm/unistd.h:14: conflicting types for `open'
/usr/include/fcntl.h:68: previous declaration of `open'
/usr/include/asm/unistd.h:21: conflicting types for `dup'
/usr/include/unistd.h:437: previous declaration of `dup'
/usr/include/asm/unistd.h:37: conflicting types for `waitpid'
/usr/include/sys/wait.h:132: previous declaration of `waitpid'
make[1]: *** [syscall_user.o] Error 1
make[1]: Leaving directory `/usr/uml-source/linux/arch/um/kernel'
make: *** [_dir_/usr/uml-source/linux/arch/um/kernel] Error 2

	When I strip out all the other filesystem support, I get the exact
same error.

	I'm completely missing some crucial piece of the build
process.  Any guesses?
	What, if anything, should be under /usr/src/linux while I'm
building uml in a different directory?  Where should
/usr/include/{asm|linux|scsi} point?
	Cheers,
	- Bill

---------------------------------------------------------------------------
	"Computers let you make more mistakes faster than any other
invention in human history, with the possible exception of handguns and
tequila." 
	-- Mitch Radcliffe
(Courtesy of Hugo van der Kooij <hvd...@ca...>)
--------------------------------------------------------------------------
William Stearns (wst...@po...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

Re: [User-mode-linux-devel] An irq fix check-in

[Jeff D. <jd...@ka...>]

> No idea whether that fixes it; both a version patched with the stock
> sourceforge patch and one overlaid with the cvs tree failt to compile
> with the following error.

Don't put your pool in /usr/src/linux.  Put it somewhere else, and those 
compile problems will go away.

				Jeff

Re: [User-mode-linux-devel] An irq fix check-in

[William S. <wst...@po...>]

On Wed, 2 Aug 2000, Jeff Dike wrote:

> wst...@po... said:
> > I can't even get the test kernel built before you've found and fixed
> > the problem!
> 
> I take it that fixed the bug?
> 
> I wasn't sure because I couldn't get a crash the way you did, and when I did, 
> the panic wasn't where it was for you.

	No idea whether that fixes it; both a version patched with the
stock sourceforge patch and one overlaid with the cvs tree failt to
compile with the following error.

gcc -D__KERNEL__ -I/usr/src/linux-2.4.0/include -Wall -Wstrict-prototypes -O2  -g   -U__i386__ -Ui386 -D__arch_um__ -DSUBARCH="i386" -DNESTING=0 -fno-strict-aliasing  - I../include  -c -o syscall_kern.o syscall_kern.c
gcc -D__KERNEL__ -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -g -U__i386__ -Ui386 -D__arch_um__ -DSUBARCH="i386" -DNESTING=0 -fno-strict-aliasing -I../include -I../include -c -o syscall_user.o syscall_user.c
In file included from syscall_user.c:23:
/usr/include/asm/unistd.h:14: conflicting types for `open'
/usr/include/fcntl.h:68: previous declaration of `open'
/usr/include/asm/unistd.h:21: conflicting types for `dup'
/usr/include/unistd.h:437: previous declaration of `dup'
/usr/include/asm/unistd.h:37: conflicting types for `waitpid'
/usr/include/sys/wait.h:132: previous declaration of `waitpid'
syscall_kern.c: In function `um_mount':
syscall_kern.c:25: warning: implicit declaration of function `sys_mount'
make[1]: *** [syscall_user.o] Error 1
make[1]: *** Waiting for unfinished jobs....
syscall_kern.c: In function `old_select':
syscall_kern.c:191: warning: implicit declaration of function `sys_select'
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/usr/src/linux-2.4.0/arch/um/kernel'
make: *** [_dir_/usr/src/linux-2.4.0/arch/um/kernel] Error 2

	I'll strip the configuration back to a standard uml setup and try
again (I had added a few of the filesystem choices).
	Cheers,
	- Bill

---------------------------------------------------------------------------
	"Windows 95 will now attempt to blow chunks across your primary
partition.  Press any key to continue..." 
(Courtesy of "Eric Princen" <epr...@ma...>)
--------------------------------------------------------------------------
William Stearns (wst...@po...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

Re: [User-mode-linux-devel] An irq fix check-in

[Jeff D. <jd...@ka...>]

wst...@po... said:
> I can't even get the test kernel built before you've found and fixed
> the problem!

I take it that fixed the bug?

I wasn't sure because I couldn't get a crash the way you did, and when I did, 
the panic wasn't where it was for you.

				Jeff

Re: [User-mode-linux-devel] An irq fix check-in

[William S. <wst...@po...>]

Good afternoon, Jeff,
	Darn it, that's no fair!  I can't even get the test kernel built
before you've found and fixed the problem!
	*smile*

On Wed, 2 Aug 2000, Jeff Dike wrote:

> The crash that Bill Stearns pointed out yesterday seems to have been caused by 
> an irq_save bug.  It was enabling signals when it should have been disabling 
> them, which is very bad.
> 
> So, the fix is checked in now.  Grab the latest stuff if you're seeing strange 
> behavoir.  I've seen process segfaults, process hangs in strange places, and 
> kernel memory corruption.  I'm tempted to blame all of that on this bug so I 
> can claim to have completely bug-free code.

	*laugh*  What an optimist.
	I'll let you know once I can get a kernel compiled off cvs.
	Cheers,
	- Bill

---------------------------------------------------------------------------
	Customer: I'm running Windows '98
	Tech: Yes.
	Customer: My computer isn't working now.
	Tech:  Yes, you said that.
(Courtesy of phazer <ph...@ba...>)
--------------------------------------------------------------------------
William Stearns (wst...@po...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

[User-mode-linux-devel] An irq fix check-in

[Jeff D. <jd...@ka...>]

The crash that Bill Stearns pointed out yesterday seems to have been caused by 
an irq_save bug.  It was enabling signals when it should have been disabling 
them, which is very bad.

So, the fix is checked in now.  Grab the latest stuff if you're seeing strange 
behavoir.  I've seen process segfaults, process hangs in strange places, and 
kernel memory corruption.  I'm tempted to blame all of that on this bug so I 
can claim to have completely bug-free code.

				Jeff

[User-mode-linux-devel] test5 changes are checked in

[Jeff D. <jd...@ka...>]

This is an update to 2.4.0-test5.  Jim Leu's virtual ethernet driver and the 
userspace tools are now in CVS as well.

				Jeff

Re: [User-mode-linux-devel] Source tarball

[William S. <wst...@po...>]

Good evening, Chris and Manjunath,

On Wed, 19 Jul 2000, Chris Lattner wrote:

> Download a tarball of the 2.4test4 source from kernel.org... then download
> the patch that goes against it... apply the patch and you have the
> source!  :)
> 
> If you need more info, try looking at patch's man page.
> 
> On Wed, 19 Jul 2000, K V Manjunath wrote:
> 
> > Hello,
> > 
> > I am not able to access the CVS repository of user-mode-linux. Not able to
> > figure out why, I think its the firewall. Can somebody tell me whether I
> > can get the tarball of the source of um-linux?

	Just in case you're thinking that CVS is newer than the latest
patch, I have it on _very_ good authority (Jeff's sitting next to me
at the Ottawa Linux Symposium) that CVS and the patch are identical right
now.
	The firewall probably needs outgoing access to port 2401/tcp for
you to be able to access cvs.

	Cheers,
	- Bill

---------------------------------------------------------------------------
	"Which is worse: ignorance or apathy?  Who knows?  Who cares?" 
--------------------------------------------------------------------------
William Stearns (wst...@po...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

Re: [User-mode-linux-devel] Source tarball

[Chris L. <sa...@sk...>]

Download a tarball of the 2.4test4 source from kernel.org... then download
the patch that goes against it... apply the patch and you have the
source!  :)

If you need more info, try looking at patch's man page.

-Chris


On Wed, 19 Jul 2000, K V Manjunath wrote:

> Hello,
> 
> I am not able to access the CVS repository of user-mode-linux. Not able to
> figure out why, I think its the firewall. Can somebody tell me whether I
> can get the tarball of the source of um-linux?
> 
> Regards,
> Manjunath
> 
> 
> 
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
> 

[User-mode-linux-devel] Source tarball

[K V M. <kv...@cs...>]

Hello,

I am not able to access the CVS repository of user-mode-linux. Not able to
figure out why, I think its the firewall. Can somebody tell me whether I
can get the tarball of the source of um-linux?

Regards,
Manjunath

[User-mode-linux-devel] test4 checkins

[Jeff D. <jd...@ka...>]

The test4 changes are checked in.  This was a small patch, nothing new as far 
as uml is concerned.

				Jeff

[User-mode-linux-devel] test3 checkins

[Jeff D. <jd...@ka...>]

The test3 changes are checked in to CVS.  Nothing major changed.  There were 
little things like locking changes, a devfs interface change, and a field 
change in the task structure.

I also removed the uaccess macro debugging message from segv.  It seemed to 
bother people, plus I'm convinced that those macros are pretty much working.

				Jeff

[User-mode-linux-devel] Test version of Toms Root/Boot 1.7.205 root filesystem running under User-Mode-Linux 2.4.0-test2

[William S. <wst...@po...>]

Good day, all,
	Quick summary - Thanks to the magnificent efforts of Tom Oehser
and Jeff Dike, I've got a functioning root filesystem built from Toms
Root/Boot that runs under User-Mode-Linux.
	For those unfamiliar with Toms Root/boot:  Toms Root/Boot is a
single floppy Linux environment that's usable as a rescue disk or Linux
text console.  It packs a lot of tools into a 1.7M floppy.  More info at
http://www.toms.net/rb/
	For those unfamiliar with User-Mode-Linux:  UML is a linux kernel
that has been compiled to run as a standard Linux executable.  It is
started from the command line just like any other binary.  It boots up,
loads its root filesystem from a file called root_fs, and allows you to
log in just like any other linux system.  More info at
http://user-mode-linux.sourcefore.net

	My small contribution has been preparing the content in Toms
Root/Boot to be usable as a root filesystem for UML.  It seems to boot up
just fine.  It's not a finished product, but it's certainly usable and I'd
love to get feedback.  
        The attached tar holds the build script and files that need to be
changed from the original distribution.  To save you time, here's what you
need to do as root (once the root_fs is built, you can start up the
toms+uml combination as any normal user):

(make sure your system is currently running kernel 2.2.15 or higher or a
relatively recent 2.3.x/2.4.x kernel)
mkdir --parents /mnt/spare/mirrors/
cd /mnt/spare/mirrors/
(save toms-uml.20000709.tar.gz to there.)
tar -xzvf toms-uml.20000709.tar.gz
cd toms-uml
(download linux-2.4.0-test2.bz2  from
http://sourceforge.net/project/filelist.php?group_id=429 ; uncompress it
and name it "linux")
./mk_toms_root 1.7.205

        It'll go out and get the tomsrtbt sources if you have wget on your
system.
	I believe Jeff is planning to make this available as one of the
root filesystems on the UML download page at
http://sourceforge.net/project/filelist.php?group_id=429
Updates to this package should be posted there at some point in the near
future.
	Many thanks to Jeff and Tom and all the other contributors to
these projects.
	Cheers,
	- Bill

Per Tom's request:
*******************************************************************************
* If you base something on it, use any of the scripts, distribute binaries or *
* libraries from it, or distribute customized versions of it: You must credit *
* tomsrtbt and include a pointer to http://www.toms.net/rb/ and to...@to..., *
* and include this notice verbatim. Copyright Tom Oehser 1999. This notice in *
* no way supercedes or nullifies any other protections on the component parts *
* such as the BSD and GPL copyrights which apply to practically everything!!! *
* Within these strictures you may redistribute, incorporate, copy, modify, or *
* do anything else to it or with it that you like. Tomsrtbt has no warranties *
* not even implied fitness or usefulness.  If it breaks you keep both pieces. *
*******************************************************************************

---------------------------------------------------------------------------
ACHTUNG!
Das machine is nicht fur gefingerpoken und mittengrabben.  Ist
easyschnappen der springenwerk, blowenfusen und corkenpoppen
mitspitzensparken.  Ist nicht fur gewerken by das dummkopfen. 
Dasrubbernecken sightseeren keepen hands in das pockets. 
Relaxen undvatch das blinkenlights!!!
--------------------------------------------------------------------------
William Stearns (wst...@po...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at:                http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------

Re: [User-mode-linux-devel] Performance enhancement idea / security issue...

[Jeff D. <jd...@ka...>]

sa...@sk... said:
> I was talking about replacing int 80's as they are found, with ud2
> (ud2 is a 2 byte opcode that generates an illegal instruction
> exception [SIGILL]).  That way any int 80s would still be trapped.

OK, that's not too different from my idea of having the system call path in 
the host generate a SIGSYSCALL.

The main difference being that ud2 could be implemented today.  Did you say 
that you might be interested in implementing it?  If so, go right ahead...

You'll have to add a SIGILL handler, have it run on the kernel stack (see 
trampoline in arch/um/kernel/process.c), and have it do essentially what 
syscall_handler does.

				Jeff

Re: [User-mode-linux-devel] Performance enhancement idea / security issue...

[Chris L. <sa...@sk...>]

Oh, I see... No, I wasn't talking about doing it as preprocessing step,
nor eliminating the tracing thread.  I was talking about replacing int
80's as they are found, with ud2 (ud2 is a 2 byte opcode that generates an
illegal instruction exception [SIGILL]).  That way any int 80s would still
be trapped.

Thanks for clearing up why you change the syscall to getpid... that makes
much more sense now.  :)

-Chris


On Fri, 7 Jul 2000, Jeff Dike wrote:

> sa...@sk... said:
> > How would security be reduced by having an alternate system call entry
> > point?
> 
> It's reduced if the alternate system call entry point can be turned off by the 
> process.  One of the proposals was to replace "int 0x80" with a direct call 
> into the kernel.  If that is done by a preprocessor, and there is also no 
> system call tracing (this bit wasn't explicitly proposed by anyone), then the 
> direct call can be rewritten by the process back into a system call into the 
> host kernel.
> 
> > If so, using 'ud2' to get into the kernel would be the same as using a
> > tracing thread... tracing is disabled on entrance, because we 'know'
> > we are in safe code...
> 
> What is ud2, anyway?  Never heard of it...
> 
> And there's one thing I forgot to mention:
> 
> jd...@ka... said:
> > My long-term plan for system calls is to eliminate the tracing thread
> > altogether.  There are two aspects to this - making threads able to
> > PTRACE_CONT and PTRACE_SYSCALL themselves, and allowing threads to
> > intercept  their own system calls. 
> 
> <snip>
> 
> And that is that plan for eliminating the tracing thread isn't exactly set in 
> stone.  If anyone has better ideas, I'll happily drop my own crappy plans, and 
> go with them.
> 
> 				Jeff
> 
> 
> 
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
> 

Re: [User-mode-linux-devel] Performance enhancement idea / security issue...

[Jeff D. <jd...@ka...>]

sa...@sk... said:
> How would security be reduced by having an alternate system call entry
> point?

It's reduced if the alternate system call entry point can be turned off by the 
process.  One of the proposals was to replace "int 0x80" with a direct call 
into the kernel.  If that is done by a preprocessor, and there is also no 
system call tracing (this bit wasn't explicitly proposed by anyone), then the 
direct call can be rewritten by the process back into a system call into the 
host kernel.

> If so, using 'ud2' to get into the kernel would be the same as using a
> tracing thread... tracing is disabled on entrance, because we 'know'
> we are in safe code...

What is ud2, anyway?  Never heard of it...

And there's one thing I forgot to mention:

jd...@ka... said:
> My long-term plan for system calls is to eliminate the tracing thread
> altogether.  There are two aspects to this - making threads able to
> PTRACE_CONT and PTRACE_SYSCALL themselves, and allowing threads to
> intercept  their own system calls. 

<snip>

And that is that plan for eliminating the tracing thread isn't exactly set in 
stone.  If anyone has better ideas, I'll happily drop my own crappy plans, and 
go with them.

				Jeff

Re: [User-mode-linux-devel] Performance enhancement idea / security issue...

[Chris L. <sa...@sk...>]

How would security be reduced by having an alternate system call entry
point?  Isn't the kernel is the one auditing the arguments passed into the
kernel?  If so, using 'ud2' to get into the kernel would be the same as
using a tracing thread... tracing is disabled on entrance, because we
'know' we are in safe code...

-Chris


On Fri, 7 Jul 2000, Jeff Dike wrote:

> sa...@sk... said:
> > 1. Instead of changing EAX to make the syscall do a getpid, why not
> > just add 2 to the EIP to skip over the int 80? 
> 
> Because the EIP += 2 has already happened.  I think the processor bumps the ip 
> to the next instruction before the current one starts executing.  When a 
> process is in a system call, its eip is already bumped to the following 
> instruction.
> 
> To see what's going on here, look at arch/i386/entry.S at the trace_sys label:
> 
> tracesys:
> 	movl $-ENOSYS,EAX(%esp)
> 	call SYMBOL_NAME(syscall_trace) *****
> 	movl ORIG_EAX(%esp),%eax
> 	cmpl $(NR_syscalls),%eax
> 	jae tracesys_exit
> 	call *SYMBOL_NAME(sys_call_table)(,%eax,4)
> 	movl %eax,EAX(%esp)		# save the return value
> tracesys_exit:
> 	call SYMBOL_NAME(syscall_trace)
> 	jmp ret_from_sys_call
> badsys:
> 	movl $-ENOSYS,EAX(%esp)
> 	jmp ret_from_sys_call
> 
> When the tracing thread is reading out the system call and changing it to 
> getpid, the child is at the '*****' line above.  Notice that it's going to 
> execute a system call, unless the syscall number is changed to be illegal, and 
> that the saved eip plays no part here.
> 
> If you did fiddle the registers, they would take effect when the process 
> leaves the kernel (from ret_from_sys_call) and those registers are restored.
> 
> sa...@sk... said:
> > 2. Additionally, why not change that int 80 to be "ud2" or some other
> > opcode that will cause a SIGILL?  When receiving a sigill, just check
> > for the magic opcode and if it is set, do the syscall... this would
> > have the advantage that the ptrace/c-switch overhead would be
> > reduced... 
> 
> re...@cs... said:
> > If the idea is to increase the performance, why not no change the "int
> > $80" for a "call um_syscall". um_syscall can "communicate" when it's
> > strictly necessary.
> 
> These ideas break security if tracing is turned off as a result.  A hostile 
> process could unmodify itself (or generate the system call dynamically) and 
> get access to the host.
> 
> That's not necessarily fatal.  We could have a slow, secure jail mode and a 
> fast non-secure mode.  But I think that there are plenty of ways of speeding 
> things up and keeping it secure.  I would think about putting things like this 
> in after I was reasonably convinced that secure mode was about as fast as it 
> was going to get, and also that relaxing security would provide noticeable 
> speed gains.
> 
> If anyone is interested in starting a uml performance project, I would suggest 
> the following:
> 
> Make sure that all of the system calls that uml makes into the host can't 
> block.  This moves all idle time into the idle thread where it belongs, and 
> where it can be more easily seen.  It also gives the kernel a chance to do 
> something else.  I think this is already the case, but I haven't done the 
> audit to make sure.
> 
> Profile it and see what's taking all the time and fix it. (As an aside here, 
> if someone were to make profile and test coverage configurable like debugging 
> is now, I would put it in :-)
> 
> Make the block driver able to have multiple operations in flight at once.  
> Right now, there is a single io thread, so there can be one io in flight at a 
> time.
> 
> My long-term plan for system calls is to eliminate the tracing thread 
> altogether.  There are two aspects to this - making threads able to 
> PTRACE_CONT and PTRACE_SYSCALL themselves, and allowing threads to intercept 
> their own system calls.
> 
> Allowing threads to PTRACE_CONT and PTRACE_SYSCALL themselves would speed up 
> system calls somewhat and probably significantly speed up fault handling and 
> signal delivery.
> 
> Letting threads intercept their own system calls would involve adding a second 
> slow system call path to the host.  This would just deliver a signal 
> (SIGSYSCALL, say) to the thread, and the SIGSYSCALL handler would (in uml's 
> case) enter the kernel and do the system call.
> 
> These two would eliminate context switching back and forth between the tracing 
> thread and the others.  uml might have a chance of getting within reasonable 
> distance of native performance at that point.
> 
> If anyone wants to start looking at the mods needed in the native kernel for 
> this, we could have something to propose reasonably early in 2.5.
> 
> 				Jeff
> 
> 
> 
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
> 

Re: [User-mode-linux-devel] Performance enhancement idea...

[Jeff D. <jd...@ka...>]

sa...@sk... said:
> 1. Instead of changing EAX to make the syscall do a getpid, why not
> just add 2 to the EIP to skip over the int 80? 

Because the EIP += 2 has already happened.  I think the processor bumps the ip 
to the next instruction before the current one starts executing.  When a 
process is in a system call, its eip is already bumped to the following 
instruction.

To see what's going on here, look at arch/i386/entry.S at the trace_sys label:

tracesys:
	movl $-ENOSYS,EAX(%esp)
	call SYMBOL_NAME(syscall_trace) *****
	movl ORIG_EAX(%esp),%eax
	cmpl $(NR_syscalls),%eax
	jae tracesys_exit
	call *SYMBOL_NAME(sys_call_table)(,%eax,4)
	movl %eax,EAX(%esp)		# save the return value
tracesys_exit:
	call SYMBOL_NAME(syscall_trace)
	jmp ret_from_sys_call
badsys:
	movl $-ENOSYS,EAX(%esp)
	jmp ret_from_sys_call

When the tracing thread is reading out the system call and changing it to 
getpid, the child is at the '*****' line above.  Notice that it's going to 
execute a system call, unless the syscall number is changed to be illegal, and 
that the saved eip plays no part here.

If you did fiddle the registers, they would take effect when the process 
leaves the kernel (from ret_from_sys_call) and those registers are restored.

sa...@sk... said:
> 2. Additionally, why not change that int 80 to be "ud2" or some other
> opcode that will cause a SIGILL?  When receiving a sigill, just check
> for the magic opcode and if it is set, do the syscall... this would
> have the advantage that the ptrace/c-switch overhead would be
> reduced... 

re...@cs... said:
> If the idea is to increase the performance, why not no change the "int
> $80" for a "call um_syscall". um_syscall can "communicate" when it's
> strictly necessary.

These ideas break security if tracing is turned off as a result.  A hostile 
process could unmodify itself (or generate the system call dynamically) and 
get access to the host.

That's not necessarily fatal.  We could have a slow, secure jail mode and a 
fast non-secure mode.  But I think that there are plenty of ways of speeding 
things up and keeping it secure.  I would think about putting things like this 
in after I was reasonably convinced that secure mode was about as fast as it 
was going to get, and also that relaxing security would provide noticeable 
speed gains.

If anyone is interested in starting a uml performance project, I would suggest 
the following:

Make sure that all of the system calls that uml makes into the host can't 
block.  This moves all idle time into the idle thread where it belongs, and 
where it can be more easily seen.  It also gives the kernel a chance to do 
something else.  I think this is already the case, but I haven't done the 
audit to make sure.

Profile it and see what's taking all the time and fix it. (As an aside here, 
if someone were to make profile and test coverage configurable like debugging 
is now, I would put it in :-)

Make the block driver able to have multiple operations in flight at once.  
Right now, there is a single io thread, so there can be one io in flight at a 
time.

My long-term plan for system calls is to eliminate the tracing thread 
altogether.  There are two aspects to this - making threads able to 
PTRACE_CONT and PTRACE_SYSCALL themselves, and allowing threads to intercept 
their own system calls.

Allowing threads to PTRACE_CONT and PTRACE_SYSCALL themselves would speed up 
system calls somewhat and probably significantly speed up fault handling and 
signal delivery.

Letting threads intercept their own system calls would involve adding a second 
slow system call path to the host.  This would just deliver a signal 
(SIGSYSCALL, say) to the thread, and the SIGSYSCALL handler would (in uml's 
case) enter the kernel and do the system call.

These two would eliminate context switching back and forth between the tracing 
thread and the others.  uml might have a chance of getting within reasonable 
distance of native performance at that point.

If anyone wants to start looking at the mods needed in the native kernel for 
this, we could have something to propose reasonably early in 2.5.

				Jeff

Re: [User-mode-linux-devel] Performance enhancement idea...

[Chris L. <sa...@sk...>]

>  No, just now I'm compiling their code, just to play a little bit with it.
> I found it yesterday, and I though that maybe It was useful for the
> umlinux.

Cool... make sure to report back what you find!  :)

-Chris

> > My guess is that they take the code they are overwriting and inline it
> > into the function that they are adding... 
> > 
> > It's interesting, but would that add too much bloat to the kernel?
> 
>  Maybe it's possible to have it as a external program. Some kind of
> preprocess program that it's executed just before the code is loaded. In
> this way, near all the code can be outside the kernel.
> 
>  I'm still thinking about it.
> 
> -------------------------------------------------------------------
>  Jose Renau Ardevol        | The great things in life are what they
>             re...@ui... |  seem to be.           Oscar Wilde
> -------------------------------------------------------------------
> 

Re: [User-mode-linux-devel] Performance enhancement idea...

[Jose R. <re...@cs...>]

On Fri, 7 Jul 2000, Chris Lattner wrote:

> > http://www.cs.umd.edu/projects/dyninstAPI/
> 
> I did a quick scour across their web site (and the paradyn projects
> site) to try to find a brief overview of how it works... but couldn't find
> anything.  Do you know how they deal with this problem?

 No, just now I'm compiling their code, just to play a little bit with it.
I found it yesterday, and I though that maybe It was useful for the
umlinux.

> My guess is that they take the code they are overwriting and inline it
> into the function that they are adding... 
> 
> It's interesting, but would that add too much bloat to the kernel?

 Maybe it's possible to have it as a external program. Some kind of
preprocess program that it's executed just before the code is loaded. In
this way, near all the code can be outside the kernel.

 I'm still thinking about it.

-------------------------------------------------------------------
 Jose Renau Ardevol        | The great things in life are what they
            re...@ui... |  seem to be.           Oscar Wilde
-------------------------------------------------------------------

Re: [User-mode-linux-devel] Performance enhancement idea...

[Chris L. <sa...@sk...>]

> > :(  If there is any other useful thing to fit into two bytes... that would
> > be cool too!  
> 
>  There are some tools for instrumenting code.
> 
> http://www.cs.umd.edu/projects/dyninstAPI/
> 
>  A small modification would make possible to change "int $80" for more
> elavorate code. This has to be done when the code is loaded
> (fs/binfmt_elf.c) but I think that it's feasable.


I did a quick scour across their web site (and the paradyn projects
site) to try to find a brief overview of how it works... but couldn't find
anything.  Do you know how they deal with this problem?

My guess is that they take the code they are overwriting and inline it
into the function that they are adding... 

It's interesting, but would that add too much bloat to the kernel?

-Chris


> > On Fri, 7 Jul 2000, Jose Renau wrote:
> > 
> > > 
> > >  If the idea is to increase the performance, why not no change the "int
> > > $80" for a "call um_syscall". um_syscall can "communicate" when it's
> > > strictly necessary. For example, a getpid could be done locally.
> > > 
> > >  This optimization could do te umlinux even faster than the "default"
> > > Linux.
> > > 
> > >  Suggestions?
> > > 
> > > On Fri, 7 Jul 2000, Chris Lattner wrote:
> > > 
> > > > Currently, syscall entry requires the tracing thread to wake up, munge the
> > > > registers around, and do other stuff before the syscall'ing thread
> > > > continues in the kernel...  I have two ideas to improve syscall
> > > > performance:
> > > > 
> > > > 1. Instead of changing EAX to make the syscall do a getpid, why not just
> > > > add 2 to the EIP to skip over the int 80?
> > > > 2. Additionally, why not change that int 80 to be "ud2" or some other
> > > > opcode that will cause a SIGILL?  When receiving a sigill, just check for
> > > > the magic opcode and if it is set, do the syscall... this would have the
> > > > advantage that the ptrace/c-switch overhead would be reduced...
> > > > 
> > > > Does anyone see any problems with these suggestions?  I may be interested
> > > > in implementing them if not...
> > > > 
> > > > -Chris
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > User-mode-linux-devel mailing list
> > > > Use...@li...
> > > > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
> > > > 
> > > 
> > > -------------------------------------------------------------------
> > >  Jose Renau Ardevol        | The great things in life are what they
> > >             re...@ui... |  seem to be.           Oscar Wilde
> > > -------------------------------------------------------------------
> > > 
> > > 
> > > _______________________________________________
> > > User-mode-linux-devel mailing list
> > > Use...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
> > > 
> > 
> 
> -------------------------------------------------------------------
>  Jose Renau Ardevol        | The great things in life are what they
>             re...@ui... |  seem to be.           Oscar Wilde
> -------------------------------------------------------------------
> 

Re: [User-mode-linux-devel] Performance enhancement idea...

[Jose R. <re...@cs...>]

On Fri, 7 Jul 2000, Chris Lattner wrote:

> The only problem is that you only have two bytes of code space to work
> with (int 0x80 is encoded as 0xCD 0x80), and a call takes 5? bytes...
> 
> :(  If there is any other useful thing to fit into two bytes... that would
> be cool too!  

 There are some tools for instrumenting code.

http://www.cs.umd.edu/projects/dyninstAPI/

 A small modification would make possible to change "int $80" for more
elavorate code. This has to be done when the code is loaded
(fs/binfmt_elf.c) but I think that it's feasable.

> On Fri, 7 Jul 2000, Jose Renau wrote:
> 
> > 
> >  If the idea is to increase the performance, why not no change the "int
> > $80" for a "call um_syscall". um_syscall can "communicate" when it's
> > strictly necessary. For example, a getpid could be done locally.
> > 
> >  This optimization could do te umlinux even faster than the "default"
> > Linux.
> > 
> >  Suggestions?
> > 
> > On Fri, 7 Jul 2000, Chris Lattner wrote:
> > 
> > > Currently, syscall entry requires the tracing thread to wake up, munge the
> > > registers around, and do other stuff before the syscall'ing thread
> > > continues in the kernel...  I have two ideas to improve syscall
> > > performance:
> > > 
> > > 1. Instead of changing EAX to make the syscall do a getpid, why not just
> > > add 2 to the EIP to skip over the int 80?
> > > 2. Additionally, why not change that int 80 to be "ud2" or some other
> > > opcode that will cause a SIGILL?  When receiving a sigill, just check for
> > > the magic opcode and if it is set, do the syscall... this would have the
> > > advantage that the ptrace/c-switch overhead would be reduced...
> > > 
> > > Does anyone see any problems with these suggestions?  I may be interested
> > > in implementing them if not...
> > > 
> > > -Chris
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > User-mode-linux-devel mailing list
> > > Use...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
> > > 
> > 
> > -------------------------------------------------------------------
> >  Jose Renau Ardevol        | The great things in life are what they
> >             re...@ui... |  seem to be.           Oscar Wilde
> > -------------------------------------------------------------------
> > 
> > 
> > _______________________________________________
> > User-mode-linux-devel mailing list
> > Use...@li...
> > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
> > 
> 

-------------------------------------------------------------------
 Jose Renau Ardevol        | The great things in life are what they
            re...@ui... |  seem to be.           Oscar Wilde
-------------------------------------------------------------------

Re: [User-mode-linux-devel] Performance enhancement idea...

[Chris L. <sa...@sk...>]

The only problem is that you only have two bytes of code space to work
with (int 0x80 is encoded as 0xCD 0x80), and a call takes 5? bytes...

:(  If there is any other useful thing to fit into two bytes... that would
be cool too!  

-Chris


On Fri, 7 Jul 2000, Jose Renau wrote:

> 
>  If the idea is to increase the performance, why not no change the "int
> $80" for a "call um_syscall". um_syscall can "communicate" when it's
> strictly necessary. For example, a getpid could be done locally.
> 
>  This optimization could do te umlinux even faster than the "default"
> Linux.
> 
>  Suggestions?
> 
> On Fri, 7 Jul 2000, Chris Lattner wrote:
> 
> > Currently, syscall entry requires the tracing thread to wake up, munge the
> > registers around, and do other stuff before the syscall'ing thread
> > continues in the kernel...  I have two ideas to improve syscall
> > performance:
> > 
> > 1. Instead of changing EAX to make the syscall do a getpid, why not just
> > add 2 to the EIP to skip over the int 80?
> > 2. Additionally, why not change that int 80 to be "ud2" or some other
> > opcode that will cause a SIGILL?  When receiving a sigill, just check for
> > the magic opcode and if it is set, do the syscall... this would have the
> > advantage that the ptrace/c-switch overhead would be reduced...
> > 
> > Does anyone see any problems with these suggestions?  I may be interested
> > in implementing them if not...
> > 
> > -Chris
> > 
> > 
> > 
> > _______________________________________________
> > User-mode-linux-devel mailing list
> > Use...@li...
> > http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
> > 
> 
> -------------------------------------------------------------------
>  Jose Renau Ardevol        | The great things in life are what they
>             re...@ui... |  seem to be.           Oscar Wilde
> -------------------------------------------------------------------
> 
> 
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
> 

Re: [User-mode-linux-devel] Performance enhancement idea...

[Jose R. <re...@cs...>]

 If the idea is to increase the performance, why not no change the "int
$80" for a "call um_syscall". um_syscall can "communicate" when it's
strictly necessary. For example, a getpid could be done locally.

 This optimization could do te umlinux even faster than the "default"
Linux.

 Suggestions?

On Fri, 7 Jul 2000, Chris Lattner wrote:

> Currently, syscall entry requires the tracing thread to wake up, munge the
> registers around, and do other stuff before the syscall'ing thread
> continues in the kernel...  I have two ideas to improve syscall
> performance:
> 
> 1. Instead of changing EAX to make the syscall do a getpid, why not just
> add 2 to the EIP to skip over the int 80?
> 2. Additionally, why not change that int 80 to be "ud2" or some other
> opcode that will cause a SIGILL?  When receiving a sigill, just check for
> the magic opcode and if it is set, do the syscall... this would have the
> advantage that the ptrace/c-switch overhead would be reduced...
> 
> Does anyone see any problems with these suggestions?  I may be interested
> in implementing them if not...
> 
> -Chris
> 
> 
> 
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
> 

-------------------------------------------------------------------
 Jose Renau Ardevol        | The great things in life are what they
            re...@ui... |  seem to be.           Oscar Wilde
-------------------------------------------------------------------

[User-mode-linux-devel] Performance enhancement idea...

[Chris L. <sa...@sk...>]

Hello all...

Currently, syscall entry requires the tracing thread to wake up, munge the
registers around, and do other stuff before the syscall'ing thread
continues in the kernel...  I have two ideas to improve syscall
performance:

1. Instead of changing EAX to make the syscall do a getpid, why not just
add 2 to the EIP to skip over the int 80?
2. Additionally, why not change that int 80 to be "ud2" or some other
opcode that will cause a SIGILL?  When receiving a sigill, just check for
the magic opcode and if it is set, do the syscall... this would have the
advantage that the ptrace/c-switch overhead would be reduced...

Does anyone see any problems with these suggestions?  I may be interested
in implementing them if not...

-Chris