user-mode-linux-devel

Re: [User-mode-linux-devel] Re: Help Wanted?

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

mj...@un... said:
> But that shouldn't take too long, probably over the weekend I'll whip
> up a little page for it off my homepage and make it available there.

OK.  Let me know when it's available.

				Jeff

Re: [User-mode-linux-devel] Help Wanted?

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

em...@mi... said:
> Great, I'll get started on the SMP stuff, then.

Cool.  Make sure you ask questions if there's something you don't understand 
:-)

> I realized that I
> have an easier option on the porting side, too.  I have regular access
> to Solaris machines (SPARC), so I might be able to give porting a try
> there. Hopefully it won't be too difficult

If you decide to give this a try, you might consider doing a Linux/sparc port 
first.  I think that a Solaris port will involve doing that anyway, so that 
would be a good way of splitting the project into two smaller ones, each of 
which is useful in its own right.

				Jeff

Re: [User-mode-linux-devel] Help Wanted?

[Emil O. <em...@mi...>]

Great, I'll get started on the SMP stuff, then.  I realized that I have an
easier option on the porting side, too.  I have regular access to Solaris
machines (SPARC), so I might be able to give porting a try there.
Hopefully it won't be too difficult (certainly not more than windows :)

Emil

On Tue, 17 Oct 2000, Jeff Dike wrote:

> em...@mi... said:
> > I'm interested in helping out with UML if it's needed or wanted.
> 
> Sure.  The more the merrier.
> 
> > What exactly is the status of SMP in UML now?
> 
> It's the victim of bitrot.  It's been allowed to atrophy.
> 
> > If SMP isn't in UML now, how should SMP be defined for it?
> 
> The only thing needed to support SMP is to make sure that the arch code is 
> SMP-safe.  All of the other support is there.  I've put some #errors in where 
> I know something is not SMP-safe.  It will fail to compile if you turn on SMP 
> and try to build it.
> 
> So, those need fixing, and a scan through the rest of the arch code would need 
> to be done and locking added as needed.
> 
> If you don't know what SMP-safety is, let me know, and I'll see how well I can 
> explain it.
> 
> > Finally, I use to be fluent in broken French, so maybe I could work on
> > translating the web site. 
> 
> That would be cool...
> 
> There are some other projects which would be interesting.  Near the top of the 
> list is a 'hostfs' filesystem which provides access to the host filesystem.  
> This would be a virtual filesystem which plugs into the VFS layer and converts 
> vfs calls into their libc equivalents.
> 
> If you want more choices, let me know.  I can probably think of some...
> 
> 				Jeff
> 
> 

Re: [User-mode-linux-devel] Re: Help Wanted?

[Michael V. <mj...@un...>]

On Tue, 17 Oct 2000, Jeff Dike wrote:
>
> Yes, there is interest :-)

Cool.

> If you can make it available, I'd like to either link to it from my site or 
> host it.  Whatever you prefer.

I took a quick look at it this afternoon and discovered that it will need
a little cleaning up -- I must have been in the middle of reorganizing
stuff when I stopped working it because it doesn't even compile right now
:)  

But that shouldn't take too long, probably over the weekend I'll whip up a
little page for it off my homepage and make it available there.

I'll send you the link when it's up.

         Mike

Re: [User-mode-linux-devel] Misc problems with slip-based networking

[David W. <dw...@in...>]

On Tue, 17 Oct 2000, Yann Dirson wrote:

> Sure, it sounds quite cool.  But you say "old Ethertap device" - does this
> mean it is planned to have it superceeded by the new tun/tap in official
> kernel sources ?

> Is there any backport of the "old ethertap" to 2.2 ?  Any plans on one if
> not ?

By 'old Ethertap' I mean the one that's present in 2.2 and 2.4 as
drivers/net/ethertap.c.

The new tap device is in 2.4, and is drivers/net/tun.c

-- 
dwmw2

Re: [User-mode-linux-devel] Misc problems with slip-based networking

[Yann D. <yd...@al...>]

On Tue, Oct 17, 2000 at 09:53:42AM +0100, David Woodhouse wrote:
> > [universal tun/tap]
> > Did someone had a look at this ?
> 
> Yep. Unfortunately, you still need a suid helper - and it would be best if 
> we could remove the need for suid at all. 
> 
> Rather than root allocating and ifconfig'ing a tunnel device and the UML
> later opening /dev/tun$n as an unprivileged user, you have to open the
> device, and _then_ ifconfig it. 
> 
> The old Ethertap device, with my patches to fix the permissions handling on 
> the netlink chardevice, has just the semantics that (I think) we want.

Sure, it sounds quite cool.  But you say "old Ethertap device" - does this
mean it is planned to have it superceeded by the new tun/tap in official
kernel sources ?

Is there any backport of the "old ethertap" to 2.2 ?  Any plans on one if
not ?

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
debian-email:   <di...@de...> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/             | Check <http://www.debian.org/>

Re: [User-mode-linux-devel] Re: Help Wanted?

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

mj...@un... said:
> To prevent the int $80s from killing the process, I had to create a
> "monitor" process that basically acted as a debugger.  Whenever the
> Linux binary executed a int $80, the monitor would gain control and
> redirect execution to the appropriate syscall.

That's exactly how UML operates, so what you've done is essentially the core 
of a UML Windows port.

> I still have my source kicking around somewhere, I could make it
> available if there is interest.  It's pretty rough around the edges
> though. 

Yes, there is interest :-)

If you can make it available, I'd like to either link to it from my site or 
host it.  Whatever you prefer.

I'd like people who might be interested in doing a Windows port that some of 
the work has already been done and is available.

				Jeff

[User-mode-linux-devel] Re: Help Wanted?

[Michael V. <mj...@un...>]

Over the summer when I had much more time on my hands I started toying
around with running Linux binaries on Windows (like lxrun).  Since every
so often there seems to be somebody asking about running UML on Windows, I
though I'd share some of what I learned.

I started entirely much from scratch and wrote an elfloader to load a
Linux binary into a Windows process and start executing it.  To prevent
the int $80s from killing the process, I had to create a "monitor" process
that basically acted as a debugger.  Whenever the Linux binary executed a
int $80, the monitor would gain control and redirect execution to the
appropriate syscall.  I was able to get simple utilities like "cat" and
"echo" working, as well as a stripped down version of bash that could even
fork() sometimes!

Cedric Adjih writes:
> I don`t know if Win98 would be useable, I got crashes when using 
> "int $80" with a genuine Win98 (and more normal blue screen reporting
> illegal operation when in vmware). I think these are some
> problems with Windows port:

The workaround (ie. nasty kludge) I came up for Win9x was to
search the .code segments and rewrite any "int $80" I found to a "int $03"
(debugger breakpoint).  Note that I used use long encoding of 0x03CD
instead of the single byte 0xCC encoding.  One annoying thing about that
is that int $03 is a trap and int $80 is a fault (or maybe the other way
around), so you have to increment PC after int $03 but not int $80 --
which means you need a check for Win9x vs. WinNT

> - For 98, the equivalent of an mmap function is necessary. Is it
>  possible? (Cygnus mmap is limited because of limitations of W98/W95).

yes, the lack of VirtualAllocEx() on Win95/98 is really annoying!

> Design might be different, for instance if it is easy on NT to
> change the memory mapping of one process: then one could use only
> two processes: the tracer process and a "traced" process.
> "Signal"-based scheduling might also be changed.

There is also the issue of whether the syscalls execute as the tracer
process or as the traced process.  There are avantages and disavantages to
both.

I still have my source kicking around somewhere, I could make it available
if there is interest.  It's pretty rough around the edges though.


	Michael

Re: [User-mode-linux-devel] Re: Help Wanted?

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

ced...@in... said:
> - On NT (W98?), the lower 64K of a process (0x00000000-0x00010000)
> aren't useable. This is an issue if a Linux process or the kernel
> expect to mmap something there.

I've never seen anything mmap anything there.  Besides, UML is occupying other 
large areas of the process address space, and that hasn't caused any probems 
either.

> the design might be different, while UML currently doesn't use too
> abstract operations (less than A386). It makes difficult to change the
> design, and to port to Windows. Design might be different, for
> instance if it is easy on NT to change the memory mapping of one
> process: then one could use only two processes: the tracer process and
> a "traced" process. "Signal"-based scheduling might also be changed.

What I'm going to do when I get another OS port is split things into userspace 
stuff and kernel stuff.  The userspace stuff is what potentially needs 
reimplementing when porting to a new OS.

> there is also an issue for compiling the Linux kernel on Windows: can
> it work ? 

By using the cygwin gcc, you ought to get the same assembly for the kernel as 
on Linux.

				Jeff

Re: [User-mode-linux-devel] Help Wanted?

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

If it helps, I have already written a "hostfs" filesystem that should work
with UML with very little modification... the only catch is that I'm
waiting on my employer to allow me to release it (which they have said
they will, just paperwork stuff)...  I'll see if I can reaccellerate this
processes...

-Chris

On Tue, 17 Oct 2000, Jeff Dike wrote:

> em...@mi... said:
> > I'm interested in helping out with UML if it's needed or wanted.
> 
> Sure.  The more the merrier.
> 
> > What exactly is the status of SMP in UML now?
> 
> It's the victim of bitrot.  It's been allowed to atrophy.
> 
> > If SMP isn't in UML now, how should SMP be defined for it?
> 
> The only thing needed to support SMP is to make sure that the arch code is 
> SMP-safe.  All of the other support is there.  I've put some #errors in where 
> I know something is not SMP-safe.  It will fail to compile if you turn on SMP 
> and try to build it.
> 
> So, those need fixing, and a scan through the rest of the arch code would need 
> to be done and locking added as needed.
> 
> If you don't know what SMP-safety is, let me know, and I'll see how well I can 
> explain it.
> 
> > Finally, I use to be fluent in broken French, so maybe I could work on
> > translating the web site. 
> 
> That would be cool...
> 
> There are some other projects which would be interesting.  Near the top of the 
> list is a 'hostfs' filesystem which provides access to the host filesystem.  
> This would be a virtual filesystem which plugs into the VFS layer and converts 
> vfs calls into their libc equivalents.
> 
> If you want more choices, let me know.  I can probably think of some...
> 
> 				Jeff
> 
> 
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-devel
> 

Re: [User-mode-linux-devel] Misc problems with slip-based networking

[David W. <dw...@in...>]

yd...@al... said:
>  As an alternative, wouldn't it be possible to use the "universal tun/
> tap driver" (http://tun.sourceforge.net/tun/) ?  I had a quick attempt
> a couple of days ago, but it does not seem compatible with the
> ethertap in 2.4 kernels - it even does not use the same device number.

> Did someone had a look at this ?

Yep. Unfortunately, you still need a suid helper - and it would be best if 
we could remove the need for suid at all. 

Rather than root allocating and ifconfig'ing a tunnel device and the UML
later opening /dev/tun$n as an unprivileged user, you have to open the
device, and _then_ ifconfig it. 

The old Ethertap device, with my patches to fix the permissions handling on 
the netlink chardevice, has just the semantics that (I think) we want.

As root, ifconfig tap0 $HOSTIP pointopoint $UMLIP ; chown $UMLUSER /dev/tap0

Then the UML can just open the device node as an when required, and no suid 
helper is required.

--
dwmw2

[User-mode-linux-devel] Re: Help Wanted?

[Cedric A. <ced...@in...>]

Emil Ong writes:
 > Hi,
 > 
 > I'm interested in helping out with UML if it's needed or wanted.  I've
 > been looking at the website, the code, and mail list archives and maybe I
 > could help out with SMP or the Windows port.
 > 
 > What exactly is the status of SMP in UML now?  I noticed that there was a
 > patch from back in January, but also some recent mention that SMP is not
 > supported/enabled.  If SMP isn't in UML now, how should SMP be defined for
 > it?  Would it be some sort of pthread (or other thread library) thing
 > where UML could actually be running on several CPU's or something else?
 > Forgive me if these are stupid questions; I just started looking at this
 > stuff.
 > 
 > I doubt that I'm really in a good position to do the Windows port -- all I
 > have is Windows 98 and from what I gather (I'm not really experienced with
 > Windows programming), Windows NT is necessary to catch syscall interrupts 
 > (?). If I can do anything with Windows 98 that would help, please let me
 > know.

  I don't know if Win98 would be useable, I got crashes when using 
"int $80" with a genuine Win98 (and more normal blue screen reporting
illegal operation when in vmware). I think these are some problems with
Windows port:

- Is interruption rerouting possible without the W98 Device Driver 
Kit ? and with ?

- For 98, the equivalent of an mmap function is necessary. Is it
possible? (Cygnus mmap is limited because of limitations of W98/W95).

- On NT (W98?), the lower 64K of a process (0x00000000-0x00010000) 
aren't useable. This is an issue if a Linux process or the kernel 
expect to mmap something there. I have hacked an NT kernel module 
from some book so that one can set IA32 code segments, 
so there are work-arounds.

If the problems above are solved, then it might be possible to port
UML. Then the questions are:

- the design might be different, while UML currently doesn't use too
abstract operations (less than A386). It makes difficult to change
the design, and to port to Windows.
Design might be different, for instance if it is easy on NT to
change the memory mapping of one process: then one could use only
two processes: the tracer process and a "traced" process.
"Signal"-based scheduling might also be changed.

- there is also an issue for compiling the Linux kernel on Windows:
can it work ? The easier might well be to make a mini-A386 for Linux
based on UML functions, port the mini-A386 to Windows, and then
run the same UML-miniA386-Linux binary on both Linux and Windows.

-- Cedric

Re: [User-mode-linux-devel] segfault around execve() and others when attaching gdb

[Yann D. <yd...@al...>]

On Mon, Oct 16, 2000 at 07:11:59PM -0500, Jeff Dike wrote:
> yd...@al... said:
> > Program received signal SIGSEGV, Segmentation fault. 
> > 0x10034a70 in ?? () 
> > (gdb) symbol-file kernel-source-2.4.0-test9-um/linux 
> > Reading symbols from kernel-source-2.4.0-test9-um/linux...done. 
> > (gdb) bt #0
> > 0x10034a70 in padzero (elf_bss=1073818712)
> >     at 
> >/home/dwitch/usr/src/umlinux/kernel-source-2.4.0-test9-um/include/asm/arch/str
> ing.h:418
> > #1  0x10035349 in load_elf_interp(interp_elf_ex=0x50053d48,  
> 
> This and the others are correct.  The process is segfaulting so as to 
> demand-load itself.  To avoid seeing them, do this:
> 	handle SIGSEGV pass nostop noprint

Oops :}  Nearly forgot it was as OS running inside :)

-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
debian-email:   <di...@de...> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/             | Check <http://www.debian.org/>

Re: [User-mode-linux-devel] Help Wanted?

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

em...@mi... said:
> I'm interested in helping out with UML if it's needed or wanted.

Sure.  The more the merrier.

> What exactly is the status of SMP in UML now?

It's the victim of bitrot.  It's been allowed to atrophy.

> If SMP isn't in UML now, how should SMP be defined for it?

The only thing needed to support SMP is to make sure that the arch code is 
SMP-safe.  All of the other support is there.  I've put some #errors in where 
I know something is not SMP-safe.  It will fail to compile if you turn on SMP 
and try to build it.

So, those need fixing, and a scan through the rest of the arch code would need 
to be done and locking added as needed.

If you don't know what SMP-safety is, let me know, and I'll see how well I can 
explain it.

> Finally, I use to be fluent in broken French, so maybe I could work on
> translating the web site. 

That would be cool...

There are some other projects which would be interesting.  Near the top of the 
list is a 'hostfs' filesystem which provides access to the host filesystem.  
This would be a virtual filesystem which plugs into the VFS layer and converts 
vfs calls into their libc equivalents.

If you want more choices, let me know.  I can probably think of some...

				Jeff

[User-mode-linux-devel] Help Wanted?

[Emil O. <em...@mi...>]

Hi,

I'm interested in helping out with UML if it's needed or wanted.  I've
been looking at the website, the code, and mail list archives and maybe I
could help out with SMP or the Windows port.

What exactly is the status of SMP in UML now?  I noticed that there was a
patch from back in January, but also some recent mention that SMP is not
supported/enabled.  If SMP isn't in UML now, how should SMP be defined for
it?  Would it be some sort of pthread (or other thread library) thing
where UML could actually be running on several CPU's or something else?
Forgive me if these are stupid questions; I just started looking at this
stuff.

I doubt that I'm really in a good position to do the Windows port -- all I
have is Windows 98 and from what I gather (I'm not really experienced with
Windows programming), Windows NT is necessary to catch syscall interrupts 
(?). If I can do anything with Windows 98 that would help, please let me
know.

Finally, I use to be fluent in broken French, so maybe I could work on
translating the web site.

If this is of use to anyone, please let me know.  I would like to focus on
one of the technical projects and maybe do the translating on the side.

Thanks,
Emil

[User-mode-linux-devel] CVS checkins

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

This batch does the following:

Allocates larger kernel stacks.  There is also a guard page between the two 
pages of stack and the task structure.  Any overly long stacks will now 
segfault at the place that they grew to big.

Redid a couple of procedures to reduce their stack frame size.

The kernel debugger no longer sees SIGSEGV.

				Jeff

Re: [User-mode-linux-devel] segfault around execve() and others when attaching gdb

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

yd...@al... said:
> Program received signal SIGSEGV, Segmentation fault. 
> 0x10034a70 in ?? () 
> (gdb) symbol-file kernel-source-2.4.0-test9-um/linux 
> Reading symbols from kernel-source-2.4.0-test9-um/linux...done. 
> (gdb) bt #0
> 0x10034a70 in padzero (elf_bss=1073818712)
>     at 
>/home/dwitch/usr/src/umlinux/kernel-source-2.4.0-test9-um/include/asm/arch/str
ing.h:418
> #1  0x10035349 in load_elf_interp(interp_elf_ex=0x50053d48,  

This and the others are correct.  The process is segfaulting so as to 
demand-load itself.  To avoid seeing them, do this:
	handle SIGSEGV pass nostop noprint

As of test10, SIGSEGVs won't be routed through gdb, so that won't be necessary.

				Jeff

[User-mode-linux-devel] segfault around execve() and others when attaching gdb

[Yann D. <yd...@al...>]

Still using 2.4.0-test9 + um on a Debian "woody" host:

Linux bylbo 2.2.17 #1 Sun Sep 10 19:21:52 CEST 2000 i586 unknown

I compiled the um kernel with debugging support (.config attached) and
cannot attach to it without getting a segfault.


* debug from beggining:

Console output stops where I usually get init's startup message, which
is coherent with `um_execve ("/sbin/init")' in the traces.


$ ~/usr/src/umlinux[704]$ ./kernel-source-2.4.0-test9-um/linux debug ubd0=/home/dwitch/usr/src/umlinux/rootfs/root_fs_debian2.2_small umn=10.0.0.132 
tracing thread pid = 25507
Linux version 2.4.0-test9-1um (dwitch@bylbo) (gcc version 2.95.2 20000220 (Debian GNU/Linux)) #1 lun oct 16 22:20:01 CEST 2000
On node 0 totalpages: 4096
zone(0): 0 pages.
zone(1): 4096 pages.
zone(2): 0 pages.
Kernel command line: debug ubd0=/home/dwitch/usr/src/umlinux/rootfs/root_fs_debian2.2_small umn=10.0.0.132 root=/dev/ubd0
[...]
VFS: Mounted root (ext2 filesystem) readonly.
Mounted devfs on /dev


5400010
att 1
b start_kernel
c
GNU gdb 5.0
[Copyright...]

(gdb) att 1
Attaching to Pid 1
0x100b4d11 in ?? ()
(gdb) b start_kernel
No symbol table is loaded.  Use the "file" command.
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x10034a70 in ?? ()
(gdb) symbol-file kernel-source-2.4.0-test9-um/linux 
Reading symbols from kernel-source-2.4.0-test9-um/linux...done.
(gdb) bt
#0  0x10034a70 in padzero (elf_bss=1073818712)
    at /home/dwitch/usr/src/umlinux/kernel-source-2.4.0-test9-um/include/asm/arch/string.h:418
#1  0x10035349 in load_elf_interp (interp_elf_ex=0x50053d48, 
    interpreter=0x500e8180, interp_load_addr=0x50053d18) at binfmt_elf.c:320
#2  0x10035c2e in load_elf_binary (bprm=0x50053e1c, regs=0x0)
    at binfmt_elf.c:666
#3  0x10026262 in search_binary_handler (bprm=0x50053e1c, regs=0x0)
    at exec.c:809
#4  0x10026484 in do_execve (filename=0x100fbd2d "/sbin/init", 
    argv=0x1013a140, envp=0x1013a180, regs=0x0) at exec.c:902
#5  0x100aa48b in execve1 (file=0x100fbd2d "/sbin/init", argv=0x1013a140, 
    env=0x1013a180) at exec_kern.c:77
#6  0x100aa4cb in um_execve (file=0x100fbd2d "/sbin/init", argv=0x1013a140, 
    env=0x1013a180) at exec_kern.c:87
#7  0x100013b8 in init (unused=0x0) at init/main.c:768
#8  0x100afcf8 in new_thread_proc (t=0x50052000) at process_kern.c:128
(gdb) 


* attach to running kernel:

It takes a couple of seconds before the segfault comes, but it is
quite reproducible.

In this case, the console is still responsive - I can halt the system
with no apparent problem.

It appears the thread which gets the segfault is not the kernel itself

6c00010
GNU gdb 5.0
[...]

(gdb) att 1
Attaching to Pid 1
0x100bc111 in ?? ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x804b871 in ?? ()
(gdb) bt
#0  0x804b871 in ?? ()
#1  0x804cd86 in ?? ()
#2  0x804d0ba in ?? ()
#3  0x4002da42 in ?? ()
(gdb) symbol-file kernel-source-2.4.0-test9-um/linux
Reading symbols from kernel-source-2.4.0-test9-um/linux...done.
(gdb) bt
#0  0x804b871 in ?? ()
#1  0x804cd86 in ?? ()
#2  0x804d0ba in ?? ()
#3  0x4002da42 in ?? ()
(gdb) 


If I just have the login prompt when I attach, just hit 'c' after the
1st segfault which I cannot tell what thread/process got, then when
pressing RETURN at the login prompt (staying in getty IIRC) I get a
second segfault, in the kernel this time:

(gdb) bt
#0  0x10012154 in file_read_actor (desc=0x5019de2c, page=0x500371e0, offset=0, 
    size=25)
    at /home/dwitch/usr/src/umlinux/kernel-source-2.4.0-test9-um/include/asm/arch/string.h:202
#1  0x10011df9 in do_generic_file_read (filp=0x500e8720, ppos=0x500e8740, 
    desc=0x5019de2c, actor=0x100120f0 <file_read_actor>) at filemap.c:1009
#2  0x100121d7 in generic_file_read (filp=0x500e8720, 
    buf=0x40014000 <Address 0x40014000 out of bounds>, count=4096, 
    ppos=0x500e8740) at filemap.c:1140
#3  0x1001d0d7 in sys_read (fd=3, 
    buf=0x40014000 <Address 0x40014000 out of bounds>, count=4096)
    at read_write.c:133
#4  0x100acbc5 in execute_syscall (syscall=3, args=0x5019dee4)
    at syscall_kern.c:340
#5  0x100ad01b in syscall_handler (unused=0) at syscall_user.c:113
#6  0x100a9eb9 in fork_handler (sig=10) at process.c:96
#7  <signal handler called>
#8  0x100b4d11 in kill () at umn_kern.c:202


If then I attempt a real login, `execve("/bin/login")' fails in much
the same way as init did in the first example:

Program received signal SIGSEGV, Segmentation fault.
0x10034a70 in padzero (elf_bss=1073818712)
    at /home/dwitch/usr/src/umlinux/kernel-source-2.4.0-test9-um/include/asm/arch/string.h:418
418     __asm__ __volatile__(
(gdb) bt
#0  0x10034a70 in padzero (elf_bss=1073818712)
    at /home/dwitch/usr/src/umlinux/kernel-source-2.4.0-test9-um/include/asm/arch/string.h:418
#1  0x10035349 in load_elf_interp (interp_elf_ex=0x5019dc04, 
    interpreter=0x50d0be60, interp_load_addr=0x5019dbd4) at binfmt_elf.c:320
#2  0x10035c2e in load_elf_binary (bprm=0x5019dcd8, regs=0x0)
    at binfmt_elf.c:666
#3  0x10026262 in search_binary_handler (bprm=0x5019dcd8, regs=0x0)
    at exec.c:809
#4  0x10026484 in do_execve (filename=0x50ea9000 "/bin/login", 
    argv=0xbf7fed54, envp=0xbf7ffe94, regs=0x0) at exec.c:902
#5  0x100aa48b in execve1 (file=0x50ea9000 "/bin/login", argv=0xbf7fed54, 
    env=0xbf7ffe94) at exec_kern.c:77
#6  0x100aa519 in sys_execve (
    file=0x804a911 <Address 0x804a911 out of bounds>, argv=0xbf7fed54, 
    env=0xbf7ffe94) at exec_kern.c:101
#7  0x100acbc5 in execute_syscall (syscall=11, args=0x5019dee4)
    at syscall_kern.c:340
#8  0x100ad01b in syscall_handler (unused=0) at syscall_user.c:113
#9  0x100a9eb9 in fork_handler (sig=10) at process.c:96
#10 <signal handler called>
#11 0x100b4d11 in kill () at umn_kern.c:202
(gdb) 


-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
debian-email:   <di...@de...> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/             | Check <http://www.debian.org/>

Re: [User-mode-linux-devel] Misc problems with slip-based networking

[Yann D. <yd...@al...>]

On Mon, Oct 16, 2000 at 05:08:15PM -0500, Jeff Dike wrote:
> That's because you're running a fairly recent 2.2 kernel.  Sometime between 
> 2.2.5 (which is what I'm running) and whatever you're running, someone 
> tightened up the security on slip so that you need CAP_NET_ADMIN (or root) in
> order to set slip encapsulation on a tty.  On my box, root is only needed for
> configuring the slip device.  A better suid helper is on my list of things to
> do.

As an alternative, wouldn't it be possible to use the "universal tun/tap
driver" (http://tun.sourceforge.net/tun/) ?  I had a quick attempt a couple
of days ago, but it does not seem compatible with the ethertap in 2.4
kernels - it even does not use the same device number.

Did someone had a look at this ?
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
debian-email:   <di...@de...> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/             | Check <http://www.debian.org/>

Re: [User-mode-linux-devel] Misc problems with slip-based networking

[Yann D. <yd...@al...>]

On Mon, Oct 16, 2000 at 05:08:15PM -0500, Jeff Dike wrote:
> yd...@al... said:
> > usermode:~# ifconfig umn 10.0.0.135 hw ether a:0:0:85:0:0 Failed to
> > set slip line discipline - errno = 1 Failed to set O_ASYNC and
> > O_NONBLOCK on fd # -1, errno = 9 
> 
> That's because you're running a fairly recent 2.2 kernel.  Sometime between 
> 2.2.5 (which is what I'm running) and whatever you're running

Right, it's a 2.2.17 - should have mentionned that earlier.  This sounds
like a reasonable thing to mention in the networking page :)

Thanks for the quick answer,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
debian-email:   <di...@de...> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/             | Check <http://www.debian.org/>

Re: [User-mode-linux-devel] Misc problems with slip-based networking

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

yd...@al... said:
> usermode:~# ifconfig umn 10.0.0.135 hw ether a:0:0:85:0:0 Failed to
> set slip line discipline - errno = 1 Failed to set O_ASYNC and
> O_NONBLOCK on fd # -1, errno = 9 

That's because you're running a fairly recent 2.2 kernel.  Sometime between 
2.2.5 (which is what I'm running) and whatever you're running, someone 
tightened up the security on slip so that you need CAP_NET_ADMIN (or root) in 
order to set slip encapsulation on a tty.  On my box, root is only needed for 
configuring the slip device.  A better suid helper is on my list of things to 
do.

				Jeff

[User-mode-linux-devel] Misc problems with slip-based networking

[Yann D. <yd...@al...>]

Hi,

I'm running Debian "unstable" (aka "woody"), and the new ifconfig we
get (from net-tools 1.57) dose not understand the "-n" option.
Although the old ifconfig shipped with Debian 2.2 does understand it,
I do not find this option documented in the manpage or in --help
output.

Now I take an old ifconfig as um_ifconfig and get:

~/usr/src/umlinux[697]$ ./kernel-source-2.4.0-test9-um/linux ubd0=/home/dwitch/usr/src/umlinux/rootfs/root_fs_debian2.2_small umn=10.0.0.132
[...]
usermode:~# ifconfig umn 10.0.0.135 hw ether a:0:0:85:0:0
Failed to set slip line discipline - errno = 1
Failed to set O_ASYNC and O_NONBLOCK on fd # -1, errno = 9
umn_init : request_irq failed - errno = -1
SIOCSIFFLAGS: Operation not permitted
SIOCSIFADDR: Permission denied
sl-1: unknown interface: No such device
SIOCSIFDSTADDR: Permission denied
sl-1: unknown interface: No such device
sl-1: unknown interface: No such device
um_ifconfig failed
SIOCSIFHWADDR: Operation not permitted


Note I slightly edited um_ifconfig output, which looked like CR's were
just replaced with LF's.


It looks like set_umn_addr() gets passed -1 as device number.
Some sanity check appears to be missing...

Will recompile and try to run gdb on this.

Regards,
-- 
Yann Dirson    <yd...@al...> |    Why make M$-Bill richer & richer ?
debian-email:   <di...@de...> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/             | Check <http://www.debian.org/>

Re: [User-mode-linux-devel] Networking via slirp

[Mikko J R. <mjr...@cc...>]

On Thu, 12 Oct 2000, Jeff Dike wrote:
> mjr...@cc... said:
> > I was wondering if anyone has considered adding slirp networking
> > support to UML?
> 
> It has come up several times in the last few weeks.  I just haven't had time 
> to look into it.

Sorry for repeating old stuff, then. I did run a search on the archive though.

> The driver just wants a file descriptor that it can read and write packets to. 
>  It doesn't care how that descriptor is set up.

Figured as much.

> That is purely user-level code.

Hence the "low-level" in "kernel/low-level" :)

Oh well, as said, might at least look into it sometime.

-- 
Mikko Rauhala - mj...@ik... - http://www.iki.fi/mjr/

Re: [User-mode-linux-devel] Networking via slirp

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

mjr...@cc... said:
> I was wondering if anyone has considered adding slirp networking
> support to UML?

It has come up several times in the last few weeks.  I just haven't had time 
to look into it.

> I guess, from glancing at the source, that it'd mostly be a case of
> modifying arch/um/drivers/umn_user.c so that instead of calling
> ifconfig slirp would be started and its stdin/out used instead of the
> tty allocated for the slip line? Any obvious flaws in this?

The driver just wants a file descriptor that it can read and write packets to. 
 It doesn't care how that descriptor is set up.

> if I get to scratching my own itch but am not really sure how to best
> go about doing it? (Read: not much kernel/low-level programming
> experience.)

That is purely user-level code.  If you can write a little proggie to set up 
slirp and communicate via it, you can probably just drop that code into the 
driver.

				Jeff

[User-mode-linux-devel] Networking via slirp

[Mikko J R. <mjr...@cc...>]

Greetings

I was wondering if anyone has considered adding slirp networking support
to UML? For those who haven't heard of it, slirp is a SLIP/PPP emulator
that works completely in user-space, providing IP-Masqueradish
functionality to a single SLIP/PPP peer. It would sort of complement the
user-space kernel by providing (limited, but for many purposes functional
enough) user-space networking, the obvious bonus being the ability to run
a networked UML completely without root priviledges.

I guess, from glancing at the source, that it'd mostly be a case of
modifying arch/um/drivers/umn_user.c so that instead of calling ifconfig
slirp would be started and its stdin/out used instead of the tty allocated
for the slip line? Any obvious flaws in this?

I'd of course be interested in knowing if anyone has already done or is
doing something to this effect? Who would I bug (Ger Off?) if I get to
scratching my own itch but am not really sure how to best go about doing
it? (Read: not much kernel/low-level programming experience.)

-- 
Mikko Rauhala - mj...@ik... - http://www.iki.fi/mjr/