user-mode-linux-devel

[User-mode-linux-devel] 2.3.49 #2

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

Good evening, Jeff,
	By adding devfsd to /sbin (loop mounts seem to be working; I
have my fingers crossed; darn, it's hard to type like this) and changing
the path in /etc/bootmisc.sh, I get:

Local time: Sat Mar  4 23:43:12 UTC 2000

Started device management daemon for /dev

	I still get strange warnings from inetd when the xterms are
re-enabled, but the xterms start just fine:
Starting internet superserver: inetd.
error stat'ing /dev/ttydirs/xxx/xxxxxxxxxxxxp1: No such file or directory

error stat'ing /dev/ttydirs/xxx/xxxxxxxxxxxxp2: No such file or directory

	/etc/issue, minor fix:
guest passwork is "guest"
             ^
	Off to try to get an RH6.2beta root_fs ready.  Do you have any
interest in posting it to uml.sourceforge?  I'd like to sincerely suggest
making two rpm's, one for the uml kernel, one for the root_fs itself, so
people can mix and match.  
	Cheers,
	- Bill

---------------------------------------------------------------------------
I'm waiting for their "...for Fucking Morons" series.
    - Stump on Slashdot, referring to a "for dummies" trademark dispute.
--------------------------------------------------------------------------
William Stearns (wst...@po...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at: http://www.pobox.com/~wstearns/
--------------------------------------------------------------------------

[User-mode-linux-devel] UML Howto, minor updates

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

Good day, all,
	A few minor updates to the uml howto attached - feedback gladly
accepted.
	Cheers,
	- Bill

---------------------------------------------------------------------------
	How's my programming?  Call 1-800-DEV-NULL
(Courtesy of http://www.tux.org/~ricdude/)
--------------------------------------------------------------------------
William Stearns (wst...@po...).  Mason, Buildkernel, named2hosts, 
and ipfwadm2ipchains are at: http://www.pobox.com/~wstearns/
--------------------------------------------------------------------------

[User-mode-linux-devel] 2.3.49 is in CVS

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

There is absolutely nothing new on this one.

Just drop the patch in, build, run, observe that it works, dump it into cvs.  
They should all be like this...

				Jeff

[User-mode-linux-devel] 2.3.48 is in cvs

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

There are a few extras besides from the .48 updates and devfs:
	fixed a bug which was making the consoles very unresponsive to keyboard input
	redid the way virtual console xterms are launched, which ought to fix the 
memory corruption
	hooked up the getpgid and mremap system calls

				Jeff

Re: [User-mode-linux-devel] Re: I added a tour of the source to the web site

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

> A traditional kernel makes a context switch when a system call (or a
> fault) occurs,

But it is still in the context of the process making the system call or fault. 
 The closest equivalent I could find was having the thread actually execute 
its own system calls.

> Now that I'm thinking of it, I guess the main reason for it might be
> the need to mmap(...) correctly the process memory.

That's one reason.

The real big reason is that system calls sleep.  And the tracing thread can't. 
 So the process ought to be the one sleeping, so it ought to be doing its 
system calls.

The other is that for SMP to work as it does in the other ports, a process 
task structure has to be at the bottom of the process kernel stack, which 
means that each process needs a different kernel stack, so they might as well 
be running on them.

This could obviously be done differently by redefining the current() macro, 
but it was convenient to do things like the other ports.

				Jeff

[User-mode-linux-devel] ReRe: I added a tour of the source to the web site

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

Jeff Dike writes:
 > [...]
 > I have a nice list of little nitty-gritty things I'm going to write up, and it didn't occur to me to write up something about how the whole thing is organized...
 > 
 > The tracing thread oversees the whole operation, but actual system calls happen in the process that invokes them.  That should have been clear in my system call write-up.  It wasn't, so could you tell me why it wasn't?  I'll see if I can make it more clear.

  Actually, it wasn't clear for me, because I didn't imagine that it could be
done that way :-) A traditional kernel makes a context switch when a
system call (or a fault) occurs, so I assumed that the tracing thread
was the "kernel context" in which kernel code was executed. It did not
occur to me that the tracing thread could pass the responsability back
to the user-mode-linux processes, and run mmap-ed kernel code there...
  Now that I'm thinking of it, I guess the main reason for it might
be the need to mmap(...) correctly the process memory.
  But this can make a port to NT more difficult: it would be necessary
in a Linux process, to keep the NT thread/process data structures
intact, along with the NT DLLs (for instance kernel32.dll, required
for any NT system call). I'll investigate this.

  Anyway, thank you for the new overview ; things are getting more and
more clear :-)

-- Cedric

Re: [User-mode-linux-devel] I added a tour of the source to the web site

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

I added an overview section to the top of the tour page.  Let me know whether 
it's any good...

				Jeff

Re: [User-mode-linux-devel] I added a tour of the source to the web site

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

adjih@inria..fr said:
> The problem with UML is that the tracing thread is started in a
> clone() call, and is difficult to debug: do you have a special gdb
> with clone() support ? Or do you simply attach the process later ?

I attach the process later.  gdb on Linux doesn't have any particular thread support, which makes things harder than they need to be.

> I tried to run the input thread in a clone() [instead of signals()]
> and to "mov <signals() info>,%ecx ; mov <new tracing thread stack>
> ,%eax; mov %eax,%esp ; push %ecx ; call <signals>". But for some
> reason the process crashes much _before_ reaching this modification
> (because argv/argc become invalid, because of the remaps???) 

You break it, you get to keep both pieces :-)

> What stays also unclear is whether the linux kernel is actually  run
> as the "tracing thread", and how memory manipulations are performed,
> when a process calls "brk()" for instance. I guess gdb the tracing
> thread is necessary for figuring out.

I have a nice list of little nitty-gritty things I'm going to write up, and it didn't occur to me to write up something about how the whole thing is organized...

The tracing thread oversees the whole operation, but actual system calls happen in the process that invokes them.  That should have been clear in my system call write-up.  It wasn't, so could you tell me why it wasn't?  I'll see if I can make it more clear.

				Jeff

[User-mode-linux-devel] I added a tour of the source to the web site

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

Jeff Dike writes:
 > It's at http://user-mode-linux.sourceforge.net/tour.php and it contains 
 > write-ups of the system call mechanism and the network driver.
 > 
 > I'd appreciate you looking at it and letting me know what you think
 > about it.
 > 
 > I'd also appreciate any and all contributions to it.  If you're 
 > interested in 
 > grokking a hunk of the code and writing it up, let me know, and 
 > I'll fill you 
 > in on the php and the hacked-up lxr in the background.

  The text is quite helpful. It is exactly what I tried to figure out.
The problem with UML is that the tracing thread is started in a
clone() call, and is difficult to debug: do you have a special gdb
with clone() support ? Or do you simply attach the process later ?

I tried to run the input thread in a clone() [instead of signals()] and to
"mov <signals() info>,%ecx ; mov <new tracing thread stack>,%eax;
mov %eax,%esp ; push %ecx ; call <signals>". But for some reason the
process crashes much _before_ reaching this modification (because argv/argc
become invalid, because of the remaps???)

  What stays also unclear is whether the linux kernel is actually 
run as the "tracing thread", and how memory manipulations are performed,
when a process calls "brk()" for instance. I guess gdb
the tracing thread is necessary for figuring out.

Cheers,
-- Cedric

Re: [User-mode-linux-devel] I added a tour of the source to the web site

[lars b. <la...@no...>]

Jeff Dike <jd...@ka...> writes:
> I'd appreciate you looking at it and letting me know what you think about it.

Whoa, absolutely great way of getting to know the code!

[User-mode-linux-devel] I added a tour of the source to the web site

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

It's at http://user-mode-linux.sourceforge.net/tour.php and it contains 
write-ups of the system call mechanism and the network driver.

I'd appreciate you looking at it and letting me know what you think about it.

I'd also appreciate any and all contributions to it.  If you're interested in 
grokking a hunk of the code and writing it up, let me know, and I'll fill you 
in on the php and the hacked-up lxr in the background.

				Jeff

[User-mode-linux-devel] 2.3.46 available

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

It's checked into CVS.  The highlights were various bugs in the fhd driver, 
one of which caused major memory corruption in 2.3.41, and the new tasklet 
mechanism.

				Jeff

Re: [User-mode-linux-devel] other than 2.3.36 ?

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

I'm going to put it into 2.5.  Whenever that happens...

				Jeff

[User-mode-linux-devel] other than 2.3.36 ?

[<jet...@ar...>]

i would like to know if this 'user-mode-linux' will be 
included as a new arch or each new mainstream kernel will 
need to be modified to run in user space ?

Re: [User-mode-linux-devel] Fwd: Q: TCP_TW_RECYCLE_TICK for HZ == 10

[lars b. <la...@no...>]

jd...@ka... writes:
> What exactly is TCP_TW_RECYCLE_TICK?

I'm not sure, but I think TW stands for time wait.  Something to do with
the state of a TCP socket?

Re: [User-mode-linux-devel] Fwd: Q: TCP_TW_RECYCLE_TICK for HZ == 10

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

> TCP_TW_RECYCLE_TICK = (log(HZ)+2-TCP_TW_RECYCLE_SLOTS_LOG)
> If HZ is not a 2^N, then it is rounded up to the closest power of two.
> In your case it is:

> #define TCP_TW_RECYCLE_TICK (4+2-TCP_TW_RECYCLE_SLOTS_LOG)


Thanks for the tip.

What exactly is TCP_TW_RECYCLE_TICK?

				Jeff :-)

[User-mode-linux-devel] Fwd: Q: TCP_TW_RECYCLE_TICK for HZ == 10

[lars b. <la...@no...>]

This might be useful for 2.3.41.

From: ku...@ms...
Subject: Re: Q: TCP_TW_RECYCLE_TICK for HZ == 10
To: lar...@in... (lars brinkhoff)
Date: Tue, 1 Feb 2000 19:39:45 +0300 (MSK)
Cc: lin...@vg...

Hello!

> In 2.3.41, include/net/tcp.h says:
> 
> #if HZ == 100
> #define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG)
> #elif HZ == 1024
> #define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG)
> #else
> #error HZ != 100 && HZ != 1024.
> #endif
> 
> What should TCP_TW_RECYCLE_TICK be defined as for, say, HZ == 10?

TCP_TW_RECYCLE_TICK = (log(HZ)+2-TCP_TW_RECYCLE_SLOTS_LOG)

If HZ is not a 2^N, then it is rounded up to the closest power of two.
In your case it is:

#define TCP_TW_RECYCLE_TICK (4+2-TCP_TW_RECYCLE_SLOTS_LOG)

Alexey Kuznetsov

Re: [User-mode-linux-devel] latest cvs checkins

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

> How about NUMA support?  Multiple UML's could be communicating across
> a network to give the appearance of one big NUMA machine. 

That would be interesting.  It's essentially a shared-memory interconnect 
(DEC's name for it was the Memory Channel).  You'd have them allocating pages 
from a hunk of memory shared between the umls.

But, until there's things like process migration and a common filesystem, you 
can't treat a bunch of machines as a real cluster.

Until that happens, the only thing you could use the interconnect for would be 
a network.

				Jeff

Re: [User-mode-linux-devel] latest cvs checkins

[lars b. <la...@no...>]

Jeff Dike <jd...@ka...> writes:
> This is a first pass of the SMP support.

How about NUMA support?  Multiple UML's could be communicating across
a network to give the appearance of one big NUMA machine.

Of course, access to memory on another network node will be slow,
especially access to shared writable pages.  But then, that's normal
on NUMA machines.

Memory type:                    Access method:
local read-only                 direct access
local read-write, COW           direct access
local read-write, shared        direct access (unless being written remotely)
remote read-only                copied from remote node, then direct access
remote read-write, COW          copied from remote node, then direct access
remote read-write, shared       something painful

[User-mode-linux-devel] latest cvs checkins

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

This is a first pass of the SMP support.  It boots on one processor.  The 
multiple CPU support is coming in the next pass.

Things that needed to be done:
	current was changed to be the bottom of the current stack, like all the other 
arches, rather than the global variable it was before.  This required a bunch 
of changes in code that doesn't necessarily execute on a kernel stack.
	It also required restructuring code that was supposed to be running on a 
kernel stack, but wasn't.
	The input code was rearranged to more closely resemble the other arches by 
having it schedule a bh to handle the input.

				Jeff

Re: [User-mode-linux-devel] implementation questions

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

> > 3. Is the kernel protedted from user mode access, and if so, how?
>
> No. 

I thought I'd expand on this a little bit.  It would make a nice project for 
someone who's interested (which I am, just not enough to implement it right 
now).

The first problem is that a hostile thread could gain access to the outside 
system by crashing the tracing thread.  Right now, this is easy.  Just pollute 
the thread's stack (located at 0x50000000-0x50001000 for your cracking 
convenience :-).  Protecting it or unmapping it won't work because those 
require system calls, which will be intercepted.

So, fixing this was impossible under the old implementation which had all the 
threads running in a single address space.  Now, with the threads in different 
address spaces, it is possible for the tracing thread to have a stack which no 
other thread can touch.  It would have to be malloced or mmapped private.  All 
kernel data is shared.

The next problem is the kernel text and data.  It might seem that polluting 
this could only hurt the hostile thread and its innocent comrades, but by 
locating its own task structure and modifying .thread.tracing and/or 
.thread.want_tracing, it could fool the tracing thread into giving it access 
to the outside system.

This is solved by protecting the kernel text and data on entry to user mode 
and unprotecting it on exit to kernel mode.  This would be done from 
syscall_handler for system calls, which runs on the process stack.  Interrupts 
would have to run on a third stack (not process or kernel) which is always 
unprotected.  It doesn't matter if it gets corrupted, because it will be 
orverwritten anyway.

				Jeff

Re: [User-mode-linux-devel] implementation questions

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

> I have some questions about the implementation of uml:
> 1. Why is TIMER_VIRTUAL used instead of TIMER_REAL?

Because this is a virtual machine, and so it runs on virtual time...

Also, this makes better guarantees about the regularity of the timer interrupt 
on a loaded system than TIMER_REAL would.  It also provides more consistent 
BogoMips :-)

> 2. Why is SIGVTALRM blocked during a SIGSEGV?

Because I wasn't sure whether the fault handler should be protected, so I did 
it to be safe.

> 3. Is the kernel protedted from user mode access, and if so, how?

No.

> (Perhaps the answers could be documented somewhere, in case someone
> else is interested in the implementation.) 

This is it, unless someone else feels like writing this stuff down...

				Jeff

[User-mode-linux-devel] implementation questions

[lars b. <la...@no...>]

I have some questions about the implementation of uml:

1. Why is TIMER_VIRTUAL used instead of TIMER_REAL?

2. Why is SIGVTALRM blocked during a SIGSEGV?

3. Is the kernel protedted from user mode access, and if so, how?

(Perhaps the answers could be documented somewhere, in case
someone else is interested in the implementation.)

Re: [User-mode-linux-devel] Portability

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

ced...@in... said:
> Actually, I wondered too if uml could be ported to Windows NT, but
> after just running strace on uml-linux, I still don't understand
> perfectly how it works :-)

Really?  I don't know what more information you could ask for :-)

Actually, you only straced the input thread, which probably the least 
interesting thread in the whole thing.  It just sits in a select waiting for 
input on file descriptors that the other threads think are interesting and 
sending it to them

> Did you post some information about it somewhere (kernel list,
> newsgroup) ?

I had some lame information on my old web site, but it got out of date pretty 
quickly.  I'm much better at writing code than writing down explanations of it 
(or at least much more interested) :-(

And if any of the slackers out there are interested in doing something useful, 
and can write this stuff up by reading sketchy explanations from me and the 
code, I'd be happy to put the results up on the web site...

>   Ok, a quick look at /proc/*/maps, shows that maybe you allocated a
> file for the physical memory and mmaped it at the right places in each
> thread (this is how I suggested to make a user-space freemware, using
> also a main process that ptraces another to catch exceptions, software
> interrupts, emulate specific instructions... and setting the proper
> memory map at each context switch). 

Right, except that big chunk at 0x50000000 also includes the kernel virtual 
memory.  The "physical" memory gets mmaped appropriately into the kernel vm 
area and into process vm areas.

> - NT debugging process receives an exception_event when you execute
> an "int 0x80". I made a test program: parent+child, where the child
> would execute an int 0x80, the parent would see this, get the eip
> address, change  the "int 0x80" to "nop ; nop", and have the child
> going on. This works.

Are you sure that the int 0x80 didn't execute?  You nulled it out, but it kind 
of seems to me that you nulled it out after the fact.

> - My Windows 98 locks instantly _sometimes_ when running the same
> program executing "int 0x80". 

According to Lars, Win98 is a lost cause because of lack of mmap (or at least 
lack of it in the cygwin libraries).

From what you've said, it looks like NT has everything needed.  Go for it :-)

				Jeff

Re: [User-mode-linux-devel] Portability

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

Jeff Dike writes:
 > > > Posix compatibility is definitely not enough.  I think the 
 > > > biggest problem would be the ability to intercept and modify 
 > > > Linux system calls.  Nothing works without that.
 > >
 > > Ah, a light dawns.  I wondered (without wondering enough to learn the
 > > Linux and uml internals) how you virtualized the machine.  This
 > > combines with the comments about debugging yourself to explain the
 > > fundamentals... 
 > 
 > Actually, with an OS that maps reasonably well to Linux, it might
 > not be hard 
 > to replace the top layer (the bit that intercepts system calls) with its 
 > equivalent.  It would run its own binaries and map those syscalls
 > onto Linux 
 > syscalls.
 > 
 > Everything below that layer it Posix, I think.  Except maybe some of the 
 > mmaping that I do.

  Actually, I wondered too if uml could be ported to Windows NT,
but after just running strace on uml-linux, I still don't understand
perfectly how it works :-)
Did you post some information about it somewhere (kernel list,
newsgroup) ?
  Ok, a quick look at /proc/*/maps, shows that maybe you allocated
a file for the physical memory and mmaped it at the right places
in each thread (this is how I suggested to make a user-space
freemware, using also a main process that ptraces another to catch
exceptions, software interrupts, emulate specific instructions...
and setting the proper memory map at each context switch).

  Anyway for NT, the question would rather be whether how much
you need out of ANSI-C ?
All what I know is the following:
- NT (Windows?) has the equivalent of "ptrace" except that you only
get the DLL load/unload and the exceptions (with the "debugging
functions").
- NT debugging process receives an exception_event when you execute 
an "int 0x80". I made a test program: parent+child, where the child
would execute an int 0x80, the parent would see this, get the eip
address, change  the "int 0x80" to "nop ; nop", and have the child
going on. This works.
- My Windows 98 locks instantly _sometimes_ when running the same
program executing "int 0x80". Otherwise the system display a
full screen fatal error, ask for enter to be pressed and stop the
process normally. According to "Undocumented Windows NT",
Set_PM_Int_Vector could be used to hook a software interrupt,
though.
- NT has some file maping and some virtual memory management
functions that should provide some of the capabilities of mmap
(and more).
  The nice thing about NT, is that it has some way to manipulate
the file/memory maping of other processes, so maybe it would do.
For 95, there are additionnal limitations (such as copy-on-write
forced when maping files for write), that were probably the source
of problems for mmap in Cygnus tools.

-- Cedric