- 07 Nov, 2004 40 commits
-
-
Jeff Dike authored
Remove an unnecessary and even dangerous check in is_syscall() The bug was inserted by my patch syscall-security-1. Signed-off-by:
Bodo Stroesser <bstroesser@fujitsu-siemens.com> Signed-off-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Jeff Dike authored
The patch syscall-security-3 is wrong (provided by me, sorry). I missed, that singlestepping_skas() used to reset PT_DTRACE. This was handled differently in tt and skas. With syscall-security-3 applied, a process in SKAS that singlestepped once continues to singlestep until the next systemcall occurs, even if it is resumed with PTRACE_CONT or PTRACE_SYSCALL. This fix unifies the usage of PT_DTRACE in TT and SKAS. PT_DTRACE now is set by ptrace(PTRACE_SINGLESTEP,...) and reset by singlestepping() and it is evaluated in kern_do_signal(). Signed-off-by:
-
Jeff Dike authored
From: Bodo Stroesser - Make singlestepping() generic. Signed-off-by:
-
Jeff Dike authored
From: Bodo Stroesser - Make singlestep_syscall generic rather than being restricted to tt mode. Signed-off-by:
-
Jeff Dike authored
From: Bodo Stroesser - Change is_syscall to check for sysenter and also that we are actually executing a system call. Signed-off-by:
-
Jeff Dike authored
This first patch lays some groundwork needed by the others. From: Bodo Stroesser - Change the interface to handle_signal so that it doesn't take the system call return value as an argument and eliminate its return value. kern_do_signal also now doesn't return immediately after determining that there is no signal to deliver. Signed-off-by:
-
Jeff Dike authored
The comment should be self-explanatory. This works around a pile of nasty-looking build output. Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
Add missing newline in help string for "nosysemu" param. Run ./vmlinux --help before and after to see the difference. Trivial - must go in. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it> Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
We have re-added the "linux" target which just creates a hardlink to vmlinux. It was noted (sorry for forgetting who said this) that "make ARCH=um" will leave an old "linux" file, since the target is not listed in .PHONY. Using a symlink, instead of an hard link, was suggested because the hard link does not get updated with make vmlinux. But mv linux $destpath (the most meaningful installation command) is broken, so I instead added linux to .PHONY. Obviously, linux will not be rebuilt on "make vmlinux ARCH=um", but this makes sense (if people use the new way, don't use old tricks). Anyway, we remove "linux" in any case. Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
To avoid silly messages coming out during debugging or when things break, after that we've read in CATCH_EINTR that errno == EINTR, clear it, so that it's 0 in next iteration. Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
From: Jeff Dike <jdike@addtoit.com> This is a large set of small fixes and other changes: Fixed a file descriptor leak in the network driver when changing an IP address. The port channel now sets SO_REUSEADDR. Added some initcall and exitcall definitions to arch/um/include/init.h so that they can be used from userspace code. Fixed the error handling in run_helper. Added the log() facility to mem_user.c. Fixed a problem with recursive segfaults not being handled correctly. tty_log_fd and umid aren't added to the command line any more. Fixed some prints. Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
From: Jeff Dike <jdike@addtoit.com> Paolo 'Blaisorblade' Giarrusso<blaisorblade_spam@yahoo.it> As Jeff Dike noted, even if SYSEMU was originally written for use in SKAS mode, there is nothing SKAS specific in SYSEMU, so use it for TT mode, too. SYSEMU simply allows one to ptrace(PTRACE_SYSEMU) a process, that will stop on the syscall entry path like with PTRACE_SYSCALL, but with the difference that it makes sure that the syscall execution is totally skipped and that the child will see the return value set by the ptracer when the child was stopped. We even hope that the SYSEMU patch can be merged in mainline sooner than SKAS. Signed-off-by: -
Paolo \'Blaisorblade\' Giarrusso authored
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it> Bodo Stroesser <bodo.stroesser@fujitsu-siemens.com> While testing the host ptrace(2) features, we modify the stack frame of a test child which is doing a syscall (namely getpid). Either we override the syscall number or the return value, which become the parent's pid, or we don't, and the return value is the child's pid. Actually, we only compared the return value with the child's pid, so we did not notice a bug where the return value happened to be different from both. So I added a stricter test here. Signed-off-by: -
Paolo \'Blaisorblade\' Giarrusso authored
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it> Bodo Stroesser <bodo.stroesser@fujitsu-siemens.com> Jeff Dike <jdike@addtoit.com> Currently, the test for the SYSEMU support on the host is completely wrong, as Bodo noticed. We should change the syscall result (inserting the host pid) and check if it is received correctly by the guest. What we actually do, without this patch, is to overwrite the syscall number. This went unnoticed because we only check that the getpid() syscall from the child does not return its pid. We don't check that it returns the correct value. Also, override the result portably, using the PT_SYSCALL_RET_OFFSET macro which abstract away the host stack frame layout (took from Jeff Dike code). Signed-off-by: -
Paolo \'Blaisorblade\' Giarrusso authored
I'm reverting the compile-time fixes to replace them with a bigger change, which also happens to fix the compilation problem. The change is in next patches. Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
This patch makes UML use print_symbol() when dumping the stack. It is not yet complete (the i386 version uses the frame pointers to walk the stack, for instance), but should be at least enough. Also, it uses bust_spinlock() when dumping errors to help them reach the console. This appears not to be enough - however I analyzed the UML console code, and it seems that UML console don't get flushed *at all* when exiting. Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it> Jeff Dike <jdike@addtoit.com> Since local_irq_save() and local_irq_disable() should match (apart from saving the flags), get/set_signals must match [un]block_signals, i.e. change_signals; since get/set_signals don't enable/disable SIGPROF (and this behaviour is safe as explained in the comment the patch adds, since the profiling code does not interact with the kernel code), not even change_signals must toggle it. Signed-off-by: -
Paolo \'Blaisorblade\' Giarrusso authored
Make generic_console_write() catch the EINTR error code and retry doing the calls accordingly. Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
From: Gerd Knorr <kraxel@bytesex.org>, and me, Paolo Giarrusso This is a rewrite of the mconsole_proc function. The old code had the problem that the kernel crashed after calling "uml_mconsole proc <somefile>" a few times. I havn't tracked what exactly causes the problem, I guess trying to access the procfs without actually mounting it somewhere causes some corruption of kernel data structures. The new code simply openes /proc/<file> via sys_open(). That simplifies the function alot. It also doesn't crash any more ;) Also, from Paolo Giarrusso: When printing the content of a file through the "proc" command, make it begin on his own line. PROBLEMS: Drawback is that it only works when procfs is actually mounted below /proc. And within UML, often this is false, because when building honeypots we mount HPPFS under /proc to avoid the hacker recognizing he's attacking a UML instance. One suggestion I've received to fix the later issue was to mount the procfs within a kernel thread with a private namespace, but I havn't tried that so far. Instead, we'd like to fix the actual code of the mconsole_proc function. From "Anthony Brock" Anthony_Brock (at) ous (dot) edu comes a comment, suggesting where the bug lays (as noted in the source): removing part of the code (it seems the symlink lookup) there are no more crashes. Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it> Jeff Dike <jdike@addtoit.com> Currently there are two distinct definitions of current_thread_info (which has its usual meaning) and current_thread (which is the same thing); so define the second to be the first (for UML compatibility). If needed, a search & replace \<current_thread\> to current_thread_info and removing current_thread can be done (that would be a separate, low-priority patch, however). Also, since the involved headers include each other very deeply, we must fix somehow this recursive inclusion or things won't compile. Jeff Dike noted that this can be done easily, since the nasty chain of includes can be broken by eliminating an include of current.h, and implemented this. Signed-off-by: -
Paolo \'Blaisorblade\' Giarrusso authored
Avoid including some unused headers. Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
Rename headers with the same name to avoid specifying the complete path for including them. Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
Since arch/um/kernel/tt/unmap_fin.o is linked statically, it could contain some symbols also contained in the rest of vmlinux; on some systems, this actually happens (due to some glibc differences). Since that file *must* be linked statically and then relinked (its code must remap the whole .text area except the section it is contained in during UML startup), we cannot change this. So, we use objcopy to turn all symbols into local ones except for switcheroo(), which is the only function actually defined in the source (the other ones are brought in during linking). This shouldn't hurt other systems, while improving the behaviour on affected ones (there is still another issue I'm trying to fix). And it is logically always needed (i.e., without this UML has just happened to work until now). Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
Correct the entry_exit parameter for syscall_trace when tracing syscalls. It was the reverse of the needed value. (i.e. it was 1 on entry and 0 on exit). Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
This adds a check that /tmp is not mounted noexec. UML needs to be able to do PROT_EXEC mmaps of temp files. Previously, a noexec /tmp would cause an early mysterious UML crash. (Actually, not /tmp but $TMP, which often is the same). Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
Changes a comment about forcing /bin/bash as shell for the UML Makefile. Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
From: Gerd Knorr <kraxel@bytesex.org>, Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it> Uml was using kill(pid, SIGKILL) instead of ptrace(PTRACE_KILL, pid), which used to work, while being probably undocumented. Due to the changes in 2.6.9 to the ptrace(2) semantics, with the introduction of TASK_TRACED by Roland McGrath, this does not more work, so this patch should fix it. With help of Gerd Knorr report and analysis, and its early fix of this problem. He fixed the problem by sending SIGCONT to the child processes after SIGKILL. Which IMHO should not be needed (I think this is a regression, which he already reported). I improved his one, by replacing the SIGCONT hack with using PTRACE_KILL instead. Signed-off-by: -
Hirokazu Takata authored
Here is a patch to fix compile errors for an Mappi evaluation board. - Just change from CONFIG_M32RPCC to CONFIG_M32R_PCC. Thanks to Naoto Sugai for reporting. Signed-off-by:
Hirokazu Takata <takata@linux-m32r.org> Signed-off-by:
-
Hirokazu Takata authored
This patch fixes arch/m32r/lib/memset.S. Signed-off-by:
-
Christoph Lameter authored
- mmtimer: add support for the use of hardware timers on SGI SHubs (sn subarch) via the posix timer interface. - Allows the scheduling of up to 3 hardware interrupts per node to deliver signals to processes running on those nodes. - Periodic timers in user space capable of supporting intervals down to 10us (<10us supported but will usually result in excessive overruns). - Scheduling accuracy of 40ns. (However, typically it takes at least a few usecs for an interrupt to be forwarded to a signal in user space.) - Add missing SHub information to include/asm-ia64/sn/shub_mmr.h - Reserve timer interrupt used in include/asm-ia64/sn/intr.h Signed-off-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Andi Kleen authored
Fix an obviously broken change someone did to the x86-64 NMI handler. reason would get used uninitialized, causing random misbehaviour in the NMI handler and gcc rightly complained about it. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Andi Kleen authored
Add links for p4-clockmod driver in x86-64 cpufreq. AK: Made it dependent on EMBEDDED because the driver is only useful in some special situations and should be normally not used. Signed-off-by:
"Venkatesh Pallipadi" <venkatesh.pallipadi@intel.com> Signed-off-by:
-
Paolo \'Blaisorblade\' Giarrusso authored
The DR7 register on i386/x86_64 has a special meaning, so there is a special check to do. Since the code is rather difficult, I added an explaination about it. Also, while studying the i386 Intel Manual, I saw that x86_64, even on 32bit emulation, allows using values which are disallowed on i386. It's almost obvious that what it allows is setting a 8-byte wide data watchpoint (in fact I double checked the AMD manuals, just in case, and this is true; I couldn't find a mention of this in my Intel manuals). But since the original ia32 emulation code has this comment: /* You are not expected to understand this ... I don't neither. */ I am dubious that the code in ptrace32.c is wrong: does x86_64 supports 8byte-wide watchpoints in 32-bit emulation? I've checked the AMD manual Vol. 2 (no. 24593), which says that to set the length to 8 bits "long mode must be enabled". This means, actually, that the current code is safe, notwithstanding the comment (which I removed). Signed-off-by:
-
Maciej W. Rozycki authored
While discussing races in the NMI handler's trailer fiddling with RTC registers, I've discovered we incorrectly attempt to handle NMIs coming from the system (memory errors, IOCHK# assertions, etc.) with all processors even though the interrupts are only routed to the bootstrap processor. If one of these events coincides with a NMI watchdog tick it may even be handled multiple times in parallel. Here is a fix that makes application processors ignore these events. They no longer access the NMI status bits at I/O port 0x61 which has also the advantage of removing the contention on the port when the I/O APIC NMI watchdog makes all processors arrive at the handler at the same time. Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by:
-
Maciej W. Rozycki authored
Here is a patch to do some cleanup to code affected by the recent change to the bootstrap code responsible for enabling the local APIC. It adds a message about how to get the APIC enabled if previously disabled by the BIOS to aid people expecting the former behavior. It removes some P4-specific code that's become dead as a result of the change. Finally it improves a couple of inaccurate comments. This has been agreed to be reasonable. Signed-off-by:
-
Paul Mackerras authored
This patch is from Hanna Linder. As pci_find_device is going away I've replaced it with pci_get_device and pci_dev_put. Signed-off-by:
Hanna Linder <hannal@us.ibm.com> Signed-off-by:
Maximilian Attems <janitor@sternwelten.at> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Paul Mackerras authored
This patch is from Hanna Linder. As pci_find_device is going away using the new for_each_pci_dev macro. Signed-off-by:
-
Paul Mackerras authored
This patch is from Hanna Linder. As pci_find_device is going away using the new for_each_pci_dev macro. Signed-off-by:
-
Paul Mackerras authored
This patch is from Hanna Linder. As pci_find_device is going away using the new for_each_pci_dev macro. Signed-off-by:
-
Paul Mackerras authored
This patch is from Hanna Linder. As pci_find_device is going away using the new for_each_pci_dev macro. If someone with a PPC64 system could test it I would appreciate it. Signed-off-by:
-
