### Sessione del log avviata a ven dic 3 00:26:47 2004 ### [23:49:13] will I need to do "echo 1 > /proc/sysemu" on startup [23:49:15] or is that default? [23:49:54] No, it is default [23:50:09] very nice [23:50:13] thanks [23:50:55] You can use the "nosysemu" param to turn it off [23:51:01] Or echo 0 > /proc/sysemu [23:51:23] it seems to work well for me. [23:51:26] The second is more useful for developers, the first would have helped with the SKAS-v5 problem [23:51:55] with the exception of two lockups from the bridge brctl bug, I havent really had any problems [23:51:57] I.e., knowing that bug, the 2.4UML would have booted with nosysemu.... [23:52:00] except that [23:52:03] ahh [23:52:05] :] [23:52:09] nosysemu is not added to 2.4 code [23:52:12] :-( [23:52:16] k [23:52:21] I've added it to 2.6 [23:52:26] But not yet backported to 2.4 [23:52:26] you guys are doing a great job. [23:52:33] Thanks, KRandomHacker [23:52:36] I'm holding off on doing a 2.6.10 guest [23:52:38] for a bit [23:52:56] just want it to settle down a bit. [23:53:08] Yes, and until 2.6.10 [23:53:16] is out, it's just for developers [23:53:21] :} [23:53:23] or people wanting to test [23:53:32] (which is never a bad idea). [23:53:37] yeah, i've got 2.6.7 guests [23:53:45] but I havent applied the syscal stuff to it. [23:53:48] thats on my list. [23:54:09] "syscal" means "sysemu" or the security fixes? [23:54:10] is there a good 2.6.9 guest that you would recommend? [23:54:17] security fixes [23:54:25] I'm running the umls in chroot [23:54:29] Well, 2.6.9 vanilla is perfectly stable [23:54:30] with very little inside [23:54:36] cool, no zombies? [23:54:50] KRandomHacker: there are zombies, [23:54:53] yes [23:55:06] sigcont, sigkill is the workaround. [23:55:11] correct that as "perfectly stable on hosts before 2.6.9" [23:55:17] :} [23:55:19] 2.6.9-bb fixes those problems [23:55:38] cool [23:55:57] I'm now going to announce 2.6.9-bb4, which includes the security fixes and various other stuff (only for stability) [23:56:07] no zombies? [23:56:12] (bb3 fixed that?) [23:56:33] No zombies, exact. bb3 had those fixes, but notice, however, that the security fixes are invasive. In fact, they were causing instabilities [23:56:41] yes [23:56:43] But bb4 should contain the fix for them [23:56:49] nice [23:57:05] (At least, it fixes all known issues) [23:57:12] Not sure if new ones will come up. [23:57:35] If you're getting problems, take a 2.6.9 vanilla on a pre 2.6.9 host. [23:57:41] thats always the case with software [23:57:47] About the security issues: [23:57:53] so 2.6.9 vanilla would be great, as I'm running 2.6.7 [23:57:56] yes [23:57:57] exact [23:58:05] re: security [23:58:07] ? [23:59:10] apart security. The "security problems" can allow one hacker, which has got local access to inside the UML (as normal user), to escape from the "UML jail", i.e. to get access to the host, as the user running UML. That does not mean he escapes from the chroot [23:59:29] :} [23:59:35] yes, I am not as worried [23:59:39] (except if you are running UML as root, which I think you aren't doing, because root can always exit from chroots [23:59:46] Ok. [23:59:48] There is not much within the chroot. [23:59:59] yes, and running as the individual user [00:00:18] I'll make this clear on my page - the word "security issues" is a bit unclear. [00:00:28] It raises eyebrows [00:00:34] lol [00:01:34] which it should do in general... [00:01:46] :} [00:02:20] however with UML inside a proper chroot, it's as you said, i.e. not a big issue. [00:02:27] yeah [00:02:46] at some point, I would like to learn the uml internals [00:02:57] if you were to offer advise on "visualizing" how uml works [00:03:00] any ideas? [00:03:09] its basically one giant wrapper for syscals? [00:03:20] Subscribe to uml-devel and follow the discussions, basically [00:03:25] yeah [00:03:27] sounds good [00:03:28] KRandomHacker: basically, like that [00:03:37] like, ? giant wrapper? [00:03:46] do you use strace / know the ptrace(2) API? [00:03:52] I use strace [00:03:59] i will have to learn ptrace [00:04:13] Well, strace uses ptrace(2) to audit what syscalls a process is doing. [00:04:35] provides a means by which a parent process may [00:04:43] observe and control the execution of another process [00:04:45] yeah [00:04:47] UML uses ptrace() to audit what syscalls a process is doing *AND* avoid that they are executed on the host *AND* execute them by itself. [00:05:00] cool [00:05:09] *AND* sends the return value to the process, obviously [00:05:14] so when ptrace was broken at the kernel level [00:05:16] it was a big thing [00:05:26] ptrace was "broken" [00:05:30] lol [00:05:35] This is the core behaviour of UML - the rest is details. [00:05:41] :} [00:05:41] when? [00:05:48] not sure who [00:05:57] but someone rewrote internals of ptrace or something [00:06:04] and the results trickle down [00:06:08] When was ptrace broken, I mean? So much time ago? [00:06:15] this was pretty recent [00:06:18] Or just now in 2.6.9? [00:06:23] That is not a rewrite [00:06:27] yeah, I'd say 2.6.9 [00:06:32] it was a minor issue? [00:06:41] Ok, minor issue, and major bugs. [00:06:58] :} [00:07:16] There is one little change which is a bugfix and which I had to backport to SKAS-v7 for 2.6.7 [00:07:20] because it was needed [00:07:28] yes [00:07:28] and a big change which broke things all over [00:07:39] yes [00:07:55] The big change is what makes you see the zombie on the host on 2.6.9 host [00:08:07] that is the one I was refering to a minute ago [00:08:11] But that was accidental... UML was using something "particular" [00:08:17] in the api [00:08:23] an older call or something? [00:08:42] so the cleanup will occur in uml, not in main kernel? [00:09:04] The real problem (no.2) is that this change has caused some host bugs... we're going to report them. [00:09:17] Apart the first issue, UML was using SIGKILL instead of PTRACE_KILL. [00:09:25] You can SIGKILL normally a process [00:09:48] but now, you cannot kill with SIGKILL a ptrace child - only it's "ptracer" can. [00:09:57] fork() wait() usual loop [00:10:06] And even he must use PTRACE_KILL, not SIGKILL [00:10:09] only parent? [00:10:27] Only "ptrace parent", which means the process ptracing it [00:10:39] thats very specific [00:10:44] it ensures tight operation [00:11:01] overkill? [00:11:42] Not sure, it may make sense, just it happens to break UML. The problem is also that UML runs more processes/threads, and only one of them [00:11:50] ptraces the child [00:11:54] in TT mode [00:11:59] so it is really busy most of the time [00:12:06] lots of context switches [00:12:08] = slow [00:12:10] ? [00:12:18] so, using PTRACE_KILL for that is tricky. [00:12:21] KRandomHacker: [00:12:22] yes [00:12:24] Not exactly. [00:12:40] it only traces when it is notified? [00:12:51] ahh, I can see I need to follow the mailing list [00:12:53] :] [00:12:54] KRandomHacker: Yes, that's point one. [00:12:55] will do [00:13:05] I can "visualize" this [00:13:12] But also, the context switches are not that much heavy. [00:13:20] good [00:13:22] SKAS is faster, but has heavier context switches. [00:13:33] more is saved on the stack [00:13:58] No, that's not a stack problem. In a context switch you also flush paging information. TT tries to minimize the time for context switches, by [00:14:20] avoid the flush of "paging information cache" (technically called TLBs) [00:14:28] yeah [00:14:34] tlb and dirty bits [00:14:43] But to do that, it loses more time sending signals to itself. [00:14:44] dont upset the juggler [00:14:48] ? [00:14:56] I'm not native English [00:14:56] the virtual machine is the juggler [00:15:05] throw balls up in the air [00:15:12] and keep them in the air all the time [00:15:14] juggler [00:15:18] Ah, ok... t [00:15:21] the vm has to move pages in and out. [00:15:31] KRandomHacker: not, luckily [00:15:56] There is a set of paging info for one process, one set of paging info for another one [00:16:04] The TLB caches them for the current process [00:16:07] tt has an algorithm for aging the pages, thats how it minizes time [00:16:19] yeah [00:16:28] and each time the ptrace does the wait [00:16:34] you have to bring in that process's pages [00:16:39] ack! [00:16:42] But when doing a memory switch, you have to flush the TLB cache [00:16:48] Not ack [00:16:50] it gets better! [00:16:59] not ack? [00:17:04] TT mode avoids a lot of memory switches [00:17:20] this is good [00:17:23] Because the current process and the kernel share the memory space [00:17:51] So, when you do a syscall, UML sends a signal to itself [00:18:03] and the signal handler handles the signal and executes the syscall [00:18:20] makes sense [00:18:26] But, astonishingly, this is bad for performance [00:19:01] Sending signals to itself is slower than how much it would take to do the memory switches [00:19:09] So SKAS mode is faster than TT [00:19:11] yes [00:19:18] whew! [00:19:58] GO to Jeff's diary [00:20:00] On: [00:20:17] http://user-mode-linux.sourceforge.net/diary.html [00:20:31] (The link to it is on the left bar) [00:20:49] I've read it before [00:21:01] you guys are quite clever [00:21:04] :] [00:21:10] Go to 25 Aug 2002 [00:21:30] k [00:21:32] And you'll see Jeff explaining that SKAS is faster than TT [00:21:33] : [00:21:49] "It's being done this way because of Ingo's revelation on LKML that context switches are much faster than signal deliveries. " [00:22:06] wow [00:22:08] Which is like when I said "Sending signals to itself is slower than how much it would take to do the memory switches" [00:22:13] I would think a signal would be pretty fast [00:22:24] Or better, what I said is from that sentence [00:22:31] KRandomHacker: I too [00:22:33] Jeff too [00:22:37] before that [00:22:39] I guess there is alot of structure involved with signals [00:23:02] To handle a signal, [00:23:13] the handler must not interfere with the process being interrupted [00:23:21] so all registers and so on must be saved [00:23:23] yes [00:23:40] wich involves a flush? [00:24:06] Not a memory flush, but saving the registers. Jeff said this me yesterday that in his opionion it's costly, [00:24:12] but I'm not so much sure [00:24:33] depends, I'd be interested to see if x86_64 is faster at this. [00:24:37] even because signal delivery in the kernel is much more complicate than you would expect [00:24:48] KRandomHacker: why? [00:24:55] any idea / suggestion? [00:24:57] more space to fill and spill? [00:25:10] the compiler can optimize ? [00:25:18] my understanding might not be complete [00:25:44] The context to save is about some kbytes... there are more registers to save on x86_64, but even more registers to optimize that [00:25:45] I'm just trying to visualize the pipeline, and everything marching thru. [00:25:55] yeah [00:26:10] It's a problem if I save this conversation? [00:26:16] no, not at all [00:26:28] Ok, so it will serve for other learners! [00:26:33] :} [00:26:37] glad I could help [00:26:39] lol [00:27:12] Today is the second time.... half an hour ago I was talking about SKAS [00:27:29] :} [00:27:31] but I really need to also put the announce on the site about bb4 and so on [00:27:38] in my opinion, this is a good thing. [00:27:41] you see, I uploaded it [00:27:46] but not put the announce [00:27:57] no, I wouldnt [00:28:23] What wouldn't you do? I hadn't put the announce waiting for caker to test it [00:28:36] yes [00:28:47] I would not announce for you [00:28:56] wait [00:29:00] sorry, its been a long day. [00:29:02] :} [00:29:39] Because he was using Mysql inside UML and MySQL used something which broke with security fixes in older patches. He sent the ack. [00:29:47] Ok, understanding the long day... [00:29:51] yes, he was getting zombies [00:30:03] also, ntpl is a problem for him [00:30:09] I was not understanding much of your opinion about releasing [00:30:15] yes [00:30:17] NPTL is a more difficult issue [00:30:25] yes [00:30:34] But you can get along by disabling it in the guest [00:30:39] I hope to fix this soon [00:30:47] it is "on the list" [00:31:08] Yes, exactly. But I still have to report one Linux bug and one glibc bug which were both biting UML. [00:31:15] We have workarounded the glibc one [00:31:22] :} [00:31:22] But cannot workaround the kernel one [00:31:37] its a work in progress [00:31:39] Which is the "number 2" of the above discussion about ptrace change. [00:31:47] yes [00:31:57] If you see unkillable threads in 'D' state on 2.6.9 host [00:32:02] That is "number 2" [00:32:07] :] [00:32:14] no kernel oops, just D state? [00:32:40] Exactly [00:32:48] fun [00:32:49] On the host, I say [00:32:56] And this is caused by the ptrace fix [00:33:03] because the fixer was not careful [00:33:11] ahh [00:33:39] However, don't go talking about it now. [00:33:55] yes [00:33:57] no prob [00:34:10] its all one big queue isnt it. [00:34:12] We don't want anyone to create 'D' processes all over the world. [00:34:20] :}