[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120812183109.GC3799@openwall.com>
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.
