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

[Pavel Emelyanov]

On 01/14/2013 03:02 PM, Alexander Kartashov wrote:
> 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.

OK, I see. I think what we need to do it fix the get_vma_by_ip and its
caller to find _any_ executable VMA and put the syscall-blob there.

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