Date: Sun, 12 Aug 2012 22:31:09 +0400 From: Solar Designer <solar@...nwall.com> To: owl-dev@...ts.openwall.com Subject: Re: kref_overflow Vasily - On Sun, Aug 12, 2012 at 10:00:21PM +0400, Vasily Kulikov wrote: > The light version of PAX_REFCOUNT was backported to Owl kernel. > It protects kref only, not all atomic_t. The pro is almost zero maintenance > time. The con is obviously missing protection for counters which were not > explicitly marked as refcounter by using kref instead of atomic_t. > > The sysctl for it is kernel.kref_overflow_action. It can be set to: > > 0 - no overflow check at all. Current upstream behaviour. > 1 - protection is on (default). Each overflow emits stack dump and a big log > warning. Is this protection at all? It's at best knowing that there was an overflow, and only if the attacker (in case this was malicious) could not or otherwise did not overwrite the log records yet (in case they're local and the attack is successful). > 2 - the same as 1 plus the current task is killed. > 3 - an overflow leads to kernel panic. What does it take to actually prevent attacks from succeeding? Does "action 2" above protect against a subset of attacks (which ones?) or is it almost equivalent to "action 1"? I'm afraid that we might have to make "action 3" the default in order for this protection to be of much use, but then we'll also make systems potentially less reliable in practice (causing kernel panics where the system could otherwise mostly stay up for longer, until a sysadmin reboots it more cleanly). Presumably most of these overflows won't actually be malicious. Thanks, Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.