On Tue, Jan 27, 2015 at 1:41 AM, Cyrill Gorcunov <[email protected]> wrote: > Signed-off-by: Cyrill Gorcunov <[email protected]> > CC: Kees Cook <[email protected]> > CC: Andrew Morton <[email protected]> > CC: "Kirill A. Shutemov" <[email protected]> > CC: Calvin Owens <[email protected]> > CC: Alexey Dobriyan <[email protected]> > CC: Oleg Nesterov <[email protected]> > CC: "Eric W. Biederman" <[email protected]> > CC: Al Viro <[email protected]> > CC: Peter Feiner <[email protected]> > CC: Pavel Emelyanov <[email protected]> > --- > > Gentlemen, could you please take a look once time permit. > Which questions this text raises so I could add more info > here (how we use it in criu, ptrace_may_access guards?) > > Documentation/filesystems/proc.txt | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > > Index: linux-2.6.git/Documentation/filesystems/proc.txt > =================================================================== > --- linux-2.6.git.orig/Documentation/filesystems/proc.txt > +++ linux-2.6.git/Documentation/filesystems/proc.txt > @@ -42,6 +42,7 @@ Table of Contents > 3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm > 3.7 /proc/<pid>/task/<tid>/children - Information about task children > 3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file > + 3.9 /proc/<pid>/map_files - Information about memory mapped files > > 4 Configuring procfs > 4.1 Mount options > @@ -1763,6 +1764,28 @@ pair provide additional information part > with TIMER_ABSTIME option which will be shown in 'settime flags', but > 'it_value' > still exhibits timer's remaining time. > > +3.9 /proc/<pid>/map_files - Information about memory mapped files > +--------------------------------------------------------------------- > +This directory consists of simbolic links which represent memory mapped files > +the process is carrying. A typical output is like the following > + > + | lr-------- 1 root root 64 Jan 27 11:24 333c600000-333c620000 -> > /usr/lib64/ld-2.18.so > + | lr-------- 1 root root 64 Jan 27 11:24 333c81f000-333c820000 -> > /usr/lib64/ld-2.18.so > + | lr-------- 1 root root 64 Jan 27 11:24 333c820000-333c821000 -> > /usr/lib64/ld-2.18.so > + | ... > + | lr-------- 1 root root 64 Jan 27 11:24 35d0421000-35d0422000 -> > /usr/lib64/libselinux.so.1 > + | lr-------- 1 root root 64 Jan 27 11:24 400000-41a000 -> /usr/bin/ls > + > +The name of a link is virtual memory bounds a particular map exhibits, i.e. > +vm_area_struct::vm_start-vm_area_struct::vm_end. > + > +The main purpose of map_files directory is to be able to retrieve a set of > +memory mapped files in a fast way instead of parsing /proc/<pid>/maps or > +/proc/<pid>/smaps which contain a way more records. Same time one can open(2) > +mappings from the listings of two processes and comparing inodes figure out > +which anonymous memory areas are actually shared.
Thanks for details! I still don't understand how this is used for checkpoint/restore when the mmap offset isn't shown. Can't a process map, say 4K of a file, from different offsets, and it would show up as: 400000-401000 -> /some/file 401000-402000 -> /some/file but there'd be no way to know how to restore that mapping? Are these symlinks "regular" symlinks, or are they something more special that bypasses VFS? If it bypasses VFS, I think adding and open check with PTRACE_ATTACH is needed, since now you're able to _modify_ the memory space of the target process instead of just reading it. -Kees -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
