linux-kernel - Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map

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: <4E5F3B25.9030701@parallels.com>
Date:	Thu, 01 Sep 2011 11:58:29 +0400
From:	Pavel Emelyanov <xemul@...allels.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Cyrill Gorcunov <gorcunov@...il.com>,
	"Kirill A. Shutemov" <kirill@...temov.name>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	"containers@...ts.osdl.org" <containers@...ts.osdl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	Nathan Lynch <ntl@...ox.com>,
	Oren Laadan <orenl@...columbia.edu>,
	Daniel Lezcano <dlezcano@...ibm.com>,
	Glauber Costa <glommer@...allels.com>,
	James Bottomley <jbottomley@...allels.com>,
	Tejun Heo <tj@...nel.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/ directory
 v6

> I'm reluctant to merge something like this unless/until it has real
> use-cases.
> 
> What is the status of your c/r effort?

Working prototype that can dump and restore tree of processes with their
registers, memory of all kinds (anon/file, private/shared), open regular
files and pipes (with contents).

And we have an RFC set from Tejun that can suspend and resume a TCP connection.

> What additional kernel patches are required to bring that effort to a
> usable state and where are those patches?

* The one you've already accepted with ->statfs for pipefs.
* PTRACE_SEIZE set from Tejun (RFC was sent some time earlier)
* CLONE_USEPID flag for the clone() syscall (Cyrill will re-send a bit later)
* The binfmt handler for images (I've sent it earlier, but there's a discussion
  happening over it. We can do restore without one, but it will improve the
  situation significantly)

Once this is merged the prototype I described above starts working on the
out-of-the-box kernel.

> IOW, before starting to merge things I'd like to get an understanding
> of what *all* the patches look like and of what level of c/r
> functionality they provide.
> 
> This particular patch introduces a distressing amount of duplication of
> /proc/pid/maps.  The changelog should provide a really good
> justification for doing this: why is /proc/pid/maps (and smaps!)
> unsuitable and why cannot maps/smaps be fixed to be suitable?

This is not duplication, since with /proc/pid/s?maps you have no idea of what
file is being mapped by a vma. I mean - you know some "path" to it, but it's
not reliable at all.

Besides, without this set there's absolutely no way to find out which two 
mappings are shared and is extremely hard to restore shared mapping.

Thanks,
Pavel
--
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/