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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ