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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFzTXuvpqjDUtjN48cc3RWADryddVXxc2RQhj6sCK=V9ag@mail.gmail.com>
Date:	Sat, 10 Mar 2012 16:12:20 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Djalal Harouni <tixxdz@...ndz.org>
Cc:	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>,
	Solar Designer <solar@...nwall.com>,
	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>,
	Ingo Molnar <mingo@...e.hu>, Stephen Wilson <wilsons@...rt.ca>,
	"Jason A. Donenfeld" <Jason@...c4.com>
Subject: Re: [PATCH 1/9] exec: add a global execve counter

On Sat, Mar 10, 2012 at 3:25 PM, Djalal Harouni <tixxdz@...ndz.org> wrote:
>
> Given that consideration this patch introduces two counters:
> A global atomic execve counter that will be incremented on every
> do_execve_common() call, and an atomic exec_id member for the task_struct.

This seems horribly expensive on most 32-bit architectures, including
very much x86-32. That atomic64_inc_return() is not cheap.  It's
possible that it's basically an impossible operation to do atomically
on certain platforms, causing it to use some random spinlock instead.

I wonder if we couldn't make something much cheaper, since we don't
actually care about it being globally incrementing, we just care about
it being globally unique. IOW, it could easily be a 56-bit per-cpu
counter along with the CPU number in the high bits or something like
that. Avoiding the whole atomicity issue, and thus avoiding the main
reason those things are really expensive.

IOW, something like

   cpu = get_cpu();
   .. increment percpu 64-bit counter ..
   id = counter * MAX_CPUS + cpu;
   put_cpu(cpu);

or equivalent would seem to be a potentially much cheaper approach.

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