Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120221162558.GA12919@dztty>
Date: Tue, 21 Feb 2012 17:25:58 +0100
From: Djalal Harouni <tixxdz@...ndz.org>
To: kernel-hardening@...ts.openwall.com
Cc: Brad Spengler <spender@...ecurity.net>,
	Solar Designer <solar@...nwall.com>
Subject: Re: procfs: infoleaks and DAC permissions

On Tue, Feb 21, 2012 at 06:56:53PM +0400, Solar Designer wrote:
> On Fri, Feb 10, 2012 at 06:36:17PM +0400, Vasiliy Kulikov wrote:
> > [1] http://grsecurity.net/~spender/dev_patches/distros_should_sponsor_me_for_doing_their_jobs.patch
> 
> In order to provide its security, this relies on atomic64_t actually
> being 64-bit and on atomic64_inc_return() returning a 64-bit value - but
> one or both of these requirements appear to be violated for some archs.
> 
> In fact, per a quick grep it appears that atomic64_inc_return() exists
> for a subset of the archs only.
There is the GENERIC_ATOMIC64 config option that can be used to support
atomic64_t.

[...]
> Should there be a different revision of the patch for mainline?  Perhaps
> it'd have to use a spinlock at least on archs lacking 64-bit atomics.
I want to add that atomic64_t is already used in other places:
xfs log functions, perf counters, netfilter conntrack modules...

That generic solution is already using raw spinlocks, but with a static
hashed array, which is perhaps not perfect for a machine with a lot of
CPUs ?


BTW I'm still trying to work on these issues, and the global exec_id from
spender's patch is the best solution, since it can be used as a global
counter to track objects related to process/mm... as noted by Vasiliy
in his other email.

Out of context: from the git commit history we can see that there have been
lately a lot of changes to /proc/<pid>/* logic which is related to this
sort of vulns.  I'm trying to summarize them before sending more patches,
just to avoid new problems.

Thanks.

-- 
tixxdz
http://opendz.org

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.