[lkml]   [2017]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] pidmap(2)
Hi Alexey,

On Thu, Sep 7, 2017 at 4:04 AM, Andy Lutomirski <> wrote:
> On Wed, Sep 6, 2017 at 2:04 AM, Alexey Dobriyan <> wrote:
>> On 9/6/17, Randy Dunlap <> wrote:
>>> On 09/05/17 15:53, Andrew Morton wrote:
>>> also, I expect that the tiny kernel people will want kconfig options for
>>> these syscalls.
>> We'll add it but the question if it is a good idea. Ideally these system calls
>> should be mandatory and /proc optional.
>> $ size kernel/pidmap.o fs/fdmap.o
>> text data bss dec hex filename
>> 560 0 0 560 230 kernel/pidmap.o
>> 617 0 0 617 269 fs/fdmap.o
> After much discussion at LPC/KS last year, I thought the idea was to
> try to speed up /proc rather than replacing it outright. The two
> specific ideas I recall were:
> 1. Add a syscall like readfileat() that you can use to, in a single
> operation, open, read, and close a /proc file (or other file). This
> should vastly reduce locking and RCU overhead.
> 2. Add a /proc file that has a nice binary format for task info. (nl_attr?)
> I don't see why pidmap() deserves to be significantly faster than getdents().
> Also, a pidmap() syscall like this inherently bypasses any security
> restrictions implied by the way that /proc is mounted. It can respect
> hidepid, but hidepid (as a per-namespace concept) is an enormous turd
> that badly needs to be deprecated, and Djalal is working on exactly
> that.

Yes as noted by Andy, me and Alexey Gladkov are working on modernizing
procfs [1] and to reduce/remove ties within pid namespaces which has lot
of problems now.

We just picked the task again, and this was the result of discussion
with Andy some months ago, on how to improve hidepid, but also how to
improve procfs in general, so we can add other mechanisms to hide or return
NULL on other /proc/_file_not_needed_by_containers_ or
/proc/_specific_module_files_ everything that is not virtualized , or mount only
some specific view of the whole /proc API this will also be used by containers.
This also should make it hard for attackers since we are planning to have
a backward compatible options on how to better treat some of these files in
regard of some namespaces.

The syscall or readfileat() for one operation is a nice addition
definitively. But
in general it would be better to treat /proc as a filesystem and not add other
specific interfaces that may abstract it with pidns, as it is the situation now
which make it from userspace perspective: hard to use especially for security

Alexey, could you please Cc'us on future, thank you very much!



 \ /
  Last update: 2017-09-07 07:06    [W:0.045 / U:0.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site