From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751382AbdAMIpS (ORCPT ); Fri, 13 Jan 2017 03:45:18 -0500 Received: from edna.lautre.net ([80.67.160.88]:38596 "EHLO edna.lautre.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751222AbdAMIpR (ORCPT ); Fri, 13 Jan 2017 03:45:17 -0500 Message-ID: <1484297111.2197.1.camel@nonadev.net> Subject: Re: [RFC DRAFT] Adds PUI: process unic identifier From: =?ISO-8859-1?Q?Jos=E9?= Bollo To: Tetsuo Handa Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Date: Fri, 13 Jan 2017 09:45:11 +0100 In-Reply-To: <201701121933.CBH73963.JQHFLOFMFtOSVO@I-love.SAKURA.ne.jp> References: <20170110215924.4623-1-jobol@nonadev.net> <201701121933.CBH73963.JQHFLOFMFtOSVO@I-love.SAKURA.ne.jp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3 (3.22.3-1.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-01-12 at 19:33 +0900, Tetsuo Handa wrote: > Jose Bollo wrote: > > Hi all, > > > > I'd like to get your feeling about the idea > > exposed in that draft. Should continue or stop > > immediately? Is there already some existing work? > > How is the taken approach? > > > > BR - Jose Bollo > > > > [RFC DRAFT] Adds PUI: process unic identifier > > > > The name 'pui' is choosen -instead of puid- > > to avoid confusion with either pid and uid. > > It is intended to identify uniquely each > > activated task item, accordling to namespaces. > > > > 64 bits seems to be a good deal for beginning. > > The count of second in a year is less than 2^25. > > So if a huge machine is able to create 2^31 processes > > per second (ex: 2^7 cores, each creating 2^24 processes > > -a nighmare-), then the unic id is over in 2^8 years. > > Far more than what a regular system upgrade needs. > > > > The pui is represented as a hexadecimal value because > > it is much more efficient. > > Firstly, please explain the motivation why you need process unique > identifier that is really unique. This patch involves userspace visible > changes but not everybody is aware of what your PTAGS wants to do. > > Secondly, please describe how userspace processes use process unique > identifier. This patch adds "Pui:" line and "NSpui:" line to > /proc/$pid/status and SO_PEERPUI option to getsockopt(), but nothing else. > Why these lines and option are needed and why they are sufficient? > > There is start_time field ("struct task_struct"->real_start_time) > in /proc/$pid/stat which is already almost unique. Even if userspace > processes use both $pid and start_time for identifying a process, is it > unreliable? If userspace processes use both "struct task_struct"->pid > and "struct task_struct"->real_start_time for identifying a process, > is it still unreliable? I wonder why find_pui_ns() needs to be aware of > CONFIG_PID_NS. How userspace processes use process unique identifier for > identifying a "struct task_struct"? > > There are %Lu %Ld %Lx %LX kstrtoull() kstrtoll() for converting > string to 64bit integer, and %llu %lld %llx %llX for converting > 64bit integer to string. You don't need to redefine 64bit types > using typedef keyword. Hi Tetsuo-san, Thank you for your review. It helps a lot! After reading about the possible use of real_start_time, I was wondering if using a kind of clock+pid(ns) would be able to replace at lower resource cost what I proposed. That leads to use of 128 bits puids but without changing anything in {pid,pid_namespace}.[ch]. Great! But I still have to check. I wanted to get advices first so I didn't sent the fs part of pui because it is not still existing. This fs part will allow access to task by their pui. I'll probably send an update in a month or more. Best regards José Bollo