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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 18 Feb 2012 11:15:39 -0500
From:	David Windsor <dwindsor@...il.com>
To:	Roland Dreier <roland@...estorage.com>
Cc:	Djalal Harouni <tixxdz@...ndz.org>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	kernel-hardening@...ts.openwall.com,
	Kees Cook <keescook@...omium.org>,
	Ubuntu security discussion <ubuntu-hardened@...ts.ubuntu.com>,
	linux-kernel@...r.kernel.org, pageexec@...email.hu,
	spender@...ecurity.net, gregkh@...uxfoundation.org
Subject: Re: [kernel-hardening] Re: Add overflow protection to kref

On Fri, Feb 17, 2012 at 8:44 PM, Roland Dreier <roland@...estorage.com> wrote:
> On Fri, Feb 17, 2012 at 3:39 PM, Djalal Harouni <tixxdz@...ndz.org> wrote:
>>> 2) what to do with architectures-loosers?
>> There is lib/atomic64.c but with a static hashed array of raw_spinlocks.
>
> Even leaving aside performance impact of atomic64_t (and probably
> in most cases the performance of kref is not important at all), it is
> unfortunate to bloat the size from 4 bytes to 8 bytes.
>
> It seems much better to have some out-of-line code for overflow
> checking rather than increasing the size of every data structure
> that embeds a kref.
>

kref is mostly a set of operations (init, get, sub, put) to be
performed on an atomic_t object.

>From linux/kref.h:

struct kref {
    atomic_t refcount;
};

Moving overflow protection into kref amounts to placing some
procedural code into kref_get and kref_sub, adding a rather small
constant factor of time, not space, to users of kref.  Introducing
overflow protection doesn't necessitate adding anything to kref for
greater state tracking.

Did you have something else in mind when you suggested a potential
increase in the size of kref?


-- 
PGP: 6141 5FFD 11AE 9844 153E  F268 7C98 7268 6B19 6CC9
--
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