linux-kernel - Re: i386-show-unhandled-signals-v3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20070726131840.6f11a056@the-village.bc.nu>
Date:	Thu, 26 Jul 2007 13:18:40 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Andi Kleen <ak@...e.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"Masoud Sharbiani" <masouds@...gle.com>,
	"Kirill Korotaev" <dev@...nvz.org>, linux-kernel@...r.kernel.org
Subject: Re: i386-show-unhandled-signals-v3

> > So you turn it on if your applications are playing up.  bfd.
> 
> You might not know applications are segfaulting. e.g. when I originally
> enabled it we found that a few obscure cases in a default system
> were occasionally segfaulting, but nobody noticed because there
> wasn't a really visible malfunction. Still fixing those made
> a better system.

There problem is that if you get something going crazy segfaulting your
logging itself can make the problem far worse. The rate limiting is as
much important to stop accidents as stop malicious attack.

> for example. Or just run the system out of memory; that will get plenty of logs
> (don't say ulimit now, you know as well as me that they are not good enough
> to prevent oom from users). Or use an unaligned a.out executable.

Zero overcommit keeps it pretty sane - most times. 

> Some of these are rate limited, but rate limiting just means it will take longer
> to fill the disk. 

Which is good news and gives you a lot longer (or your tools a lot
longer) to react and sort it out. It also avoids the disk thrashing and
performance hit you can cause.

> Anyways if you feel strongly about it then rate limit the x86-64 ones
> (Masoud's patch did this anyways); but please don't turn them off.

Its configurable easily enough so I'm not sure it matters which way it is
set, but it does need to be a -safe- default - either rate limited or off.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/