user-mode-linux-devel

[User-mode-linux-devel] more checkins

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

The major change in this batch is that disk I/O is now asynchronous.  There is 
now a separate thread which handles disk I/O and sends a SIGIO to the kernel 
whenever an operation has completed.

I fixed a few bugs, including (I think, I haven't checked it yet) the one 
where the network freezes.

The fhd device and its occupation of block major 62 are now history.  So, if 
this kernel stops booting, this is probably why.

				Jeff

[User-mode-linux-devel] CVS checkins

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

I've made another batch of checkins.  They include:

the beginnings of the IA-64 port
the userspace access macros now do access checking properly
fixed a race early in the boot process caused by a SIGVTALRM hitting before 
the signal handler had been set up
put some checks in sys_ptrace to make sure that kernel memory can't be 
accessed through ptrace

And, as a bonus, I found a way to crash it that I don't know how to fix yet.  
So, if you've always wanted to panic a virtual machine but didn't know how, 
here's what you do:

boot it up with an extra virtual console or two
log in and run 'strace -f -p <pid>' with the pid of a getty running on a 
virtual console
log in on that console
you will probably get a nice kernel-mode fault

This seems to be somewhat dependent on what strace finds in some random memory 
that it's looking at, but this is reliable for me...

				Jeff

Re: [User-mode-linux-devel] Implementation question...

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

sa...@sk... said:
> Each virtual linux process is actually a real linux cloned process
> that runs under the host linux environment.  When something
> interesting happens (trap, fault, syscall, signal, etc...) the virtual
> linux kernel takes over and fixes stuff. 

So far, so good.

> Given this, it seems like UM Linux isn't using ptrace to actually do
> memory reads and writes to the user process... so what could the
> memory map of the mondo linux process look like?  Are all linux
> processes sharing a 3G process space of the UM-Linux kernel?

You run into trouble here.  If you do a ps in the host, you'll see a 'tracing 
thread' process.  That thread is ptracing all of the other threads mostly to 
intercept their system calls.

When one of the virtual processes does a system call, the tracing thread warps 
the process onto its (the process) kernel stack by ptrace(PTRACE_GETREGS, ...) 
to save the process state and ptrace(PTRACE_SETREGS, ...) to set its state to 
some previously saved state that puts it in syscall_handler which actually 
executes the system call.

Since processes run their own system calls, kernel text and data is present in 
each address space.  The memory map of a typical thread looks like:

0x8000000 - 0x80xxxxx : process text and data
0x10000000 - 0x10xxxxxx : kernel text and data
0x40000000 - 0x40xxxxxx : process shared libraries
0x50000000 - 0x5xxxxxxx : kernel "physical" and virtual memory
0xb7fxxxxx - 0xb8000000 : process stack
0xbffxxxxx - 0xc0000000 : original kernel stack (not used for much except 
storing the name you see with ps in the host)

Every process gets its own address space.  Kernel data is made shared with a 
nasty bit of code that you can find in remap_data() in 
um/arch/um/kernel/user_util.c.

> I'm trying to change this a bit to be more seperated and use ptrace to
> do reads and writes...

You need to be more clear about what you're up to...

get_user and friends are trivial since the address space contains both kernel 
and process data.  They are essentially memcpy().  (Actually, I just finished 
making them a lot less trivial in order for them to detect bogus address 
correctly, but that's irrelevant here.)

> The problem, however, is that the "UM User" processes and "UM Kernel"
> processes can have data mapped into the same addresses...

There is no such thing as a "kernel" process.  Every process runs its own 
kernel code.

				Jeff

[User-mode-linux-devel] Implementation question...

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

Hi there...

I'm wondering how the get_user/put_user macros work in UM linux... Does
the kernel share memory space with each of the "linux processes"?  Here is
my understanding of how this works:

Each virtual linux process is actually a real linux cloned process that
runs under the host linux environment.  When something interesting happens
(trap, fault, syscall, signal, etc...) the virtual linux kernel takes over
and fixes stuff.

Given this, it seems like UM Linux isn't using ptrace to actually do
memory reads and writes to the user process... so what could the memory
map of the mondo linux process look like?  Are all linux processes sharing
a 3G process space of the UM-Linux kernel?

I'm trying to change this a bit to be more seperated and use ptrace to do
reads and writes... but it seems that the "get_user" macro (f.e.) is
allowed to read from either user or kernel space... and the address
determines what we are looking at.  The problem, however, is that the "UM
User" processes and "UM Kernel" processes can have data mapped into the
same addresses... thus there seems to be no easy way to ge tthis to work?

-Chris

[User-mode-linux-devel] CVS updates

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

I've checked in some more stuff:

The ubd driver supports a new ioctl so it can look like a CD-ROM.  It also now 
has the option of taking over a different major number.

The console driver isn't so quick to panic if tcsetattr fails.

Fixed a bug which was causing signals to be blocked when they should be 
enabled and vice-versa.

Got rid of the input thread, which isn't needed now that input is totally 
signal-driven.  Its remaining jobs are now handled by the tracing thread.

				Jeff

Re: [User-mode-linux-devel] Problems getting user-mode-linux to work with 2.4.0-test1 kernel...

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

The snippet of console output you show has devfs not being mounted.  That is 
the error you get when devfs isn't mounted and you boot a filesystem with no 
/dev.

So, either put 'devfs=mount' on the command line or reconfigure it with the 
'devfs mounts by default' option.

				Jeff

[User-mode-linux-devel] Problems getting user-mode-linux to work with 2.4.0-test1 kernel...

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

Hey all,

Does anyone have any experience playing with user-mode linux and a
2.4.0-test1 kernel?  I applied the kernel patch and got everything to
build (one chunk didn't go in correctly, but that wasn't a big
deal)... but it seems that something has changed in the kernel design that
is causing the console driver to not get registered... I'm getting:

...
devfs: boot_options: 0x2
VFS: Mounted root (ext2 filesystem) readonly.
Warning: unable to open an initial console.

And then it hangs (thread blocking in select).  I'm not familiar enough
with the code to figure out how linux goes through the process of mapping
a sys_open("/dev/console"...) to a fn call in the arch/um directory...

Anyways, thanks for all the great work!  Hopefully I'll be able to help
out in a more meaningful way soon!

-Chris

[User-mode-linux-devel] pre9 CVS checkin

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

2.3.99-pre9 is checked in.  The one change I had to make was backing out a 
change in copy_mount_options in fs/super.c which relied on handling of 
user-mode induced kernel memory faults (i.e. a process passes a bogus address 
into a system call which causes a kernel-mode fault when it is dereferenced) 
which I don't yet do right.

				Jeff

[User-mode-linux-devel] pre-pre9 CVS checkins

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

I decided to check in the irq stuff and a bunch of other things before doing 
-pre9.

So, there is now a real irq system in there.

include/asm-um/highmem.h is now there, not that it did anybody any good :-)

I fixed the console stair-stepping.

There is now a real fix for that hang that people were seeing last week.

I fixed the missing errno problem in get_pty in arch/um/kernel/user_util.c.

				Jeff

[User-mode-linux-devel] Re: [User-mode-linux-user] The -pre8 compilation problems

[Lennert B. <bu...@gn...>]

Yes, fixed it. Thanks.


Lennert



On Wed, 24 May 2000, Jeff Dike wrote:

> I reproduced this problem on sourceforge.  The kernel looks at its own maps 
> when it starts up because it needs to fiddle the shareability of its data and 
> to mark those parts of its address space off-limits for mmap.
> 
> In arch/um/kernel/tlb.c, it reads its maps into a fixed-length array, and 
> panics if it find too many.  For some reason, when you compile locally, you 
> get a different number of maps than when you use the precompiled binaries.
> 
> For now, apply this patch:
> --- arch/um/kernel/tlb.c~  Wed May 24 09:09:49 2000
> +++ arch/um/kernel/tlb.c   Wed May 24 09:23:39 2000
> @@ -179,7 +179,7 @@
>  
>  /* text, data, init_task, data, bss, physical memory in three chunks, 
>     virtual memory area, stack */
> -static struct vm_area_struct process_vmas[10 * (NESTING + 1)];
> +static struct vm_area_struct process_vmas[20 * (NESTING + 1)];
>  static int num_process_vmas = 0;
>  
>  void add_perm_vma(unsigned long start, unsigned long end, char rperm, 
> 
> I'll figure out a better way of doing this later.
> 
> 				Jeff
> 
> 
> 
> 
> _______________________________________________
> User-mode-linux-user mailing list
> Use...@li...
> http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-user
> 

[User-mode-linux-devel] The -pre8 compilation problems

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

I reproduced this problem on sourceforge.  The kernel looks at its own maps 
when it starts up because it needs to fiddle the shareability of its data and 
to mark those parts of its address space off-limits for mmap.

In arch/um/kernel/tlb.c, it reads its maps into a fixed-length array, and 
panics if it find too many.  For some reason, when you compile locally, you 
get a different number of maps than when you use the precompiled binaries.

For now, apply this patch:
--- arch/um/kernel/tlb.c~  Wed May 24 09:09:49 2000
+++ arch/um/kernel/tlb.c   Wed May 24 09:23:39 2000
@@ -179,7 +179,7 @@
 
 /* text, data, init_task, data, bss, physical memory in three chunks, 
    virtual memory area, stack */
-static struct vm_area_struct process_vmas[10 * (NESTING + 1)];
+static struct vm_area_struct process_vmas[20 * (NESTING + 1)];
 static int num_process_vmas = 0;
 
 void add_perm_vma(unsigned long start, unsigned long end, char rperm, 

I'll figure out a better way of doing this later.

				Jeff

Re: [User-mode-linux-devel] cat /proc/interrupts

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

nu...@r4... said:
> ....kills usermode linux nicely. But the host is nice and stable. I
> just LOVE that :) 

That's fixed in my next release.  I'm putting in a real irq system and 
/proc/interrupts comes along more-or-less for free.

				Jeff

Re: [User-mode-linux-devel] Compiling pre8

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

You appear not to be the only one.  It works fine for me :-)

Look at the "problems executing uml-2.3.99-pre8" thread on the user list for 
more examples.  I discovered a header that I didn't write that could be the 
cause.  Put the below in arch/asm-um/highmem.h and rebuild:

#ifndef __UM_HIGHMEM_H
#define __UM_HIGHMEM_H

#include "asm/arch/highmem.h"

#endif

If that doesn't do it, I might need one of you troublemakers to let me on your 
box so I can have a look :-)

				Jeff

[User-mode-linux-devel] Compiling pre8

[James R. L. <jl...@mi...>]

Is anyone else having probelm compile there own kernel with pre8?

tar -zxvf linux-2.3.99-pre8.tar.gz
cd linux
bzip2 -dc ../patch-2.3.99-pre8.bz2 | patch -p1
cd include/asm
ln -s ../asm-i386 arch
cd ../../
cd arch/um/include/
ln -s sysdep-i386 sysdep
cd ../../../
make menuconfig
make dep ; make linux

The resulting "kernel" hangs in select() right after getting a sigtrap.
Obviously I'm screwing something up.

Host system is rh 6.1 running a 2.3.99-pre6 kernel

Any help would be greatly appreciated.

Jim
-- 
James R. Leu

[User-mode-linux-devel] cat /proc/interrupts

[<nu...@r4...>]

....kills usermode linux nicely. But the host is nice and stable. I just
LOVE that :)

--buddy

Re: [User-mode-linux-devel] ifconfig idea

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

> perl script is out of the question...SUID scripts is even worse (well
> maybe not) than SUID ifconfig.  A simple binary is probably a better
> idea. 

I thought I read somewhere in the perl docs that safe suid perl scripts were 
doable.  Anyway, a binary would be easy enough, too.  If you're so bothered by 
it, why not write up a nice little ifconfig wrapper, and I'll distribute it 
instead of my stupid um_ifconfig :-)

> I dont know TOO much, but i think it's more a kernel thing that's
> restricting it from doing things..ifconfig doesn't really do much
> error checking... 

I think you're right.

BTW, configuring the device isn't the only permissions problem with the net.  
In order to set up a slip device, you need to get a pty.  I currently use a 
pts device, and on some distros (like Debian) the permissions on /dev/pts 
don't allow random users to do that.  One more reason to go over to an 
ethertap network.

				Jeff

Re: [User-mode-linux-devel] ifconfig idea

[<nu...@r4...>]

> 
> The actual device names aside, what do you mean up letting ifconfig ONLY 
> configure umn and lo?  Are you talking about me shipping a restricted ifconfig 
> that people are supposed to make suid root?  

yup....some kind of checking to make sure the arguments are what UML will
be using....

> That can be done with a perl 
> script or a little binary that checks its arguments and execs ifconfig.
> 
perl script is out of the question...SUID scripts is even worse (well
maybe not) than SUID ifconfig.  A simple binary is probably a better idea.

> Long-term, I do think that ifconfig needs to lighten up a bit.  Maybe by 
> looking at the permissions of the tap devices (which I don't think it does 
> now).

I dont know TOO much, but i think it's more a kernel thing that's
restricting it from doing things..ifconfig doesn't really do much error
checking...

--buddy

Re: [User-mode-linux-devel] ifconfig idea

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

nu...@r4... said:
> Well, i don't exactly like making a SUID ifconfig binary, nor do i
> like running UML as root. 

Nobody likes it, least of all me.

> How about a patch to ifconfig such that it ONLY ifconfig's 'umn' and
> 'lo' with their respective IPs. 

Because in the hosting kernel, where the permission problems are, the device 
being ifconfig-ed is sl* (and /dev/tap* if that ethertap interface gets 
finished).

The actual device names aside, what do you mean up letting ifconfig ONLY 
configure umn and lo?  Are you talking about me shipping a restricted ifconfig 
that people are supposed to make suid root?  That can be done with a perl 
script or a little binary that checks its arguments and execs ifconfig.

Long-term, I do think that ifconfig needs to lighten up a bit.  Maybe by 
looking at the permissions of the tap devices (which I don't think it does 
now).
				Jeff

[User-mode-linux-devel] ifconfig idea

[<nu...@r4...>]

Well, i don't exactly like making a SUID ifconfig binary, nor do i like
running UML as root.

So, here's my idea and i hope someone can take it and run with it.

How about a patch to ifconfig such that it ONLY ifconfig's 'umn' and 'lo'
with their respective IPs.

suggestions?

--buddy

[User-mode-linux-devel] more CVS updates

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

I added some code to speed up context switching.  Before, the woken-up process 
needed to do a complete page table walk in order to update its address space 
with any changes that had occurred when it was asleep.

Now, proc->mm->segments remembers those changes, and on most wakeups, this 
list can be used to do the updates.

I also made /proc/interrupts contain some minimal useful information.

				Jeff

[User-mode-linux-devel] CVS updates

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

I've checked in a redesign of the system call dispatch mechanism.  Instead of 
that huge switch in arch/um/sys-$(SUBARCH)/syscalls.c (and formerly 
arch/um/kernel/syscall_kern.c), there is now an array of function pointers in 
arch/um/kernel/sys_call_table.c.  This includes "sysdep/syscalls.h", in which 
each arch is expected to define ARCH_SYSCALLS, which initializes the system 
calls specific to that arch, and LAST_SYSCALL, which is the last defined 
system call for that arch.

This moves all of the common code back to arch/um/kernel where it belongs, and 
makes arches define only those system calls it does differently.

				Jeff

[User-mode-linux-devel] -pre8 CVS updates

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

The -pre8 changes are checked in.

The major change here is that kernel modules now work.  Note that you can't 
use modules from your host kernel.  You have to use modules that were built in 
the user-mode pool.  To get them installed in the user-mode filesystem, I 
mount the filesystem in mnt at the top of the pool, and run 'make 
modules_install INSTALL_MOD_PATH=`pwd`/mnt'.  This will drop the modules in 
the right place.  Make sure you unmount it before running the kernel.

I'm sure that there are lots of symbols that arch is going to need to export.  
I exported just enough to get isofs working as a module.  When you run into 
them, let me know, and I'll export them.

				Jeff

[User-mode-linux-devel] -pre7 CVS updates

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

I've checked in the -pre7 code.  The only updates to the arch code involved  
device names changing from a pointer to an array, some locking changes in 
ptrace, and new handling of the return from handle_mm_fault in the seg fault 
handler.

				Jeff

[User-mode-linux-devel] CVS checkins

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

This set includes more abstracting away i386-specific code, and it also 
includes the first drop of Chris Emerson's ppc code.

				Jeff

Re: [User-mode-linux-devel] UML/PPC status

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

> I'll have to have a closer look.  At the moment all that I see is a
> zombie process.

Make sure that it's hitting the segfault handler.  If it's not, figure out why 
it's not being installed.

> I've been running 'killall -KILL linux' a lot recently. 

You'll get used to that :-)

> Incidentally, have you got gdb usefully debugging this sort of thing? 

The basic problem is that a process can only have one ptrace parent at a time, 
and most of the threads are already being ptraced by the tracing thread.  So, 
if you send the thread you're interested in a SIGUSR1, the tracing thread will 
see it and detach that thread.  At that point, you can attach to it with gdb 
and poke around.

> Is padzero the first one to happen?  If not, it's possibly even
> stranger. 

It's the second.  The stack initialization happens first.

				Jeff