Dumb question: Why are exceptions such as SIGSEGV not logged
Linux logs almost everything, why not exceptions such as SIGSEGV in userspace which may be very informative?
Regards
Michael
Signature · 6 lines
Powered by linux-2.6. Compiled with gcc-2.95-3 - mature and rock solid 2.4/2.6 kernel testing: ACPI PCI interrupt routing, PCI IRQ sharing, swsusp 2.6 kernel testing: PCMCIA yenta_socket, Suspend to RAM with ACPI S1-S3 More info on swsusp: http://sourceforge.net/projects/swsusp/
Quoted 2 lines · Michael Frank
Linux logs almost everything, why not exceptions such as SIGSEGV in userspace which may be very informative?
Consider this code:
char *foo = 0;
sigset(SIGSEGV,SIG_IGNORE);
for(;;) { *foo = '\5'; }Your logfiles just got DoS'ed....
(Your syslog will just print 'last message repeated 11934 times'? OK, put two different signals in the loop.. ;)
And yes, I've worked on systems that will log SEGV... and the logs get ugly.
Quoted 5 lines · [email protected] wrote:
Quoted 2 lines · Michael Frank
Linux logs almost everything, why not exceptions such as SIGSEGV in userspace which may be very informative?
[
SIG_IGN]
Presumably only SIGSEGVs which kill a process would be logged...
Some programs actually _use_ SIGSEGV in a useful way, to manage memory. Same for SIGBUS and other signals. It would be wrong to log them.
-- Jamie
Quoted 7 lines · [email protected] wrote:
Consider this code:
char *foo = 0; sigset(SIGSEGV,SIG_IGNORE); for(;;) { *foo = '\5'; }Your logfiles just got DoS'ed....
Why not then just log uncaught exceptions?
Quoted 10 lines · David D. Hagood
Quoted 5 lines · [email protected] wrote:
Consider this code:
char *foo = 0; sigset(SIGSEGV,SIG_IGNORE); for(;;) { *foo = '\5'; }Your logfiles just got DoS'ed....
Why not then just log uncaught exceptions?
You can still DoS by forking repeatedly and having the child die with SEGV...
-Doug
Quoted 4 lines · * Doug McNaught ([email protected]) wrote:
You can still DoS by forking repeatedly and having the child die with SEGV...
True - but there are a million and one ways of similarly DoSing a box; an option to log programs terminated by a bad uncaught signal would seem useful to me; at least one of which could be as a sign of someone trying out buffer overrun type attacks on a system; and just as a diagnostic to catch apps that go pop when you aren't expecting them too.
(I seem to remember ARM Linux actually does log user exceptions and very useful it is too).
Dave
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
Quoted 2 lines · Dr. David Alan Gilbert
(I seem to remember ARM Linux actually does log user exceptions and very useful it is too).
Of course, this is configurable via a debugging option...
Signature · 2 lines
Russell King ([email protected]) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 4 lines · David D. Hagood
Quoted 1 line
Your logfiles just got DoS'ed....
Why not then just log uncaught exceptions?
man acct
Quoted 9 lines · David D. Hagood
Quoted 7 lines · [email protected] wrote:
Consider this code:
char *foo = 0; sigset(SIGSEGV,SIG_IGNORE); for(;;) { *foo = '\5'; }Your logfiles just got DoS'ed....
...
Consider this code:
for (;;) syslog(LOG_INFO, "root, hurt me please!");
My point being, that if a user wishes to spam the syslog he can.
Please read the syslogd man page - see under "SECURITY THREATS". Especially option 5 in that section:
----------------
5. Use step 4 and if the problem persists and is not secondary to a rogue
program/daemon get a 3.5 ft (approx. 1 meter) length of sucker rod* and have a chat with the user in question.
Sucker rod def. -- 3/4, 7/8 or 1in. hardened steel rod, male threaded on each end. Primary use in the oil industry in Western North Dakota and other locations to pump 'suck' oil from oil wells. Secondary uses are for the construction of cattle feed lots and for dealing with the occasional recalcitrant or belligerent individual.
----------------
Signature · 6 lines
................................................................ : [email protected] : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............:
Thank you all for your valuable input,
I was chasing some data corruption testing swsusp.
This simple patch met my immediate needs (against 2.4.22-rc1)
diff -uN kernel/signal.c.orig kernel/signal.c
signal.c 2003-08-17 06:21:49.000000000 +0800 renamed from signal.c.orig 2003-08-16 22:08:57.000000000 +0800 +5 -0
@@ -536,6 +536,11 @@ int ret; +#ifdef CONFIG_SOFTWARE_SUSPEND_DEBUG + if (sig == 11 || sig == 13) + printk("Signal: %d\n",sig); +#endif + #if DEBUG_SIG printk("SIG queue (%s:%d): %d ", t->comm, t->pid, sig); #endif
Quoted 4 lines
----------------
5. Use step 4 and if the problem persists and is not secondary to a
rogue program/daemon get a 3.5 ft (approx. 1 meter) length of sucker rod* and have a chat with the user in question.
As to security concerns, I feel this being the appropriate approach ;)
Regards
Michael
Signature · 6 lines
Powered by linux-2.6. Compiled with gcc-2.95-3 - mature and rock solid 2.4/2.6 kernel testing: ACPI PCI interrupt routing, PCI IRQ sharing, swsusp 2.6 kernel testing: PCMCIA yenta_socket, Suspend to RAM with ACPI S1-S3 More info on swsusp: http://sourceforge.net/projects/swsusp/
Quoted 5 lines
Quoted 2 lines · [email protected] wrote:
Consider this code:
Quoted 7 lines
Quoted 5 lines
char *foo = 0; sigset(SIGSEGV,SIG_IGNORE); for(;;) { *foo = '\5'; }Your logfiles just got DoS'ed....
Why not then just log uncaught exceptions?
Because deliberately creating an uncaught exception is a perfectly sane,
reasonable thing to do with well-defined semantics. Applications should feel free to do such reasonable things without getting complaints from the system administrator that their log is being flooded with garbage.
There is no mechanism that is guaranteed to terminate a process other than
sending yourself an exception that is not caught. So in cases where you must guarantee that your process terminates, it is perfectly reasonable to send yourself a SIGILL.
FreeBSD logs any number of normal things that sane, reasonable processes do
and it's very annoying. A very annoying example is FreeBSD's desire to log calls to 'wait' functions with 'SIGCHLD' ignored. How else can portable programs say, "I want you to automatically reap my zombies if you can, but otherwise, I'll reap them if needed by calling waitpid(WNOHANG) every once in a while".
DS
Followup to: <[email protected]> By author: "David Schwartz" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 6 lines
There is no mechanism that is guaranteed to terminate a process other than
sending yourself an exception that is not caught. So in cases where you must guarantee that your process terminates, it is perfectly reasonable to send yourself a SIGILL.
exit(2)?
-hpa
Signature · 4 lines
<[email protected]> at work, <[email protected]> in private! If you send me mail in HTML format I will assume it's spam. "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
Quoted 4 lines · H. Peter Anvin
Followup to: <[email protected]> By author: "David Schwartz" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 8 lines
Quoted 4 lines
There is no mechanism that is guaranteed to terminate a process other
than sending yourself an exception that is not caught. So in cases where you must guarantee that your process terminates, it is perfectly reasonable to send yourself a SIGILL.exit(2)?
-hpa
Nope... A monitoring process must send the exit to a different thread... which may be being directed to generate a core dump.
Quoted 10 lines
Quoted 8 lines
There is no mechanism that is guaranteed to terminate a
process other than
sending yourself an exception that is not caught. So in cases where you must
guarantee that your process terminates, it is perfectly reasonable to send
yourself a SIGILL.exit(2)?
And what if a registered 'atexit' function needs to acquire a mutex that is
held by a thread that's in an endless loop? What if a standard I/O stream has buffered data for a local disk that failed? I'm looking for a mechanism that is guaranteed to terminate a process immediately.
DS
Quoted 9 lines · David Schwartz
Quoted 7 lines
Quoted 7 lines
There is no mechanism that is guaranteed to terminate a
process other than
sending yourself an exception that is not caught. So in cases where you must
guarantee that your process terminates, it is perfectly reasonable to send
yourself a SIGILL.
Quoted 8 lines
Quoted 1 line
exit(2)?
And what if a registered 'atexit' function needs to acquire a mutex that is
held by a thread that's in an endless loop? What if a standard I/O stream has buffered data for a local disk that failed? I'm looking for a mechanism that is guaranteed to terminate a process immediately.
Correction...
_exit(2).
There is no exit(2); I was talking about _exit(2) and you're talking about exit(3).
_exit(2) *is* guaranteed to terminate a process immediately.
-hpa
Quoted 11 lines
Correction...
_exit(2).There is no exit(2); I was talking about
_exit(2)and you're talking about exit(3).
_exit(2)*is* guaranteed to terminate a process immediately.-hpa
If only it was so! I have direct practical experience that under
LinuxThreads, at least, it doesn't. SuSv3 allows _exit to flush open streams and remove temporary files. Sadly, _exit, on many systems, acquire locks or accesses process structures that might be corrupt whereas dereferencing a NULL pointer does not.
I have portable code that has a 'terminate this process immediately'
function. It started out calling '_exit' until we found platforms where that resulted in a hang (say the thread calling _exit holds a non-recursive mutex that the _exit function tries to acquire). So we kept inching our way up to more and more extreme termination methods.
DS
Quoted 2 lines · Michael Frank
Linux logs almost everything, why not exceptions such as SIGSEGV in userspace which may be very informative?
Such exceptions are part of the normal operation of certain kinds of programs, such as ones using (nowadays unusual) certain garbage collection algorithms. I actually installed such a beast (Lisp system) in no small part so it would exercise "invalid" memory accesses and test various bits of VM code related to such. For other VM people interested in it, there's an sbcl debian package that recompiles a moderately sized chunk of Lisp code and hence runs the system at install-time, and so exercises the SIGSEGV path rather heavily on 32-bit systems and/or systems with <= 2GB of RAM. No particular intervention apart from (re)installing it is required to pound the SIGSEGV path like a wild monkey, so it's actually a very convenient touch test for such things.
-- wli
Quoted 4 lines · William Lee Irwin III
Quoted 2 lines · Michael Frank
Linux logs almost everything, why not exceptions such as SIGSEGV in userspace which may be very informative?
Quoted 12 lines
Such exceptions are part of the normal operation of certain kinds of programs, such as ones using (nowadays unusual) certain garbage collection algorithms. I actually installed such a beast (Lisp system) in no small part so it would exercise "invalid" memory accesses and test various bits of VM code related to such. For other VM people interested in it, there's an sbcl debian package that recompiles a moderately sized chunk of Lisp code and hence runs the system at install-time, and so exercises the SIGSEGV path rather heavily on 32-bit systems and/or systems with <= 2GB of RAM. No particular intervention apart from (re)installing it is required to pound the SIGSEGV path like a wild monkey, so it's actually a very convenient touch test for such things.
I am thinking along the line of "Exceptions" rather than "normal events" by specific applications.
I tend to see segfaults only when something is broken or when my lapse of attention perhaps should be rewarded by said "sucker rod".
The current application to trap SIGSEGV when something is badly broken can be found here:
http://marc.theaimsgroup.com/?l=swsusp-devel&m=106121712521861&w=2
Regards
Michael
Signature · 6 lines
Powered by linux-2.6. Compiled with gcc-2.95-3 - mature and rock solid 2.4/2.6 kernel testing: ACPI PCI interrupt routing, PCI IRQ sharing, swsusp 2.6 kernel testing: PCMCIA yenta_socket, Suspend to RAM with ACPI S1-S3 More info on swsusp: http://sourceforge.net/projects/swsusp/