From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754051Ab1L1QHE (ORCPT <rfc822;w@1wt.eu>);
	Wed, 28 Dec 2011 11:07:04 -0500
Received: from mail-iy0-f174.google.com ([209.85.210.174]:36537 "EHLO
	mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753966Ab1L1QHB (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 28 Dec 2011 11:07:01 -0500
Date: Wed, 28 Dec 2011 08:06:55 -0800
From: Tejun Heo <tj@kernel.org>
To: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: linux-kernel@vger.kernel.org, Pavel Emelyanov <xemul@parallels.com>,
        Glauber Costa <glommer@parallels.com>,
        Andi Kleen <andi@firstfloor.org>, Matt Helsley <matthltc@us.ibm.com>,
        Pekka Enberg <penberg@kernel.org>,
        Eric Dumazet <eric.dumazet@gmail.com>,
        Vasiliy Kulikov <segoon@openwall.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [patch 1/4] Add routine for generating an ID for kernel pointer
Message-ID: <20111228160655.GL17712@google.com>
References: <20111223124741.711871189@openvz.org>
 <20111223124920.661126615@openvz.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20111223124920.661126615@openvz.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello, Cyrill.

Just my 2 cents.

On Fri, Dec 23, 2011 at 04:47:42PM +0400, Cyrill Gorcunov wrote:
> +unsigned long gen_obj_id(void *ptr, int type)
> +{
> +	if (!capable(CAP_SYS_ADMIN) || !ptr)
> +		return 0;
> +
> +	BUG_ON(type >= GEN_OBJ_ID_TYPES);
> +
> +	/*
> +	 * Note the simple XOR is used here not in a sake
> +	 * of security by any means, but rather to break
> +	 * an "impression" that such IDs means something
> +	 * other than a number which can be used for comparison
> +	 * with another number generated by this helper only.
> +	 */
> +	return ((unsigned long)ptr) ^ gen_obj_cookie[type];
> +}

To me, XOR & CAP_SYS_ADMIN combination doesn't make much sense.  With
CAP_SYS_ADMIN, there's no reason for XOR - we can just export
pointers.  If we plan on removing CAP_SYS_ADMIN restriction down the
road, XOR doesn't help much.  It's too weak.  The XOR is unnecessary
with CAP_SYS_ADMIN and useless without it.  It seems pointless to me.
If we're going down this route, I think doing cryptographically safe
hash would be much better.

Thanks.

-- 
tejun