[CRIU] [PATCH 20/23] ptrace.c: don't seize the task that doesn't run in the userspace

[Alexander Kartashov]

On 01/14/2013 02:42 PM, Pavel Emelyanov wrote:
> Task trapped/stopped inside the kernel
> code?

No, the trick is that it's not the kernel code. Take a look at /proc/1/maps
on my ARM box:

00008000-0000f000 r-xp 00000000 b3:01 32826      /sbin/init
00016000-00017000 r--p 00006000 b3:01 32826      /sbin/init
00017000-00018000 rw-p 00007000 b3:01 32826      /sbin/init
00018000-00039000 rw-p 00000000 00:00 0          [heap]
b6d73000-b6d75000 r-xp 00000000 b3:01 32866 
/lib/arm-linux-gnueabi/libdl-2.13.so
b6d75000-b6d7c000 ---p 00002000 b3:01 32866 
/lib/arm-linux-gnueabi/libdl-2.13.so
b6d7c000-b6d7d000 r--p 00001000 b3:01 32866 
/lib/arm-linux-gnueabi/libdl-2.13.so
b6d7d000-b6d7e000 rw-p 00002000 b3:01 32866 
/lib/arm-linux-gnueabi/libdl-2.13.so
b6d7e000-b6ea4000 r-xp 00000000 b3:01 32858 
/lib/arm-linux-gnueabi/libc-2.13.so
b6ea4000-b6eab000 ---p 00126000 b3:01 32858 
/lib/arm-linux-gnueabi/libc-2.13.so
b6eab000-b6ead000 r--p 00125000 b3:01 32858 
/lib/arm-linux-gnueabi/libc-2.13.so
b6ead000-b6eae000 rw-p 00127000 b3:01 32858 
/lib/arm-linux-gnueabi/libc-2.13.so
b6eae000-b6eb1000 rw-p 00000000 00:00 0
b6eb1000-b6ecc000 r-xp 00000000 b3:01 32972 
/lib/arm-linux-gnueabi/libselinux.so.1
b6ecc000-b6ed3000 ---p 0001b000 b3:01 32972 
/lib/arm-linux-gnueabi/libselinux.so.1
b6ed3000-b6ed4000 r--p 0001a000 b3:01 32972 
/lib/arm-linux-gnueabi/libselinux.so.1
b6ed4000-b6ed5000 rw-p 0001b000 b3:01 32972 
/lib/arm-linux-gnueabi/libselinux.so.1
b6ed5000-b6f0f000 r-xp 00000000 b3:01 32884 
/lib/arm-linux-gnueabi/libsepol.so.1
b6f0f000-b6f16000 ---p 0003a000 b3:01 32884 
/lib/arm-linux-gnueabi/libsepol.so.1
b6f16000-b6f17000 r--p 00039000 b3:01 32884 
/lib/arm-linux-gnueabi/libsepol.so.1
b6f17000-b6f18000 rw-p 0003a000 b3:01 32884 
/lib/arm-linux-gnueabi/libsepol.so.1
b6f18000-b6f35000 r-xp 00000000 b3:01 32887 
/lib/arm-linux-gnueabi/ld-2.13.so
b6f35000-b6f37000 rw-p 00000000 00:00 0
b6f3b000-b6f3c000 rw-p 00000000 00:00 0
b6f3c000-b6f3d000 r--p 0001c000 b3:01 32887 
/lib/arm-linux-gnueabi/ld-2.13.so
b6f3d000-b6f3e000 rw-p 0001d000 b3:01 32887 
/lib/arm-linux-gnueabi/ld-2.13.so
bedeb000-bee0c000 rw-p 00000000 00:00 0          [stack]
ffff0000-ffff1000 r-xp 00000000 00:00 0          [vectors]


As you can see there's an executable VMA ffff0000-ffff1000 that is above
the userspace code. The task may be seized while executing the code
in this VMA but since it's a special VMA it can't be infected here.

Probably a better solution is to choose a VMA other that the PC is currently
in for infection with the syscall blob.

-- 
Sincerely yours,
Alexander Kartashov

Intern
Core team

www.parallels.com

Skype: aleksandr.kartashov
Email: alekskartashov at parallels.com