linux-kernel - Re: [PATCH 1/9] exec: add a global execve counter

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]

Message-ID: <20120311095658.GA15121@elte.hu>
Date:	Sun, 11 Mar 2012 10:56:58 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Solar Designer <solar@...nwall.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Djalal Harouni <tixxdz@...ndz.org>,
	linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Alexey Dobriyan <adobriyan@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	Kees Cook <keescook@...omium.org>,
	WANG Cong <xiyou.wangcong@...il.com>,
	James Morris <james.l.morris@...cle.com>,
	Oleg Nesterov <oleg@...hat.com>,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Greg KH <gregkh@...uxfoundation.org>,
	Stephen Wilson <wilsons@...rt.ca>,
	"Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH 1/9] exec: add a global execve counter

* Solar Designer <solar@...nwall.com> wrote:

> > Actually, using a pure counter is horrible, because even if 
> > it takes four days to wrap, it *will* wrap, and the attacker 
> > can just count his own execve's.
> 
> Four days (for a 32-bit counter) is just not enough, so the 
> counter needs to be e.g. 64-bit as proposed.  A 64-bit counter 
> won't wrap during lifetime of a system.

A 64-bit counter is OK on 32-bit platforms as well as long as 
it's not *atomic*.

Linus's scheme of using the CPU ID for the high bits would solve 
that particular problem IMO. Each CPU would have its own count 
set apart in a percpu area, accessible via __this_cpu_inc() or 
so.

16 bits for the CPU ID and 48 bits for the actual count should 
be enough for everyone! ;-) It wraps in about 700 years, with 
current CPU speeds and assuming that exec() will be relatively 
slow in the future as well.

Some other kernel code might make use of such a fast, global 
generation count as well, so if this is reasonably abstracted 
out and named properly it would not just be a single-purpose 
security facility. DEFINE_GENCOUNT() or so? [the count itself 
would not be reused, of course.]

> The CPUs' timestamp counters were not designed for security.  
> I would not be too surprised if some implementation of a CPU 
> architecture (maybe emulated, maybe under a hypervisor) has 
> such timestamp counter granularity that we may see the same 
> value across a second execve().

Not using the TSC would certainly make this logic simpler and 
faster - which is a big plus for any security measure.

Thanks,

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