From: Benedict V. <ben...@gm...> - 2008-06-04 09:32:33
|
Hi, i have a problem with running ssh on an etch UML system. I think this problem only started since Debian had the openssl bug. When i try to run sshd using /etc/init.d/ssh start, it doesn't run anymore. It prints the starting message but that's all. No sshd process running. When i try the command as specified in the /etc/init.d/ssh script, it doesn't run either: start-stop-daemon --start --quiet --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd -- However, when i add the -d switch on the above line, it works. /usr/sbin/sshd -d & works, /usr/sbin/sshd & doesn't work either. Logging revealed this: sshd[2729]: fatal: Couldn't obtain random bytes (error 604389476) /dev/random and /dev/urandom are present however Any ideas? Regards, Benedict |
From: Cameron K. <ck...@cs...> - 2008-06-05 00:02:54
|
If you use -d, chances are it probably doesn't work correctly either, but by then its already put itself into the background and so you see it return. What does it '/usr/sbin/sshd' pause on when you run it inside strace? I'm thinking it may be that its pausing because the system has run out of entropy to give suitable random data for /dev/random. You could try "stirring in" some entropy by doing something like moving the mouse a lot, or doing a lot of disk IO on the host; the host kernel gathers entropy from such events. Ideally though, you would have a hardware random number generator (RNG) on your motherboard, which all(?) modern systems will have. Ensure your host has support for this in the kernel (or loaded via module). I'm not sure if the guest will source its /dev/random from the hosts / dev/random or not. On 04/06/2008, at 9:31 PM, Benedict Verheyen wrote: > Hi, > > > i have a problem with running ssh on an etch UML system. > I think this problem only started since Debian had the openssl bug. > > When i try to run sshd using /etc/init.d/ssh start, it doesn't run > anymore. It prints the starting message but that's all. No sshd > process > running. > > When i try the command as specified in the /etc/init.d/ssh script, > it doesn't run either: > start-stop-daemon --start --quiet --pidfile /var/run/sshd.pid --exec > /usr/sbin/sshd -- > > However, when i add the -d switch on the above line, it works. > /usr/sbin/sshd -d & works, /usr/sbin/sshd & doesn't work either. > > Logging revealed this: > > sshd[2729]: fatal: Couldn't obtain random bytes (error 604389476) > > /dev/random and /dev/urandom are present however > > Any ideas? > > Regards, > Benedict > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > -- Cameron Kerr <ck...@cs...> Teaching Fellow, Computer Science, University of Otago NOTE: I only check my e-mail at 11am each day, to improve time management. |
From: Benedict V. <ben...@gm...> - 2008-06-05 07:31:00
|
Cameron Kerr wrote: > If you use -d, chances are it probably doesn't work correctly either, > but by then its already put itself into the background and so you see > it return. > > What does it '/usr/sbin/sshd' pause on when you run it inside strace? > I'm thinking it may be that its pausing because the system has run out > of entropy to give suitable random data for /dev/random. You could try > "stirring in" some entropy by doing something like moving the mouse a > lot, or doing a lot of disk IO on the host; the host kernel gathers > entropy from such events. > > Ideally though, you would have a hardware random number generator > (RNG) on your motherboard, which all(?) modern systems will have. > Ensure your host has support for this in the kernel (or loaded via > module). > > I'm not sure if the guest will source its /dev/random from the hosts / > dev/random or not. That's what i thought as well, guessing by the random bytes error. If fed files to /dev/random and did this until the size was over 3000. Then i checked: >> cat /proc/sys/kernel/random/entropy_avail 3126 I then tried to start sshd but it still failed complaining about the random bytes. I would have thought having more than 3000 random bytes would be enough to start the service. When i start the sshd daemon in debug mode and try to connect to it, that works but when i quit, the sshd quits as well but this may be due to the debug mode. Regards, Benedict |
From: Benedict V. <ben...@gm...> - 2008-06-05 16:09:47
|
<snip> I found an option "Hardware random number generator" in the UML config that sets CONFIG_UML_RANDOM. Together with rng-tools and a daemon program rngd, it allows injection of the hosts entropy into the guests /dev/random. Maybe this will solve the problem, i'll try it out. Regards, Benedict |
From: Jeff D. <jd...@ad...> - 2008-06-05 20:53:17
|
On Thu, Jun 05, 2008 at 06:08:20PM +0200, Benedict Verheyen wrote: > I found an option "Hardware random number generator" in the UML config > that sets CONFIG_UML_RANDOM. > Together with rng-tools and a daemon program rngd, it allows injection > of the hosts entropy into the guests /dev/random. > > Maybe this will solve the problem, i'll try it out. It should. BTW, there's a /dev/random patch in recent mainline which you'll need in order for this to work: 5d33e4d7fd9a52d2673e5c730eab81856e100a74 Jeff -- Work email - jdike at linux dot intel dot com |
From: Benedict V. <ben...@gm...> - 2008-06-06 08:20:54
|
Jeff Dike wrote: > On Thu, Jun 05, 2008 at 06:08:20PM +0200, Benedict Verheyen wrote: >> I found an option "Hardware random number generator" in the UML config >> that sets CONFIG_UML_RANDOM. >> Together with rng-tools and a daemon program rngd, it allows injection >> of the hosts entropy into the guests /dev/random. >> >> Maybe this will solve the problem, i'll try it out. > > It should. BTW, there's a /dev/random patch in recent > mainline which you'll need in order for this to work: > 5d33e4d7fd9a52d2673e5c730eab81856e100a74 > > Jeff Jeff, i googled for this patch and saw that it was commited in 2.6.26.rc2. Does that mean that i need to compile a new 2.6.26.rc2 kernel or a new 2.6.26.rc2 guest kernel or both ? Also, when i have compiled a new kernel, do i still need to install rng-tools to be able to run ssh again or won't that be necessary? I guess i can leave the CONFIG_UML_RANDOM set to yes without a problem. Regards, Benedict |
From: Benedict V. <ben...@gm...> - 2008-06-07 23:43:37
|
Benedict Verheyen schreef: > > Jeff, > > i googled for this patch and saw that it was commited in 2.6.26.rc2. > Does that mean that i need to compile a new 2.6.26.rc2 kernel or a new > 2.6.26.rc2 guest kernel or both ? > > Also, when i have compiled a new kernel, do i still need to install > rng-tools to be able to run ssh again or won't that be necessary? > I guess i can leave the CONFIG_UML_RANDOM set to yes without a problem. > > Regards, > Benedict I compiled a new guest kernel. I took the 2.6.25 baseline source tree and applied the 2.6.26-rc5 patch. With this kernel, ssh works again ! I could even turn off the rng tools and it still worked. Nice ! Only downside so far is that the skas 4 patch returned a couple of failed hunks. Understandably since it's a new version of the kernel :) Here are the result of a dry-run patch round: patching file arch/um/include/as-layout.h Hunk #1 FAILED at 23. 1 out of 1 hunk FAILED -- saving rejects to file arch/um/include/as-layout.h.rej patching file arch/um/include/kern_util.h patching file arch/um/include/os.h patching file arch/um/include/siginfo_segv.h patching file arch/um/include/skas/mm_id.h patching file arch/um/include/skas/skas.h patching file arch/um/include/skas_ptrace.h Hunk #1 FAILED at 1. Hunk #2 FAILED at 7. 2 out of 2 hunks FAILED -- saving rejects to file arch/um/include/skas_ptrace.h.rej patching file arch/um/include/sysdep-i386/ptrace.h patching file arch/um/include/sysdep-i386/ptrace_user.h Hunk #1 succeeded at 43 with fuzz 2. patching file arch/um/include/sysdep-i386/tls.h patching file arch/um/include/sysdep-x86_64/ptrace.h patching file arch/um/include/sysdep-x86_64/ptrace_user.h Hunk #1 succeeded at 74 with fuzz 2 (offset 2 lines). patching file arch/um/kernel/process.c patching file arch/um/kernel/ptrace.c patching file arch/um/kernel/reboot.c patching file arch/um/kernel/signal.c patching file arch/um/kernel/skas/clone.c patching file arch/um/kernel/skas/mmu.c patching file arch/um/kernel/skas/process.c patching file arch/um/kernel/skas/syscall.c patching file arch/um/kernel/syscall.c Hunk #2 succeeded at 131 (offset -17 lines). patching file arch/um/kernel/um_arch.c Hunk #1 succeeded at 286 (offset 2 lines). patching file arch/um/os-Linux/skas/mem.c patching file arch/um/os-Linux/skas/process.c patching file arch/um/os-Linux/start_up.c Hunk #2 FAILED at 26. Hunk #3 FAILED at 148. Hunk #4 FAILED at 191. Hunk #5 FAILED at 391. Hunk #6 FAILED at 403. Hunk #7 FAILED at 415. Hunk #8 succeeded at 434 (offset 9 lines). Hunk #9 FAILED at 444. Hunk #10 FAILED at 478. Hunk #11 succeeded at 500 (offset -1 lines). 8 out of 11 hunks FAILED -- saving rejects to file arch/um/os-Linux/start_up.c.rej patching file arch/um/os-Linux/sys-i386/registers.c Hunk #1 FAILED at 4. Hunk #2 FAILED at 78. Hunk #3 succeeded at 115 (offset 2 lines). 2 out of 3 hunks FAILED -- saving rejects to file arch/um/os-Linux/sys-i386/registers.c.rej patching file arch/um/os-Linux/sys-x86_64/registers.c patching file arch/um/sys-i386/ldt.c patching file arch/um/sys-i386/signal.c patching file arch/um/sys-i386/stub.S patching file arch/um/sys-i386/tls.c patching file arch/um/sys-x86_64/signal.c patching file arch/um/sys-x86_64/stub.S patching file arch/um/sys-x86_64/syscall_table.c patching file arch/um/sys-x86_64/syscalls.c patching file arch/x86/ia32/ia32_signal.c patching file arch/x86/ia32/ia32entry.S Hunk #1 succeeded at 377 (offset 4 lines). Hunk #2 succeeded at 732 (offset 4 lines). patching file arch/x86/kernel/entry_32.S Hunk #1 succeeded at 368 (offset -3 lines). patching file arch/x86/kernel/entry_64.S Hunk #3 succeeded at 429 (offset -2 lines). Hunk #4 succeeded at 486 (offset -2 lines). patching file arch/x86/kernel/ptrace.c Hunk #5 FAILED at 1253. Hunk #6 succeeded at 1377 (offset -76 lines). Hunk #7 succeeded at 1414 (offset -77 lines). Hunk #8 succeeded at 1466 (offset -77 lines). Hunk #9 succeeded at 1549 (offset -77 lines). Hunk #10 succeeded at 1578 (offset -77 lines). Hunk #11 succeeded at 1593 (offset -77 lines). 1 out of 11 hunks FAILED -- saving rejects to file arch/x86/kernel/ptrace.c.rej patching file arch/x86/kernel/signal_32.c Hunk #1 succeeded at 571 with fuzz 1 (offset -2 lines). Hunk #2 FAILED at 603. 1 out of 2 hunks FAILED -- saving rejects to file arch/x86/kernel/signal_32.c.rej patching file arch/x86/kernel/signal_64.c Hunk #1 succeeded at 405 (offset -2 lines). Hunk #2 succeeded at 436 (offset -1 lines). patching file arch/x86/kernel/sys_i386_32.c Hunk #1 succeeded at 21 with fuzz 2. Hunk #2 succeeded at 245 (offset -17 lines). patching file arch/x86/kernel/sys_x86_64.c Hunk #1 succeeded at 234 (offset -17 lines). patching file arch/x86/kernel/syscall_table_32.S patching file arch/x86/mm/fault.c patching file fs/proc/base.c Hunk #1 succeeded at 2380 (offset 101 lines). Hunk #2 succeeded at 2483 (offset 102 lines). patching file include/asm-generic/siginfo.h patching file include/asm-um/desc.h patching file include/asm-um/host_ldt-i386.h patching file include/asm-um/host_ldt-x86_64.h patching file include/asm-um/processor-i386.h patching file include/asm-um/ptrace-generic.h patching file include/asm-um/ptrace-i386.h patching file include/asm-um/ptrace-x86_64.h patching file include/asm-um/thread_info.h patching file include/asm-x86/Kbuild Hunk #1 succeeded at 22 (offset 1 line). patching file include/asm-x86/ia32.h patching file include/asm-x86/ptrace.h Hunk #2 succeeded at 55 with fuzz 1. Hunk #3 succeeded at 251 with fuzz 2 (offset 6 lines). patching file include/asm-x86/siginfo.h patching file include/asm-x86/thread_info_32.h Hunk #1 succeeded at 141 with fuzz 2 (offset -1 lines). Hunk #2 FAILED at 161. 1 out of 2 hunks FAILED -- saving rejects to file include/asm-x86/thread_info_32.h.rej patching file include/asm-x86/thread_info_64.h Hunk #1 FAILED at 125. Hunk #2 FAILED at 147. 2 out of 2 hunks FAILED -- saving rejects to file include/asm-x86/thread_info_64.h.rej patching file include/asm-x86/unistd_32.h patching file include/asm-x86/unistd_64.h patching file include/linux/init_task.h Hunk #1 succeeded at 176 (offset -17 lines). patching file include/linux/ptrace.h patching file include/linux/sched.h Hunk #1 succeeded at 64 (offset -1 lines). Hunk #2 succeeded at 1024 (offset 32 lines). Hunk #3 succeeded at 1154 (offset 32 lines). Hunk #4 succeeded at 1842 (offset 72 lines). patching file include/linux/signalfd.h patching file kernel/Makefile Hunk #1 FAILED at 9. 1 out of 1 hunk FAILED -- saving rejects to file kernel/Makefile.rej patching file kernel/exit.c Hunk #1 succeeded at 186 (offset 11 lines). patching file kernel/fork.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 2 out of 2 hunks ignored -- saving rejects to file kernel/fork.c.rej patching file kernel/ptrace.c Hunk #1 succeeded at 410 (offset -10 lines). Hunk #2 succeeded at 474 (offset 1 line). patching file kernel/signal.c Hunk #1 FAILED at 1785. Hunk #2 succeeded at 2077 (offset -32 lines). Hunk #3 succeeded at 2097 (offset -32 lines). 1 out of 3 hunks FAILED -- saving rejects to file kernel/signal.c.rej patching file kernel/vcpu.c patching file mm/Makefile Hunk #1 succeeded at 4 with fuzz 1. patching file mm/mmfs.c Regards, Benedict |
From: Laurent W. <l.w...@gm...> - 2008-06-08 09:25:19
|
2008/6/8 Benedict Verheyen <ben...@gm...>: > Benedict Verheyen schreef: >> >> Jeff, >> >> i googled for this patch and saw that it was commited in 2.6.26.rc2. >> Does that mean that i need to compile a new 2.6.26.rc2 kernel or a new >> 2.6.26.rc2 guest kernel or both ? >> >> Also, when i have compiled a new kernel, do i still need to install >> rng-tools to be able to run ssh again or won't that be necessary? >> I guess i can leave the CONFIG_UML_RANDOM set to yes without a problem. >> >> Regards, >> Benedict > > I compiled a new guest kernel. I took the 2.6.25 baseline source tree and > applied the 2.6.26-rc5 patch. > With this kernel, ssh works again ! > I could even turn off the rng tools and it still worked. Nice ! > > Only downside so far is that the skas 4 patch returned a couple of failed > hunks. Understandably since it's a new version of the kernel :) Hi Benedict, I've began to port the skas4 patch to 2.6-git. You can clone the repo here: git://gitorious.org/my-unofficial-linux-uml-tree/mainline.git You can also get the patch here: http://dl.kodros.fr/skas4_20080607.diff The only part that need to be done is PTRACE_SWITCH_MM case in arch/x86/kernel/ptrace.c. Help and comments are welcome. I'll try to finish the portage today, but that's unsure. Regards, Laurent. |
From: Laurent W. <l.w...@gm...> - 2008-06-08 10:16:10
|
2008/6/8 Laurent Wandrebeck <l.w...@gm...>: > 2008/6/8 Benedict Verheyen <ben...@gm...>: >> Benedict Verheyen schreef: >>> >>> Jeff, >>> >>> i googled for this patch and saw that it was commited in 2.6.26.rc2. >>> Does that mean that i need to compile a new 2.6.26.rc2 kernel or a new >>> 2.6.26.rc2 guest kernel or both ? >>> >>> Also, when i have compiled a new kernel, do i still need to install >>> rng-tools to be able to run ssh again or won't that be necessary? >>> I guess i can leave the CONFIG_UML_RANDOM set to yes without a problem. >>> >>> Regards, >>> Benedict >> >> I compiled a new guest kernel. I took the 2.6.25 baseline source tree and >> applied the 2.6.26-rc5 patch. >> With this kernel, ssh works again ! >> I could even turn off the rng tools and it still worked. Nice ! >> >> Only downside so far is that the skas 4 patch returned a couple of failed >> hunks. Understandably since it's a new version of the kernel :) > Hi Benedict, > I've began to port the skas4 patch to 2.6-git. > You can clone the repo here: > git://gitorious.org/my-unofficial-linux-uml-tree/mainline.git > You can also get the patch here: http://dl.kodros.fr/skas4_20080607.diff > The only part that need to be done is PTRACE_SWITCH_MM case in > arch/x86/kernel/ptrace.c. > Help and comments are welcome. > I'll try to finish the portage today, but that's unsure. > Regards, > Laurent. Hi again, I *think* I have finished to port skas4. you'll find updated git tree at the same place. Updated patch is here: http://dl.kodros.fr/skas4_20080608.diff (I'm a bit unsure it is correct - I'm new to git - You'd better clone the git tree). Unfortunately, I can't until monday test if it compiles, as Fedora 9 gcc is buggy and ICE while compiling the kernel - and up to now I've been unable to get to compile another gcc. Laurent. -- Archi. Nouveau-né de Lille Compagnon Archiviste Humaniste Fouet d'Harold de Chassepierre en surface. |
From: Laurent W. <l.w...@gm...> - 2008-06-08 13:57:55
|
2008/6/8 Laurent Wandrebeck <l.w...@gm...>: > 2008/6/8 Laurent Wandrebeck <l.w...@gm...>: >> 2008/6/8 Benedict Verheyen <ben...@gm...>: >>> Benedict Verheyen schreef: >>>> >>>> Jeff, >>>> >>>> i googled for this patch and saw that it was commited in 2.6.26.rc2. >>>> Does that mean that i need to compile a new 2.6.26.rc2 kernel or a new >>>> 2.6.26.rc2 guest kernel or both ? >>>> >>>> Also, when i have compiled a new kernel, do i still need to install >>>> rng-tools to be able to run ssh again or won't that be necessary? >>>> I guess i can leave the CONFIG_UML_RANDOM set to yes without a problem. >>>> >>>> Regards, >>>> Benedict >>> >>> I compiled a new guest kernel. I took the 2.6.25 baseline source tree and >>> applied the 2.6.26-rc5 patch. >>> With this kernel, ssh works again ! >>> I could even turn off the rng tools and it still worked. Nice ! >>> >>> Only downside so far is that the skas 4 patch returned a couple of failed >>> hunks. Understandably since it's a new version of the kernel :) >> Hi Benedict, >> I've began to port the skas4 patch to 2.6-git. >> You can clone the repo here: >> git://gitorious.org/my-unofficial-linux-uml-tree/mainline.git >> You can also get the patch here: http://dl.kodros.fr/skas4_20080607.diff >> The only part that need to be done is PTRACE_SWITCH_MM case in >> arch/x86/kernel/ptrace.c. >> Help and comments are welcome. >> I'll try to finish the portage today, but that's unsure. >> Regards, >> Laurent. > Hi again, > I *think* I have finished to port skas4. > you'll find updated git tree at the same place. > Updated patch is here: http://dl.kodros.fr/skas4_20080608.diff > (I'm a bit unsure it is correct - I'm new to git - You'd better clone > the git tree). > Unfortunately, I can't until monday test if it compiles, as Fedora 9 > gcc is buggy and ICE while compiling the kernel - and up to now I've > been unable to get to compile another gcc. > Laurent. Don't bother for now, it looks like the skas4 single patch was actually missing one. I'm right now fighting with git which does not want to push. I've installed virtualbox and Centos 5.1 i386, which gcc doesn't ICE, contrary to the fedora 9 one. Will keep you informed about my skas4 adventures ;) Laurent. |
From: Laurent W. <l.w...@gm...> - 2008-06-08 17:41:15
|
2008/6/8 Laurent Wandrebeck <l.w...@gm...>: > 2008/6/8 Laurent Wandrebeck <l.w...@gm...>: >> 2008/6/8 Laurent Wandrebeck <l.w...@gm...>: >>> 2008/6/8 Benedict Verheyen <ben...@gm...>: >>>> Benedict Verheyen schreef: >>>>> >>>>> Jeff, >>>>> >>>>> i googled for this patch and saw that it was commited in 2.6.26.rc2. >>>>> Does that mean that i need to compile a new 2.6.26.rc2 kernel or a new >>>>> 2.6.26.rc2 guest kernel or both ? >>>>> >>>>> Also, when i have compiled a new kernel, do i still need to install >>>>> rng-tools to be able to run ssh again or won't that be necessary? >>>>> I guess i can leave the CONFIG_UML_RANDOM set to yes without a problem. >>>>> >>>>> Regards, >>>>> Benedict >>>> >>>> I compiled a new guest kernel. I took the 2.6.25 baseline source tree and >>>> applied the 2.6.26-rc5 patch. >>>> With this kernel, ssh works again ! >>>> I could even turn off the rng tools and it still worked. Nice ! >>>> >>>> Only downside so far is that the skas 4 patch returned a couple of failed >>>> hunks. Understandably since it's a new version of the kernel :) >>> Hi Benedict, >>> I've began to port the skas4 patch to 2.6-git. >>> You can clone the repo here: >>> git://gitorious.org/my-unofficial-linux-uml-tree/mainline.git >>> You can also get the patch here: http://dl.kodros.fr/skas4_20080607.diff >>> The only part that need to be done is PTRACE_SWITCH_MM case in >>> arch/x86/kernel/ptrace.c. >>> Help and comments are welcome. >>> I'll try to finish the portage today, but that's unsure. >>> Regards, >>> Laurent. >> Hi again, >> I *think* I have finished to port skas4. >> you'll find updated git tree at the same place. >> Updated patch is here: http://dl.kodros.fr/skas4_20080608.diff >> (I'm a bit unsure it is correct - I'm new to git - You'd better clone >> the git tree). >> Unfortunately, I can't until monday test if it compiles, as Fedora 9 >> gcc is buggy and ICE while compiling the kernel - and up to now I've >> been unable to get to compile another gcc. >> Laurent. > Don't bother for now, it looks like the skas4 single patch was > actually missing one. > I'm right now fighting with git which does not want to push. > I've installed virtualbox and Centos 5.1 i386, which gcc doesn't ICE, > contrary to the fedora 9 one. > Will keep you informed about my skas4 adventures ;) > Laurent. Me again. One error left, unvcpu function is undefined, and I can't find anywhere where it has been (checked in 2.6.23,24,25, git) Looks like there is a little bug in skas4 ;) Jeff, I suppose you have that function somewhere ? Laurent. |
From: Laurent W. <l.w...@gm...> - 2008-06-09 08:08:15
|
2008/6/8 Laurent Wandrebeck <l.w...@gm...>: > 2008/6/8 Laurent Wandrebeck <l.w...@gm...>: >> 2008/6/8 Laurent Wandrebeck <l.w...@gm...>: >>> 2008/6/8 Laurent Wandrebeck <l.w...@gm...>: >>>> 2008/6/8 Benedict Verheyen <ben...@gm...>: >>>>> Benedict Verheyen schreef: >>>>>> >>>>>> Jeff, >>>>>> >>>>>> i googled for this patch and saw that it was commited in 2.6.26.rc2. >>>>>> Does that mean that i need to compile a new 2.6.26.rc2 kernel or a new >>>>>> 2.6.26.rc2 guest kernel or both ? >>>>>> >>>>>> Also, when i have compiled a new kernel, do i still need to install >>>>>> rng-tools to be able to run ssh again or won't that be necessary? >>>>>> I guess i can leave the CONFIG_UML_RANDOM set to yes without a problem. >>>>>> >>>>>> Regards, >>>>>> Benedict >>>>> >>>>> I compiled a new guest kernel. I took the 2.6.25 baseline source tree and >>>>> applied the 2.6.26-rc5 patch. >>>>> With this kernel, ssh works again ! >>>>> I could even turn off the rng tools and it still worked. Nice ! >>>>> >>>>> Only downside so far is that the skas 4 patch returned a couple of failed >>>>> hunks. Understandably since it's a new version of the kernel :) >>>> Hi Benedict, >>>> I've began to port the skas4 patch to 2.6-git. >>>> You can clone the repo here: >>>> git://gitorious.org/my-unofficial-linux-uml-tree/mainline.git >>>> You can also get the patch here: http://dl.kodros.fr/skas4_20080607.diff >>>> The only part that need to be done is PTRACE_SWITCH_MM case in >>>> arch/x86/kernel/ptrace.c. >>>> Help and comments are welcome. >>>> I'll try to finish the portage today, but that's unsure. >>>> Regards, >>>> Laurent. >>> Hi again, >>> I *think* I have finished to port skas4. >>> you'll find updated git tree at the same place. >>> Updated patch is here: http://dl.kodros.fr/skas4_20080608.diff >>> (I'm a bit unsure it is correct - I'm new to git - You'd better clone >>> the git tree). >>> Unfortunately, I can't until monday test if it compiles, as Fedora 9 >>> gcc is buggy and ICE while compiling the kernel - and up to now I've >>> been unable to get to compile another gcc. >>> Laurent. >> Don't bother for now, it looks like the skas4 single patch was >> actually missing one. >> I'm right now fighting with git which does not want to push. >> I've installed virtualbox and Centos 5.1 i386, which gcc doesn't ICE, >> contrary to the fedora 9 one. >> Will keep you informed about my skas4 adventures ;) >> Laurent. > Me again. > One error left, unvcpu function is undefined, and I can't find > anywhere where it has been (checked in 2.6.23,24,25, git) > Looks like there is a little bug in skas4 ;) > Jeff, I suppose you have that function somewhere ? > Laurent. OK, silly me. I've (at last) finished to port the beast. Compile tested on x86_64. you can git clone git://gitorious.org/my-unofficial-linux-uml-tree/mainline.git or git clone http://git.gitorious.org/my-unofficial-linux-uml-tree/mainline.git Laurent. |
From: Benedict V. <ben...@gm...> - 2008-06-09 22:34:48
|
Laurent Wandrebeck wrote: <snip> > OK, silly me. I've (at last) finished to port the beast. > Compile tested on x86_64. > you can git clone > git://gitorious.org/my-unofficial-linux-uml-tree/mainline.git or git > clone http://git.gitorious.org/my-unofficial-linux-uml-tree/mainline.git > Laurent. Hi, i first had to install git as i don't use it. I like Subversion more :) I will try to clone the repository and compile it. I will let you know the results of the jury :) Regards, Benedict |
From: Benedict V. <ben...@gm...> - 2008-06-11 23:06:37
|
Benedict Verheyen schreef: > Laurent Wandrebeck wrote: > <snip> >> OK, silly me. I've (at last) finished to port the beast. >> Compile tested on x86_64. >> you can git clone >> git://gitorious.org/my-unofficial-linux-uml-tree/mainline.git or git >> clone http://git.gitorious.org/my-unofficial-linux-uml-tree/mainline.git >> Laurent. > > Hi, > > i first had to install git as i don't use it. > I like Subversion more :) > > I will try to clone the repository and compile it. > I will let you know the results of the jury :) > > Regards, > Benedict I tried compiling (Debian 4.0) and it fails ... LD .tmp_vmlinux1 arch/um/kernel/built-in.o: In function `do_signal': (.text+0x1c65): undefined reference to `unvcpu' arch/um/kernel/built-in.o: In function `sys_vcpu': (.text+0x2170): undefined reference to `do_vcpu' arch/um/kernel/built-in.o: In function `handle_syscall': (.text+0x370e): undefined reference to `unvcpu' arch/um/os-Linux/built-in.o: In function `vcpu_userspace': (.text+0x5293): undefined reference to `fp_regs' arch/um/sys-i386/built-in.o: In function `copy_sc_from_user': signal.c:(.text+0x15e2): undefined reference to `fp_regs' arch/um/sys-i386/built-in.o: In function `copy_sc_to_user': signal.c:(.text+0x1765): undefined reference to `fp_regs' signal.c:(.text+0x177b): undefined reference to `fp_regs' signal.c:(.text+0x17d0): undefined reference to `fp_regs' kernel/built-in.o: In function `ptrace_request': (.text+0xca22): undefined reference to `do_switch' collect2: ld returned 1 exit status KSYM .tmp_kallsyms1.S nm: '.tmp_vmlinux1': No such file No valid symbol. make[1]: *** [.tmp_kallsyms1.S] Fout 1 make[1]: Map '/usr/src/testgit/mainline' wordt verlaten make: *** [debian/stamp-build-kernel] Fout 2 And then i quits the compilation. Any ideas? Regards, Benedict |
From: Laurent W. <l.w...@gm...> - 2008-06-13 13:50:28
|
2008/6/12 Benedict Verheyen <ben...@gm...>: > Benedict Verheyen schreef: >> Laurent Wandrebeck wrote: >> <snip> >>> OK, silly me. I've (at last) finished to port the beast. >>> Compile tested on x86_64. >>> you can git clone >>> git://gitorious.org/my-unofficial-linux-uml-tree/mainline.git or git >>> clone http://git.gitorious.org/my-unofficial-linux-uml-tree/mainline.git >>> Laurent. >> >> Hi, >> >> i first had to install git as i don't use it. >> I like Subversion more :) >> >> I will try to clone the repository and compile it. >> I will let you know the results of the jury :) >> >> Regards, >> Benedict > > > I tried compiling (Debian 4.0) and it fails > ... > LD .tmp_vmlinux1 > arch/um/kernel/built-in.o: In function `do_signal': > (.text+0x1c65): undefined reference to `unvcpu' > arch/um/kernel/built-in.o: In function `sys_vcpu': > (.text+0x2170): undefined reference to `do_vcpu' > arch/um/kernel/built-in.o: In function `handle_syscall': > (.text+0x370e): undefined reference to `unvcpu' > arch/um/os-Linux/built-in.o: In function `vcpu_userspace': > (.text+0x5293): undefined reference to `fp_regs' > arch/um/sys-i386/built-in.o: In function `copy_sc_from_user': > signal.c:(.text+0x15e2): undefined reference to `fp_regs' > arch/um/sys-i386/built-in.o: In function `copy_sc_to_user': > signal.c:(.text+0x1765): undefined reference to `fp_regs' > signal.c:(.text+0x177b): undefined reference to `fp_regs' > signal.c:(.text+0x17d0): undefined reference to `fp_regs' > kernel/built-in.o: In function `ptrace_request': > (.text+0xca22): undefined reference to `do_switch' > collect2: ld returned 1 exit status > KSYM .tmp_kallsyms1.S > nm: '.tmp_vmlinux1': No such file > No valid symbol. > make[1]: *** [.tmp_kallsyms1.S] Fout 1 > make[1]: Map '/usr/src/testgit/mainline' wordt verlaten > make: *** [debian/stamp-build-kernel] Fout 2 > > And then i quits the compilation. > Any ideas? Yes, I have two repos with on going port to 2.6.26, and messed up with them. I pushed the wrong one on the master. Will fix it up and let you know. Regards, Laurent. |
From: Laurent W. <l.w...@gm...> - 2008-06-16 07:54:09
|
Hi Benedict, all, I've solved the problem, and rebased on a newer linus tree (a bit after rc6). git clone git://gitorious.org/low-unofficial-linux-uml-hacking-tree/mainline.git I've deleted the previous repo which was becoming messy. Hope that one will last longer. Compile tested (on i386), and started (no time to do much testing up to now). Let me know how it goes. Regards, Laurent. |
From: Laurent W. <l.w...@gm...> - 2008-06-16 11:03:16
|
2008/6/16 Laurent Wandrebeck <l.w...@gm...>: > Hi Benedict, all, > > I've solved the problem, and rebased on a newer linus tree (a bit > after rc6). git clone > git://gitorious.org/low-unofficial-linux-uml-hacking-tree/mainline.git > I've deleted the previous repo which was becoming messy. Hope that one > will last longer. > Compile tested (on i386), and started (no time to do much testing up to now). > Let me know how it goes. > Regards, > Laurent. You can also get the patch here: http://dl.kodros.fr/skas4_patch_7775c9753b94fe429dc4323360d6502c95e0dd6e_to_5c625f340a7acb7ef73a0d36c68ccec82dec75f6.diff Laurent. |
From: Benedict V. <ben...@gm...> - 2008-06-16 11:48:58
|
Laurent Wandrebeck wrote: > 2008/6/16 Laurent Wandrebeck <l.w...@gm...>: >> Hi Benedict, all, >> >> I've solved the problem, and rebased on a newer linus tree (a bit >> after rc6). git clone >> git://gitorious.org/low-unofficial-linux-uml-hacking-tree/mainline.git >> I've deleted the previous repo which was becoming messy. Hope that one >> will last longer. >> Compile tested (on i386), and started (no time to do much testing up to now). >> Let me know how it goes. >> Regards, >> Laurent. > You can also get the patch here: > http://dl.kodros.fr/skas4_patch_7775c9753b94fe429dc4323360d6502c95e0dd6e_to_5c625f340a7acb7ef73a0d36c68ccec82dec75f6.diff > Laurent. Laurent, i downloaded patch 2.6.26-rc6 and applied it to the patch baseline as specified on the kernel site. This works but when i applied the skas 4 patch, 2 hunks failed to apply: ... Hunk #7 succeeded at 497 (offset -7 lines). patching file arch/um/os-Linux/sys-i386/registers.c Hunk #1 FAILED at 4. Hunk #2 FAILED at 79. 2 out of 3 hunks FAILED -- saving rejects to file arch/um/os-Linux/sys-i386/registers.c.rej De rejects file contents: *************** *** 4,15 **** * Licensed under the GPL */ #include <errno.h> #include <sys/ptrace.h> - #include <sys/user.h> #include "kern_constants.h" #include "longjmp.h" #include "user.h" #include "sysdep/ptrace_user.h" int save_fp_registers(int pid, unsigned long *fp_regs) --- 4,20 ---- * Licensed under the GPL */ + #include <stdio.h> + #include <stdlib.h> #include <errno.h> + #include <asm/ldt.h> + #include <sys/syscall.h> + #include <unistd.h> #include <sys/ptrace.h> #include "kern_constants.h" #include "longjmp.h" #include "user.h" + #include "skas.h" #include "sysdep/ptrace_user.h" int save_fp_registers(int pid, unsigned long *fp_regs) *************** int put_fp_registers(int pid, unsigned long *regs) *** 74,85 **** return restore_fp_registers(pid, regs); } void arch_init_registers(int pid) { - struct user_fpxregs_struct fpx_regs; - int err; - err = ptrace(PTRACE_GETFPXREGS, pid, 0, &fpx_regs); if (!err) return; --- 79,110 ---- return restore_fp_registers(pid, regs); } + extern int host_gdt_entry_tls_min; + + #define GDT_ENTRY_TLS_ENTRIES 3 + #define GDT_ENTRY_TLS_MIN 6 + #define GDT_ENTRY_TLS_MAX (GDT_ENTRY_TLS_MIN + GDT_ENTRY_TLS_ENTRIES - 1) + + struct user_desc tls[GDT_ENTRY_TLS_ENTRIES]; + + unsigned long fp_regs[FP_SIZE]; + void arch_init_registers(int pid) { + struct user_desc *entry; + int err, i; + for (i = 0; i < GDT_ENTRY_TLS_ENTRIES; i++) { + entry = &tls[i]; + entry->entry_number = i + GDT_ENTRY_TLS_MIN; + err = get_thread_area(entry); + if (err) { + perror("get_thread_area"); + exit(1); + } + } + + err = ptrace(PTRACE_GETFPXREGS, pid, 0, fp_regs); if (!err) return; Regards, Benedict |
From: Laurent W. <l.w...@gm...> - 2008-06-16 12:30:27
|
2008/6/16 Benedict Verheyen <ben...@gm...>: > > Laurent, > > i downloaded patch 2.6.26-rc6 and applied it to the patch baseline as > specified on the kernel site. This works but when i applied the skas 4 > patch, 2 hunks failed to apply: <snip> Ok, I checked git log, and a couple uml changes sneaked in after 2.6.26-rc6. Commits f1ef9167ca4494a8c6d71d0031c73e9c8841eadd and 14c8a77e1bbd693446dad297d2ae2dd22f187e4f. Either try http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.26-rc6-git3.bz2 or easier, git clone my repo. Thx for testing. Laurent. |
From: Benedict V. <ben...@gm...> - 2008-06-17 12:05:59
|
Laurent Wandrebeck wrote: > Ok, I checked git log, and a couple uml changes sneaked in after 2.6.26-rc6. > Commits f1ef9167ca4494a8c6d71d0031c73e9c8841eadd and > 14c8a77e1bbd693446dad297d2ae2dd22f187e4f. > Either try http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.26-rc6-git3.bz2 > or easier, git clone my repo. > Thx for testing. > Laurent. Laurent, i tried the git tree and that indeed seems to work. The skas 4 mode is working, thanks ! However, i'm back to where i started as ssh isn't working, with or without the rngd tool. Hardware random option is set in the kernke: CONFIG_UML_RANDOM=y Regards, Benedict |
From: Laurent W. <l.w...@gm...> - 2008-06-17 12:33:18
|
2008/6/17 Benedict Verheyen <ben...@gm...>: > Laurent Wandrebeck wrote: >> Ok, I checked git log, and a couple uml changes sneaked in after 2.6.26-rc6. >> Commits f1ef9167ca4494a8c6d71d0031c73e9c8841eadd and >> 14c8a77e1bbd693446dad297d2ae2dd22f187e4f. >> Either try http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.26-rc6-git3.bz2 >> or easier, git clone my repo. >> Thx for testing. >> Laurent. > > Laurent, > > i tried the git tree and that indeed seems to work. > The skas 4 mode is working, thanks ! Thx for testing. Glad it works :) > > However, i'm back to where i started as ssh isn't working, with or > without the rngd tool. > Hardware random option is set in the kernke: CONFIG_UML_RANDOM=y Hmmmm, will take a look tonight at what happened to random fixes by Jeff. Regards, Laurent. |
From: Laurent W. <l.w...@gm...> - 2008-06-18 07:51:41
|
2008/6/17 Laurent Wandrebeck <l.w...@gm...>: >> >> However, i'm back to where i started as ssh isn't working, with or >> without the rngd tool. >> Hardware random option is set in the kernke: CONFIG_UML_RANDOM=y > Hmmmm, will take a look tonight at what happened to random fixes by Jeff. > Regards, > Laurent Random patches are still in place. I'm wondering why this does not work... Jeff, any idea ? Laurent. |
From: Jeff D. <jd...@ad...> - 2008-06-18 16:57:36
|
On Wed, Jun 18, 2008 at 09:51:38AM +0200, Laurent Wandrebeck wrote: > Random patches are still in place. I'm wondering why this does not work... > Jeff, any idea ? Is it dumping messages about not being able to get enough entropy? If you strace UML on the host, do you see it trying to get entropy from the host's /dev/random? Jeff -- Work email - jdike at linux dot intel dot com |
From: Benedict V. <ben...@gm...> - 2008-06-20 09:10:03
|
Jeff Dike wrote: > On Wed, Jun 18, 2008 at 09:51:38AM +0200, Laurent Wandrebeck wrote: >> Random patches are still in place. I'm wondering why this does not work... >> Jeff, any idea ? > > Is it dumping messages about not being able to get enough entropy? > > If you strace UML on the host, do you see it trying to get entropy > from the host's /dev/random? > > Jeff > I started the rngd daemon on the uml with kernel 2.6.26rc6 but sshd failed again. This is what the logs showed: Jun 20 10:10:14 rngd[2874]: rngd 2-unofficial-mt.10 starting up... Jun 20 10:11:13 rngd[2874]: entropy source exhausted! Jun 20 10:11:13 rngd[2874]: stats: bits received from HRNG source: 64 Jun 20 10:11:13 rngd[2874]: stats: bits sent to kernel pool: 0 Jun 20 10:11:13 rngd[2874]: stats: entropy added to kernel pool: 0 Jun 20 10:11:13 rngd[2874]: stats: FIPS 140-2 successes: 0 Jun 20 10:11:13 rngd[2874]: stats: FIPS 140-2 failures: 0 Jun 20 10:11:13 rngd[2874]: stats: FIPS 140-2(2001-10-10) Monobit: 0 Jun 20 10:11:13 rngd[2874]: stats: FIPS 140-2(2001-10-10) Poker: 0 Jun 20 10:11:13 rngd[2874]: stats: FIPS 140-2(2001-10-10) Runs: 0 Jun 20 10:11:13 rngd[2874]: stats: FIPS 140-2(2001-10-10) Long run: 0 Jun 20 10:11:13 rngd[2874]: stats: FIPS 140-2(2001-10-10) Continuous run: 0 Jun 20 10:11:13 rngd[2874]: stats: HRNG source speed: (min=0.000; avg=0.000; max=0.000)bits/s Jun 20 10:11:13 rngd[2874]: stats: FIPS tests speed: (min=0.000; avg=0.000; max=0.000)bits/s Jun 20 10:11:13 rngd[2874]: stats: Lowest ready-buffers level: 2 Jun 20 10:11:13 rngd[2874]: stats: Entropy starvations: 0 Jun 20 10:11:13 rngd[2874]: stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us Jun 20 10:11:13 rngd[2874]: Exiting... I tried again with kernel 2.6.26-rc5 (without skas4 compiled in) and with this kernel, ssh works. So it seems like some things changed between rc5 and rc6. Regards, Benedict |
From: Benedict V. <ben...@gm...> - 2008-06-25 07:51:46
|
Benedict Verheyen wrote: > Jeff Dike wrote: >> On Wed, Jun 18, 2008 at 09:51:38AM +0200, Laurent Wandrebeck wrote: >>> Random patches are still in place. I'm wondering why this does not work... >>> Jeff, any idea ? >> Is it dumping messages about not being able to get enough entropy? >> >> If you strace UML on the host, do you see it trying to get entropy >> from the host's /dev/random? >> >> Jeff I tried to strace the UML on the host but the stracing suddenly crashes and dumps me back to the prompt, so i'm not able to get more info this way. Regards, Benedict |