user-mode-linux-devel

[User-mode-linux-devel] 2.3.99-pre3 is checked in

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

It's been updated to 2.3.99-pre3.

I changed the network driver to try running ifconfig if um_ifconfig failed and 
the kernel is being running as root.  I also broke apart a trio of ioctls so 
that each produces a different error message on failure.  It turns out that 
various distros have different permissions on pts devices, and some (like 
Debian) don't allow normal users to allocate them.  This change allows that to 
be debugged more easily.

I fixed the Mandrake crash by turning on read permissions to an mmapped 
segment that's going to be written.

I fixed a hang that was caused by a signal handler failing to execute because 
its stack had been swapped out.  The kernel-mode syscall handler now forces 
the stack back in by referencing it, causing it to be faulting back in if 
necessary.  This is the bug that was causing kernel builds to fail more often 
than not.  For some reason, this showed up best while doing makes.

Eliminated the bogus include of tasks.h from irq.c.

				Jeff

[User-mode-linux-devel] Re: VM modules in kernel? (fwd)

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

	From the Linux-kernel mailing list...
	Cheers,
	- Bill

---------------------------------------------------------------------------
We're upping our productivity with Linux - so up yours!
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------


---------- Forwarded message ----------
Date: Fri, 24 Mar 2000 17:40:48 +0000 (GMT)
From: Alan Cox <al...@lx...>
To: mh...@me...
Cc: Linux Kernel mailing list <lin...@vg...>
Subject: Re: VM modules in kernel?

> I was thinking that faster VM speeds may be possible if the
> kernel can be tweaked more freely due to the GPL nature of the
> Plex86/bochs projects now.

Remember something here. IBM tuned the hardware to this, and to an extent
they tuned the software on top of VM. They have a lot of cards to play that
Motorola m68K chips did but x86 does not.

Im hoping transmeta can manage to add a virtualised 386 mode to their chip.
Here's hoping they are listening ;)

In the Linux case we have another weapon (other than fear suprise and the
cuddly penguin) which is that we don't give two hoots[1] if the kernel running
on the hypervisor is not a normal x86 kernel. If it provides the APIs and
it runs x86 user space its fine.

Consider the user mode kernel as a more interesting starting point.

Alan
[1] Arguably we don't give one hoot or even a ho[2] either
[2] half a hoot


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj...@vg...
Please read the FAQ at http://www.tux.org/lkml/

[User-mode-linux-devel] Re: UM linux segfault in memcpy(): solved.

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

> What still seems strange to me, why read access from gdb enable read
> access for the page instead of protection fault.

> So I suggest you to add PROT_READ flags for such non trivial memcpy()
> implementation and forget about the problem. 

Thanks for tracking that down.

The PROT_READ is now in there.

Does the kernel now run for you?

				Jeff

[User-mode-linux-devel] UM linux segfault in memcpy(): solved.

[Yuri P. <yu...@sw...>]

It looks like I found the cause and the solution,
however the way how read access from gdb interferes
with the child read access continue to seems strange to me.

I wrote a small mmap-test prog which just does create_file_vm(),
mmap(), and memcpy(). Segfault occurs when two conditions are in play:

 - mmap use PROT_WRITE protection (no PROT_READ);
 - particular memcpy() implementation, which does READ access to destination
area.

Unfortunatly this is the implementation from my libc.a, comes in play
when statically linked.

Summary: PROT_WRITE works fine with:

 - gcc 2.95.2 __builtin_memcpy();
 - glibc 2.1.3 memcpy(), comes from sysdeps/generic/memcpy.c;
 - Redhat 6.1 supplied glibc-2.1.2-11

PROT_WRITE known not to work with:
 - some ugly memcpy from Mandrake 7.0, comes from glibc-2.1.2-9mdk.

This implementation touches cache lines before write to the destination
for a possible speedup. Adding PROT_READ permission surely fixes the problem
for this case.

What still seems strange to me, why read access from gdb enable read access
for the page instead of protection fault.

So I suggest you to add PROT_READ flags for such non trivial memcpy()
implementation
and forget about the problem.


FYI attached is the dissassembly dump of the affected memcpy().

memcpy.o:     file format elf32-i386

Disassembly of section .text:

00000000 <memcpy>:
   0: 57                    push   %edi
   1: 56                    push   %esi
   2: 8b 7c 24 0c           mov    0xc(%esp,1),%edi
   6: 8b 74 24 10           mov    0x10(%esp,1),%esi
   a: 8b 4c 24 14           mov    0x14(%esp,1),%ecx
   e: 89 f8                 mov    %edi,%eax
  10: fc                    cld
  11: 83 f9 20              cmp    $0x20,%ecx
  14: 76 56                 jbe    6c <memcpy+0x6c>
  16: f7 d8                 neg    %eax
  18: 83 e0 03              and    $0x3,%eax
  1b: 29 c1                 sub    %eax,%ecx
  1d: 91                    xchg   %eax,%ecx
  1e: f3 a4                 repz movsb %ds:(%esi),%es:(%edi)
  20: 89 c1                 mov    %eax,%ecx
  22: 83 e9 20              sub    $0x20,%ecx
  25: 78 3e                 js     65 <memcpy+0x65>
  27: 8b 07                 mov    (%edi),%eax

^^^^ here it segfaults on a READ access to the destination.

  29: 8b 57 1c              mov    0x1c(%edi),%edx

^^^^ here is another read access to the second case line

  2c: 83 e9 20              sub    $0x20,%ecx
  2f: 8b 06                 mov    (%esi),%eax
  31: 8b 56 04              mov    0x4(%esi),%edx
  34: 89 07                 mov    %eax,(%edi)
  36: 89 57 04              mov    %edx,0x4(%edi)
  39: 8b 46 08              mov    0x8(%esi),%eax
  3c: 8b 56 0c              mov    0xc(%esi),%edx
  3f: 89 47 08              mov    %eax,0x8(%edi)
  42: 89 57 0c              mov    %edx,0xc(%edi)
  45: 8b 46 10              mov    0x10(%esi),%eax
  48: 8b 56 14              mov    0x14(%esi),%edx
  4b: 89 47 10              mov    %eax,0x10(%edi)
  4e: 89 57 14              mov    %edx,0x14(%edi)
  51: 8b 46 18              mov    0x18(%esi),%eax
  54: 8b 56 1c              mov    0x1c(%esi),%edx
  57: 89 47 18              mov    %eax,0x18(%edi)
  5a: 89 57 1c              mov    %edx,0x1c(%edi)
  5d: 8d 76 20              lea    0x20(%esi),%esi
  60: 8d 7f 20              lea    0x20(%edi),%edi
  63: 79 c4                 jns    29 <memcpy+0x29>
  65: 83 c1 20              add    $0x20,%ecx
  68: 8b 44 24 0c           mov    0xc(%esp,1),%eax
  6c: f3 a4                 repz movsb %ds:(%esi),%es:(%edi)
  6e: 5e                    pop    %esi
  6f: 5f                    pop    %edi
  70: c3                    ret

[User-mode-linux-devel] More info on misterious coredump

[Yuri P. <yu...@sw...>]

I figured out how to locate the exact place of coredump.

Then I run newly compiled uml-linux-2.3.99-pre2,  it dumps core
in memcpy at user_utils.c:156, after the first crearte_vm_file() call.

The mistery is that both src and dst addresses for memcpy,
as well as size seems to be reasonably correct.
mmap() to dst is also successed.
However memcpy call did not return, resulted in segfault.

Here is a gdb session:

Breakpoint 6, remap_data (perms=0x1015ef53 "rw-") at user_util.c:156
156           memcpy(addr, (void *) start, size);
1: x/i $eip  0x10084fa1 <remap_data+165>:       mov    0xfffffff4(%ebp),%eax
(gdb) list
151           data = create_vm_file(size);
152           if((addr = mmap(NULL, size, PROT_WRITE, MAP_SHARED, data, 0)) < 0){
153             perror("mapping new data segment");
154             exit(1);
155           }
156           memcpy(addr, (void *) start, size);
157           if(munmap((void *) start, size) < 0){
158             perror("unmapping old data segment");
159             exit(1);
160           }
(gdb) p data
$24 = 10
(gdb) p/x addr
$25 = 0x40000000
(gdb) p/x size
$26 = 0x97000
(gdb) p/x start
$27 = 0x100d0000
(gdb) p/x 618496
$28 = 0x97000
(gdb) p ((char*)addr)[0]
$29 = 0 '\000'
(gdb) p ((char*)addr)[size-1]
$30 = 0 '\000'
(gdb) p ((char*)start)[size-1]
$31 = 0 '\000'
(gdb) p ((char*)start)[0]
$32 = 0 '\000'
(gdb) p $esp
$33 = (void *) 0xbffff754
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x1008ebf9 in memcpy ()
1: x/i $eip  0x1008ebf9 <memcpy+41>:    mov    0x1c(%edi),%edx
(gdb) p/x $edi
$35 = 0x40001000

And the most interesting observation:
the exact address at which program segfaulted depends on
my print manipulations from gdb.
I.e. if I do print ((char*)addr[0], it segfaulted at addr+0x1000,
if I do touch also addr[0x1000], it segfaulted at addr+0x2000.
In case I did not print at all, I got segfault @ 0x400000000.

Got the point?

FYI: I use 2.2.15-pre15 as a host kernel (with ptrace() syscall-overwrite patch).

Will continue my efforts tomorrow, please help me with advise
if you have some explanations.

Re: [User-mode-linux-devel] Cannot compile uml-2.3.99-pre2 from sources

[Yuri P. <yu...@sw...>]

I just re-read you reply and finally found the root of my compiling problems:
after unpacking and patching sources, I leaved /usr/src/linux symlink pointed
to uml-linux source tree. This setup badly brokes your game with include paths,
resulting in my problems described.

So now I can cleanly compile uml-linux from clean 2.3.99-pre2 and your patch,
with only one correction:
 - removed #include "linux/tasks.h" from irq.c

But running linux executable still gives me core dump in the same place,
still do not know why.

And as I alraedy mentioned, CVS tree has outdated stdio_console_user.c file.


Best regards,
Yuri Pudgorodsky

Re: [User-mode-linux-devel] Cannot compile uml-2.3.99-pre2 from sources

[Yuri P. <yu...@sw...>]

Jeff Dike wrote:

> > In the CVS:
> >     - open_vt() from stdio_console_user.c conflicts with its prototype
> > and calling place.
>
> I just checked this out and I don't see a problem:
>
> This is the declaration:
>         extern int open_vt(int n, int *pid_out);
>
> This is the call:
>         static struct vt {
>           int fd;
>           int count;
>           int xterm_pid;
>         } vts[MAX_TTYS];
>
>         int line;
>         vts[line].fd = open_vt(line, &vts[line].xterm_pid);
>
> I grabbed those snippets from the cvs browser:
>
> http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/um/drivers/stdio_conso
> le.h?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=user-mode-linux
>         http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/um/drivers/stdio_cons
> ole.c?rev=1.6&content-type=text/x-cvsweb-markup&cvsroot=user-mode-linux
>
>                                 Jeff

From
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/um/drivers/stdio_console_user.c?rev=1.6&content-type=text/x-cvsweb-markup&cvsroot=user-mode-linux

we see wrong open_vt() implementation:

int open_vt(int n)
{
    ....
}


Compile problem descriptions:

My build environment uses customized Mandrake 7.0 installation:
   - glibc 2.1.3
   - gcc 2.95.2.

Pristine uml-2.3.99-pre2 cannot compile without $(TOPDIR)/include{linux,asm} symlinked to
/usr/include/.

make[1]: Entering directory `/usr/src/linux-2.3.99pre-uml/arch/um/kernel'
gcc -D__KERNEL__ -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -g -U__i386__ -D__arch_um__
-fwritable-strings -fno-strict-aliasing -I../include  -c -o process.o process.c
In file included from /usr/include/signal.h:294,
                 from process.c:3:
/usr/include/bits/sigcontext.h:28: asm/sigcontext.h: No such file or directory
In file included from /usr/include/errno.h:36,
                 from process.c:5:
/usr/include/bits/errno.h:25: linux/errno.h: No such file or directory
process.c:9: asm/ptrace.h: No such file or directory
make[1]: *** [process.o] Error 1

I fixed this by adding -I$(HPATH) to USER_CFLAGS in um/kernel/Makefile

3) syscall_user.c and trap_user.c still do not compile:

gcc -D__KERNEL__ -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -g -U__i386__ -D__arch_um__
-fwritable-strings -fno-strict-aliasing -I/usr/src/linux-2.3.99pre-uml/include
-I../include  -c -o syscall_user.o syscall_user.c
In file included from syscall_user.c:12:
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:14: conflicting types for `open'
/usr/include/fcntl.h:68: previous declaration of `open'
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:21: conflicting types for `dup'
/usr/include/unistd.h:437: previous declaration of `dup'
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:28: conflicting types for `close'
/usr/include/unistd.h:296: previous declaration of `close'
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:35: conflicting types for `waitpid'
/usr/include/sys/wait.h:132: previous declaration of `waitpid'
make[1]: *** [syscall_user.o] Error 1

gcc -D__KERNEL__ -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -g -U__i386__ -D__arch_um__
-fwritable-strings -fno-strict-aliasing -I/usr/src/linux-2.3.99pre-uml/include
-I../include  -c -o trap_user.o trap_user.c
In file included from trap_user.c:11:
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:21: conflicting types for `dup'
/usr/include/unistd.h:437: previous declaration of `dup'
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:28: conflicting types for `close'
/usr/include/unistd.h:296: previous declaration of `close'
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:32: parse error before `pid'
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:32: warning: function declaration isn't
a prototype
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:34: parse error before `pid'
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:35: conflicting types for `waitpid'
/usr/include/sys/wait.h:132: previous declaration of `waitpid'
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h: In function `waitpid':
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:36: `pid' undeclared (first use in this
function)
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:36: (Each undeclared identifier is
reported only once
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:36: for each function it appears in.)
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:36: `stat_addr' undeclared (first use
in this function)
/usr/src/linux-2.3.99pre-uml/include/asm/unistd.h:36: `options' undeclared (first use in
this function)

After working around the above bugs
(I commented out "include asm/unistd.h", leaving only libc unistd.h include),

I finally got ./linux executable linked.

It, however, segfaulted inside memcpy a bit after successfully opened "vm_file":

.....
read(4, "n", 1)                         = 1
read(4, "u", 1)                         = 1
read(4, "x", 1)                         = 1
read(4, "\n", 1)                        = 1
open("vm_file", O_RDWR|O_CREAT|O_EXCL, 0777) = 6
unlink("vm_file")                       = 0
lseek(6, 618496, SEEK_SET)              = 618496
write(6, "\0", 1)                       = 1
mmap(NULL, 618496, PROT_WRITE, MAP_SHARED, 6, 0) = 0x40000000
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++


Core was generated by
`./linux                                                                       '.
Program terminated with signal 11, Segmentation fault.
#0  0x1008ebf7 in memcpy ()
(gdb) bt
#0  0x1008ebf7 in memcpy ()
Cannot access memory at address 0xbffff748


Unfortunatly, gdb does not show stack trace and line info.

Any comments?

Re: [User-mode-linux-devel] Cannot compile uml-2.3.99-pre2 from sources

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

> In the CVS:
>     - open_vt() from stdio_console_user.c conflicts with its prototype
> and calling place. 

I just checked this out and I don't see a problem:

This is the declaration:
	extern int open_vt(int n, int *pid_out);

This is the call:
	static struct vt {
	  int fd;
	  int count;
	  int xterm_pid;
	} vts[MAX_TTYS];

        int line;
	vts[line].fd = open_vt(line, &vts[line].xterm_pid);

I grabbed those snippets from the cvs browser:

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/um/drivers/stdio_conso
le.h?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=user-mode-linux
	http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/linux/arch/um/drivers/stdio_cons
ole.c?rev=1.6&content-type=text/x-cvsweb-markup&cvsroot=user-mode-linux

				Jeff

Re: [User-mode-linux-devel] Cannot compile uml-2.3.99-pre2 from sources

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

> I tried to build uml-2.3.99-pre2 from sources, but failed. 

I just grabbed my patch from sourceforge and rebuilt a kernel, so it's not 
hopelessly bad :-)

> moreover CVS and patch give different source trees. 

This surprises me a little, but not too much.  My CVS discipline has not been 
the best in the past, although I added something to the -pre2 build which 
should have caught any lingering differences.  I'll check this out and make 
CVS match the patch.

>     - um/kernel/irq.c references "linux/tasks.h" which does not
> exists; 

This is true.  I'll see if there's an easy way to prevent the compiler from 
looking in /usr/include (nostdinc does, but when I looked at that before, I 
thought there were nasty side-effects which couldn't be avoided).

You can get rid of that include.

>     - many files (for example syscall_user.c) include both "asm/
> somefile.h" and "somefile.h"
>       which have conflicts (/usr/include/unistd.h from glibc 2.1.3 and
> asm/unistd.h); 

This is ok.  It should get /usr/include/asm/somefile.h and 
/usr/include/somefile.h.  It should not get $(TOPDIR)/include/asm/somefile.h. 
and this is guaranteed by stripping that -I from the command line.  This is 
the compile line for syscall_user.c:
	gcc -D__KERNEL__ -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -g -U__i386__ 
-D__arch_um__ -fwritable-strings -fno-strict-aliasing -I../include  -c -o 
syscall_user.o syscall_user.c

The compiler has no way of finding the kernel headers.  It gets system headers 
and what's in ../include.

> The question is: where may I find good uml sources?

The patch is as good as you're going to get from me :-)

In order to fix this, I need to see your build output.

If you want to look into this yourself, the thing you need to know is this:
	The uml sources are divided into user-space files, which include only system 
headers and no kernel headers, and kernel files, which include only kernel 
headers and no system headers.  They communicate through headers that they 
both include, which are mostly located in arch/um/include (and a couple in 
arch/um/drivers).

Compile problems happen when system headers sneak into kernel files or kernel 
headers sneak into user-space files.  I've seen cases where I have a header 
missing from include/asm and the compiler finds the file in /usr/include/asm 
instead (and I'll check to see if -nostdinc will prevent that).  The rewriting 
of CFLAGS to eliminate the -I$(TOPDIR)/include from user-space file compiles 
should prevent kernel headers from sneaking into them.

				Jeff

[User-mode-linux-devel] Cannot compile uml-2.3.99-pre2 from sources

[Yuri P. <yu...@sw...>]

Hi!

I tried to build uml-2.3.99-pre2 from sources, but failed.

Both patch-2.3.99-pre2 and CVS contains a number of glitches,
moreover CVS and patch give different source trees.

Both in the CVS and in the patch:
    - um/kernel/irq.c references "linux/tasks.h" which does not exists;
    - many files (for example syscall_user.c) include both "asm/somefile.h" and
"somefile.h"
      which have conflicts (/usr/include/unistd.h from glibc 2.1.3 and
asm/unistd.h);

In the CVS:
    - open_vt() from stdio_console_user.c conflicts with its prototype and
calling place.

The question is: where may I find good uml sources?

Thank you in advance,
Yuri Pudgorodsky

[User-mode-linux-devel] 2.3.99-pre2 is checked in

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

The main change is that I redid the system call mechanism.  If the timer 
interrupted at the right point during a system call, the old method would 
cause the system call to return essentially a random number (actually the pid 
of the underlying thread).  This is the cause of the occasional panic during 
fsck.  That should not happen any more.  It may also have caused the syscall 0 
problems.

I added a little bit of geometry support to the block driver.  This allows 
fdisk to run on it and recognize a partition.  Since filesystems leave the 
first couple of blocks alone, you can run fdisk on a filesystem file and put a 
partition table on it.  I would recommend making the whole thing a single 
partition, since there is no support in the driver for multiple partitions in 
a single file.

				Jeff

[User-mode-linux-devel] [PATCH] Backport the 2.3.22 ptrace patch

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

Would it be possible (and likely :-) to stick the 2.3.22 patch below into 
2.2.x?  It removes the restriction that ptrace(POKEUSER, ...) can't modify 
system call numbers.

This is needed by my user-mode port and a few other apps.  It would be 
convenient for users to have this already in their kernels.

				Thanks, Jeff

diff -u --recursive --new-file v2.3.21/linux/arch/i386/kernel/entry.S 
linux/arch/i386/kernel/entry.S
--- v2.3.21/linux/arch/i386/kernel/entry.S	Sat Oct  9 11:47:50 1999
+++ linux/arch/i386/kernel/entry.S	Tue Oct 12 10:05:53 1999
@@ -237,8 +237,11 @@
 	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:
diff -u --recursive --new-file v2.3.21/linux/arch/i386/kernel/ptrace.c 
linux/arch/i386/kernel/ptrace.c
--- v2.3.21/linux/arch/i386/kernel/ptrace.c	Sun Jul 11 09:11:46 1999
+++ linux/arch/i386/kernel/ptrace.c	Tue Oct 12 10:05:53 1999
@@ -71,8 +71,6 @@
 	unsigned long regno, unsigned long value)
 {
 	switch (regno >> 2) {
-		case ORIG_EAX:
-			return -EIO;
 		case FS:
 			if (value && (value & 3) != 3)
 				return -EIO;

Re: [User-mode-linux-devel] Host kernel patch into 2.2.x?

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

> Quick question - Have you approached Alan Cox about including that
> short patch necessary for the host kernel in 2.2.x, x>15?

No.  I'll send some mail and see what he says...

> Does that patch fall in the category of "iffy, development kernel
> only", or "so trivially correct that it could very well make it into
> 2.2.x"?

It falls into the trivially correct category.

				Jeff

Re: [User-mode-linux-devel] 2.3.99-pre1 is checked in to cvs

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

> 	Did he have any suggestions about what might be more to his liking? 

We came to this arrangement:

Me:
> How about /dev/ubd* and /dev/ubd/* (ubd == user-mode block device)?

Him:
> That works.  You are block major 98. 

				Jeff

[User-mode-linux-devel] Host kernel patch into 2.2.x?

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

Good afternoon, Jeff et al,
	Quick question - Have you approached Alan Cox about including that
short patch necessary for the host kernel in 2.2.x, x>15?  I know it's way
too late for 2.2.15, but it would mean that future 2.2 kernel users could
use uml without having to recompile the kernel.  Despite my best efforts
to make that possible (Buildkernel, in my .sig), I strongly suspect most
people stay with whatever their distribution provides and never compile
their own.
	Does that patch fall in the category of "iffy, development kernel
only", or "so trivially correct that it could very well make it into
2.2.x"?
	Cheers,
	- Bill

---------------------------------------------------------------------------
Windows NT: n.
    32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit
    operating system originally coded for a 4-bit microprocessor,  written
    by a 2-bit company that can't stand for 1 bit of competition.
(Courtesy of Michael Neuffer <ne...@tr...>)
--------------------------------------------------------------------------
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] 2.3.99-pre1 is checked in to cvs

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

On Fri, 17 Mar 2000, Jeff Dike wrote:

> I fixed the swapping bug.  That turned out to be a long-standing bug and I'm 
> surprised I didn't see it before.  The problem was that the kernel vm area 
> wasn't mapped in to new processes, and if they needed to swap immediately, 
> they segfaulted when trying to read the swap map, which is vmalloced.

	Thanks!  I'll try it out this weekend.

> In other news, I tried getting a major number for the block device, which I 
> renamed vbd (== Virtual Block Device).  In the immortal words of hpa, "Both 
> these names are extremely poor choices" (he was also referring to /dev/disk/*).
> 
> Discussions are continuing...

	Did he have any suggestions about what might be more to his
liking?
	Cheers,
	- Bill

---------------------------------------------------------------------------
	Q: Will the tcp/ethernet SMP scaling changes be back-ported to 2.2.x?
	Mingo: yes, all SMP changes in 2.3 will be backported to 2.2 in the
next few months, but to not confuse it with 2.2 it will be named '2.4' ;)
	-- Ingo Molnar <mi...@ch...>
--------------------------------------------------------------------------
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] 2.3.99-pre1 is checked in to cvs

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

I fixed the swapping bug.  That turned out to be a long-standing bug and I'm 
surprised I didn't see it before.  The problem was that the kernel vm area 
wasn't mapped in to new processes, and if they needed to swap immediately, 
they segfaulted when trying to read the swap map, which is vmalloced.

I also moved thread cleanup, including killing the underlying process, up a 
bit.  The killing of the process now happens right after the new zombie calls 
schedule.  If this doesn't fix the out-of-processes problem that Lars saw, I 
don't know what will.

In other news, I tried getting a major number for the block device, which I 
renamed vbd (== Virtual Block Device).  In the immortal words of hpa, "Both 
these names are extremely poor choices" (he was also referring to /dev/disk/*).

Discussions are continuing...

				Jeff

[User-mode-linux-devel] Re: slip vs ethertap

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

> The ethertap could be brought up once during host system boot and left
> until uml-linux is started.  Just for example:  Boot scripts bring up
> tap0 w/ 192.168.0.254, ptp -> 192.168.0.253, and add a route to .253.
>  /dev/tap0 is given mode 660, owned by root/uml-group.

If you're doing serious network stuff, you'd want a bunch of them, and I'd be 
somewhat concerned about potentially locking out other ethertap users.

Also, the fact that both ends are configured a boot time before a uml runs 
means that the uml net setup scripts need to change to just accept whatever IP 
address the uml's /dev/tap has.  It also means that the IP address needs to be 
read out of the network driver somehow and fed back into ifconfig so that the 
network layer knows its own IP address.

> The right to access host networking is now down to whether ./linux is
> able to read and write to a preconfigured /dev/tap0.  Is that a more
> elegant approach?

It's better, but I'm not all that happy with it.

What security problems arise from letting normal users set the ptp address 
(assuming that address isn't already used) of an otherwise configured /dev/tap 
and letting them send and receive packets over it?

That's what I'd really like to be able to do.

				Jeff

[User-mode-linux-devel] Re: slip vs ethertap

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

Good afternoon, Jeff,

On Mon, 13 Mar 2000, Jeff Dike wrote:

> My current umn network driver uses slip as the kernel-to-user communications 
> mechanism.  I'm unhappy with this for two reasons:
> 	- the slip device needs to be ifconfig-ed, which means that either the kernel 
> needs to be run as root, or there needs to be a setuid ifconfig available 
> (i.e. um_ifconfig).

	Agreed.  Are Linux capabilities functional enough that one could
add CAP_NET_ADMIN to the uml-kernel file?  I suspect administrators would
be much happier typing "set_pcap +netadmin ./linux" than "chmod 4755
./linux".

> 	- there is no obvious way to configure both ends (especially the host end) of 
> the channel from the boot scripts.
> 
> I don't see that using ethertap helps either of these.  /dev/tap* still needs 
> to be ifconfig-ed, which still needs root privs somehow.  And using a 
> different communications mechanism to the hosting kernel doesn't seem to 
> change the problem of getting the host end ip address into the driver from the 
> networking layer above it.
> 
> Is this right?  Are there any advantages to using ethertap that I've 
> overlooked?

	The ethertap could be brought up once during host system boot and
left until uml-linux is started.  Just for example:  Boot scripts bring up
tap0 w/ 192.168.0.254, ptp -> 192.168.0.253, and add a route to .253.  
/dev/tap0 is given mode 660, owned by root/uml-group.
	tap0 just sits there until someone in uml-group start up uml with:
./linux tap=192.168.0.253,/dev/tap0
	at which point uml-linux assigns .253 to its internal tap0, opens
/dev/tap0 on the host filesystem as a normal file for read-write (perhaps 
locking it to avoid accidental opens by two uml's), and shuffles bytes
back and forth from its own /dev/tap0 to the host /dev/tap0.
	In fact, if I replace
route add -host 192.168.0.254 dev umn
route add default gw 192.168.0.254
	in the newly submitted 0.0.6 howto with
route add default dev umn
	, uml doesn't even have to know what IP is on the other end of the
tap-tap link.
	The right to access host networking is now down to whether ./linux
is able to read and write to a preconfigured /dev/tap0.  Is that a more
elegant approach?
	Cheers,
	- Bill

---------------------------------------------------------------------------
	Q: Will the tcp/ethernet SMP scaling changes be back-ported to 2.2.x?
	Mingo: yes, all SMP changes in 2.3 will be backported to 2.2 in the
next few months, but to not confuse it with 2.2 it will be named '2.4' ;)
	-- Ingo Molnar <mi...@ch...>
--------------------------------------------------------------------------
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] slip vs ethertap

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

My current umn network driver uses slip as the kernel-to-user communications 
mechanism.  I'm unhappy with this for two reasons:
	- the slip device needs to be ifconfig-ed, which means that either the kernel 
needs to be run as root, or there needs to be a setuid ifconfig available 
(i.e. um_ifconfig).
	- there is no obvious way to configure both ends (especially the host end) of 
the channel from the boot scripts.

I don't see that using ethertap helps either of these.  /dev/tap* still needs 
to be ifconfig-ed, which still needs root privs somehow.  And using a 
different communications mechanism to the hosting kernel doesn't seem to 
change the problem of getting the host end ip address into the driver from the 
networking layer above it.

Is this right?  Are there any advantages to using ethertap that I've 
overlooked?

				Jeff

[User-mode-linux-devel] 2.3.51 check-ins

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

I've checked in a few fixes, namely:
	adding a request for the input thread to forget about a file descriptor when 
it's closed.  This fixes the hang when shutting down the umn device by hand - 
it wasn't really a kernel hang; the input thread was hung in a read, which 
meant that any input source that depended on the input thread was useless.  
The serial line still uses its own input thread, so you could log in there.
	hooked up chroot and creat.
	mkrootfs doesn't contain the init files as here documents any more.

				Jeff

Re: [User-mode-linux-devel] Re: 2.3.51 Networking *smile*

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

adjih@inria..fr said:
>   I used it in an experimental program which I called 'usertunnel'
> which (which is not freely available), but which was working along
> those lines: 

[ Much snippage ]

Did you just draw all that up off the top of your head, or did you already 
have it lying around?

Anyway, that's exactly the sort of thing I've been poking around in ethertap.c 
looking for.

My main concern was whether I have to construct ethernet frames or whether the 
uppoer levels of the kernel are going to make them for me.

				Jeff

Re: [User-mode-linux-devel] Re: 2.3.51 Networking *smile*

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

Good morning, Jeff,

On Mon, 13 Mar 2000, Jeff Dike wrote:

> > How would it be if you used ethertap on the host and uml?  Could the
> > uml kernel connect the output of one tap to the input of the other and
> > vice-versa?
> 
> Where can I find something to read about ethertap?  Rusty also mentioned this 
> a while back, as a possible way to get rid of the um_ifconfig kludge.

	/usr/src/linux-2.3.51/Documentation/networking/ethertap.txt
	As best I understand it, it appears to the networking layer as
just another network interface that can send and receive
packets.  Anything sent out that interface can be sucked out of /dev/tap0
by a userspace program.  Anything that userspace program stuffs into
/dev/tap0 arrives at the nework layer as if it had been received on this
virtual interface.
	Rusty's netfilter package has some examples of applications that
can work with tap* and even some shell scripts used in his test suite to
show how to send and receive packets by hand from a shell script.
	http://www.samba.org/netfilter/0.90/0.90.html gets you to the
download page for the latest release; get the tar and look in the utils
and testsuite directories.
	Rusty is probably better for low level details than I.
	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
--------------------------------------------------------------------------

[User-mode-linux-devel] Re: 2.3.51 Networking *smile*

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

Jeff Dike writes:
 > > How would it be if you used ethertap on the host and uml?  Could the
 > > uml kernel connect the output of one tap to the input of the other and
 > > vice-versa?
 > 
 > Where can I find something to read about ethertap?  Rusty also
 > mentioned this 
 > a while back, as a possible way to get rid of the um_ifconfig kludge.
 > 

/usr/src/linux/Documentation/networking/ethertap.txt :-)

  I used it in an experimental program which I called 'usertunnel' which
(which is not freely available), but which was working along those lines:






User space tunnel
-----------------

usertunnel.py is a simple tunnel at the ethernet frame level.
Modified, it could offer proof of concept bridging.

It uses two abilities from the Linux kernel:

- /dev/tap : pseudo ethernet device in 2.1.x kernels. It is seen by the 
  kernel exactly as an ethernet device. The difference is that instead of
  sending (/receiving) physically the packet, it is sent (/received) to a
  process that has opened /dev/tap.
  (see /usr/src/linux/Documentation/networking/ethertap.txt)

- socket(..., SOCK_PACKET) : a type of socket similar to SOCK_RAW: the
  difference is that the socket will receive all the packets of a
  given _ethernet type_ (coming from all the interfaces). 

The usertunnel operate in two ways:

- tunnel using TCP/IP connection: actually IP over IP tunneling.
  The tunnel is first started as a server on a machine ; then a
  client is started on another machine, that makes a TCP/IP 
  connection to the server. Once the connection established,
  client and server exchange (symetrically) the frames they
  receive on each of their /dev/tap, via TCP/IP.
  Via TCP/IP the /dev/tap frame is sent as is, prefixed by two
  bytes indicating the size of the frame.

- tunnel using Ethernet: each frame received on /dev/tap is 
  encapsulated and sent on the Ethernet interface (eth0) with a
  special type (BridgeType=0xcda8) :
  | Ethernet dest. | Ethernet src. | type=0xcda8 | /dev/tap frame |
  It is sent to the destination whose ethernet address was specified
  on the command line.

Note:
- Because Python+/dev/tap0 doesn't give easily the frame boundary,
  only IP trafic is forwarded: IP headers are used to determine what
  is the actual frame length.

---------------------------------------------------------------------------

Frame formats:


- /dev/tap0 gives the frame with the following format (they
  are also written to /dev/tap0 with the same format):
²
      <-------------- ethernet frame -------------------...->
  0  1| 2  3  4  5  6  7| 8  9  10 11 12 13|14 15|16 17 ...
 00 00| Ethernet dest.  | Ethernet src.    |type | data ... 
 (pad)
 \----------------- tap frame ---------------------------.../

  the Ethernet address is actually FE:FD:00:00:00:00 (arbitrary
  set by the Linux kernel)


- with socket(..., SOCK_PACKET) the frames are received and sent
  with the same format without the padding (so it is a raw ethernet 
  frame):

  0  1  2  3  4  5| 6  7  8  9  10 11|12 13|14 15 16 17 ....
  Ethernet dest.  | Ethernet src.    |type | data ... 
 \----------------- ethernet frame -----------------------.../


---------------------------------------------------------------------------

Data flow in

 
  ================================================================

  USER SPACE PROCESS

   +------+
   |telnet|
   +------+   +------------+  (3)
      |       | usertunnel |<---------------------------------\
      |       +------------+                                  | 
      |                  |                                    |
  ================================================================
      |                  |                                    |
      V(1)               V(4)                                 |
     +-----------------------------------------+              |
     | Networking upper layers (socket/TCP/IP) |              |
     +-----------------------------------------+              |
      |                                     |                 |
      V(2)                                  V(5)              | 
   +--------------------------------+    +-----------------+  |
   |Ethernet pseudo-device /dev/tap0|    | Ethernet device |  |
   +--------------------------------+    +-----------------+  |
      |                                     |                 |
      \-------------------------------------------------------/
                                            |
   LINUX KERNEL                             |
  ================================================================
                                            |
                                            V(6)
                                        Physical ethernet link

(0):
     +----+                               +----+
     | m1 |                               | m2 |
     +----+ ip1                           +----+ ip2
        ^   ethaddr1                        ^    ethaddr2
        |                                   |
        +-----------------------------------+ Ethernet

  Two machines m1, m2 are used, connected by an Ethernet link.
  Let ip1 and ip2 be the IP addresses of m1 and m2 on Ethernet interfaces
  Let tapip1 and tapip2 be the IP addresses of m1 and m2 on tap0 interfaces
  Let ethaddr1 and ethaddr2 be the ethernet addresses on the 
  
  m1 has /dev/tap0 configured with:   ifconfig tap0 <tapip1>
  and m2 with:   ifconfig tap0 <tapip2>

  The usertunnel is started with:
  on m1:   usertunnel eth ethaddr2
  on m2:   usertunnel eth ethaddr1

  The figure assumes telnet is started on m1 to tapip2 (telnetd responds on
m2 to tapip1) and that a key is pressed. The data flow is then:

  (1) "telnet" sends a packet that contains the key (1 byte)
      it uses the system call: send(socket, <data:key>, <size of data>, ...)

  (2) the upper layers of the kernel processes this data as part of the
      TCP/IP connection: a TCP/IP packet is to be sent:
  [(pad)|pseudo eth|pseudo eth|ethType IP]???[ IP header | TCP header | data ]
      and is passed to the ethernet pseudo-device tap0

  (3) The ethernet frame is passed from tap0 to the usertunnel process
      usertunnel had open /dev/tap0 and was blocked in a recvfrom(...) call
      (or in a select(...), then followed by recvfrom(...)):
  [ 0000 | pseudo eth | eth | EthType IP=0x800| IP header | TCP header | data ]

  (4) usertunnel receives the frame as above, and encapsulate it:

  [ ethaddr2 | ethaddr1 | EthType special=0xcda08 | <tap0 frame> ]
  where <tap0 frame> is exactly the frame received via tap0 (above)

  This new frame is send to the kernel as a raw packet, using the
  socket created with a socket(...,SOCK_PACKET) and a sendto indicating
  the name of the device ("eth0").

  (5) The kernel dispatch it to the ethernet device driver of "eth0"
  without doing any TCP/IP (or upper layer) processing on it.

  (6) The ethernet driver receive the packet and transmit it physically
  on the link.


  At the reception of the packet it follows _exactly_ the reverse path
on the m2 machine, so the corresponding figure and description is not
included.



-- Cedric

[User-mode-linux-devel] Re: 2.3.51 Networking *smile*

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

> How would it be if you used ethertap on the host and uml?  Could the
> uml kernel connect the output of one tap to the input of the other and
> vice-versa?

Where can I find something to read about ethertap?  Rusty also mentioned this 
a while back, as a possible way to get rid of the um_ifconfig kludge.

> As one possibility, one could assign an ndb device to fhd1.  The fake
> device at the other end of the network could be (perhaps _must_ be; I
> don't know) pointing to a physical device with a partition table.

Ok, I'll keep that in mind.

> If it really is a matter of cut and paste, would it be useful to
> simply enable the remaining syscalls and printk/syslog their use the
> first time they get called in a given kernel along with a request to
> mail "syscall 674, at location blah..." to you/the devel list?

I'm starting to think about what to do about the remaining syscalls.  I've 
been doing them one at a time so I make sure each one is right, and I didn't 
make any typos or anything, but that is starting not to be so useful now.

> I brought it up because I'm moderately confident that I've never
> successfully gotten any data into swap space on 2.3.51/2.3.51-uml.  

I checked it out after I sent that mail, and swap is indeed not working...

				Jeff