Linux漏洞引起zygote重启问题分析报告

【问题现象】

启动《神马搜索》APP，系统高概率重启。

【分析问题】main日志中，除了app的NE日志合zygote重启日志外，无其他明显的异常：

11-05 15:14:51.824 11179 11179 I DEBUG   : pid: 23631, tid: 23693, name: ucsdk_setup  >>> com.uc.searchbox <<<
11-05 15:14:51.824 11179 11179 I DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
11-05 15:14:51.914 11179 11179 I DEBUG   :     r0 00000000  r1 00005c8d  r2 00000006  r3 00000000
11-05 15:14:51.914 11179 11179 I DEBUG   :     r4 00000006  r5 00000016  r6 00005c8d  r7 0000010c
11-05 15:14:51.914 11179 11179 I DEBUG   :     r8 7b6aa841  r9 00000000  sl 4173fc38  fp 71be6c90
11-05 15:14:51.914 11179 11179 I DEBUG   :     ip 7c27cf8c  sp 7a0da770  lr 400b5169  pc 400c410c  cpsr 000f001
...
11-05 15:14:54.224 24116 24116 D AndroidRuntime:
11-05 15:14:54.224 24116 24116 D AndroidRuntime: >>>>>> AndroidRuntime START com.android.internal.os.ZygoteInit <<<<<<
11-05 15:14:55.054   232   232 I ServiceManager: service 'simphonebook.0' died
11-05 15:14:55.054   232   232 I ServiceManager: service 'simphonebook' died
11-05 15:14:55.054   232   232 I ServiceManager: service 'iphonesubinfo.0' died

内核日志中也没有异常。

用stace查看zygote：

root@cancro:/ # ps |grep zygote                                                
root      18987 1     863628 60724 ffffffff 400a9854 S zygote

 
root@cancro:/ # strace -CttTip 18987  
15:14:53.566312 [400c2648] madvise(0x71aac000, 16384, 0xc /* MADV_??? */) = -1 EINVAL (Invalid argument) <0.000037>
15:14:53.566502 [400c25a8] mmap2(NULL, 1040384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x71ab0000 <0.000041>
15:14:53.566696 [400c2648] madvise(0x71ab0000, 1040384, 0xc /* MADV_??? */) = -1 EINVAL (Invalid argument) <0.000037>
15:14:53.566942 [400c2628] mprotect(0x71ab0000, 4096, PROT_NONE) = 0 <0.000045>
15:14:53.567160 [400c39d8] clone(child_stack=0x71baddc8, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 24057 <0.000065>
15:14:53.567381 [400c3a84] futex(0x71baddd0, FUTEX_WAKE_PRIVATE, 1) = 1 <0.000083>
15:14:53.567671 [400c3a84] futex(0x4174612c, FUTEX_WAKE_PRIVATE, 2147483647) = 1 <0.000052>
15:14:53.567882 [400c3a84] futex(0x41746128, FUTEX_WAKE_PRIVATE, 1) = 1 <0.000081>
15:14:53.568118 [400c3a84] futex(0x6fccbdf0, FUTEX_WAKE_PRIVATE, 1) = 1 <0.000063>
15:14:53.568346 [400c211c] getpgid(0x4b30) = 18987 <0.000039>
15:14:53.568542 [400c231c] setpgid(24049, 18987) = 0 <0.000039>
15:14:53.568768 [400c3538] sendmsg(50, {msg_name(0)=NULL, msg_iov(1)=[{"]�", 4}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 4 <0.000061>
15:14:53.569092 [400c3538] sendmsg(50, {msg_name(0)=NULL, msg_iov(1)=[{"", 1}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 1 <0.000053>
15:14:53.569426 [400c2854] select(51, [10 50], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted) <0.328044>
15:14:53.905148 [????????] +++ killed by SIGHUP +++

zygote原来是被SIGHUP给kill掉的！

zygote是root权限，一般app无法在用户态发送signal来杀死root的app，所以把问题的范围缩小到内核代码中。

在内核代码中搜索SIGHUP，发现如下代码很可疑：

@kernel/kernel/exit.c
static void
kill_orphaned_pgrp(struct task_struct *tsk, struct task_struct *parent)
{
        struct pid *pgrp = task_pgrp(tsk);
        struct task_struct *ignored_task = tsk;

        if (!parent)
                parent = tsk->real_parent;
        else
                ignored_task = NULL;

        if (task_pgrp(parent) != pgrp &&
            task_session(parent) == task_session(tsk) &&
            will_become_orphaned_pgrp(pgrp, ignored_task) &&
            has_stopped_jobs(pgrp)) {
               __kill_pgrp_info(SIGHUP, SEND_SIG_PRIV, pgrp);
               __kill_pgrp_info(SIGCONT, SEND_SIG_PRIV, pgrp);
        }
}

打开kernel的tracing开关

# echo 1 > /d/tracing/events/signal/enable

# cat /d/tracing/trace_pipe
           <...>-9083  [003] d..3 88396.530478: signal_generate: sig=1 errno=0 code=128 comm=chmod pid=9083 grp=1 res=0
           <...>-9083  [003] d..3 88396.530567: signal_generate: sig=1 errno=0 code=128 comm=ipayGphone:push pid=9024 grp=1 res=0
           <...>-9083  [003] d..3 88396.530728: signal_generate: sig=1 errno=0 code=128 comm=m.taobao.taobao pid=8889 grp=1 res=0
           <...>-9083  [003] d..3 88396.530891: signal_generate: sig=1 errno=0 code=128 comm=id.AlipayGphone pid=8824 grp=1 res=0
           <...>-9083  [003] d..3 88396.531072: signal_generate: sig=1 errno=0 code=128 comm=.searchbox:push pid=8752 grp=1 res=0
           ...
           <...>-9083  [003] dN.3 88396.535071: signal_generate: sig=1 errno=0 code=128 comm=zygote pid=11158 grp=1 res=0
           <...>-9083  [003] dN.3 88396.535073: signal_generate: sig=18 errno=0 code=128 comm=chmod pid=9083 grp=1 res=1
           <...>-9083  [003] dN.3 88396.535075: signal_generate: sig=18 errno=0 code=128 comm=ipayGphone:push pid=9024 grp=1 res=1
           <...>-9083  [003] dN.3 88396.535077: signal_generate: sig=18 errno=0 code=128 comm=m.taobao.taobao pid=8889 grp=1 res=1
           <...>-9083  [003] dN.3 88396.535079: signal_generate: sig=18 errno=0 code=128 comm=id.AlipayGphone pid=8824 grp=1 res=1
           <...>-9083  [003] dN.3 88396.535081: signal_generate: sig=18 errno=0 code=128 comm=.searchbox:push pid=8752 grp=1 res=1
           ...
           <...>-9083  [003] dN.3 88396.535363: signal_generate: sig=18 errno=0 code=128 comm=com.miui.core pid=11542 grp=1 res=1
           <...>-9083  [003] dN.3 88396.535365: signal_generate: sig=18 errno=0 code=128 comm=ndroid.systemui pid=11522 grp=1 res=1
           <...>-9083  [003] dN.3 88396.535368: signal_generate: sig=18 errno=0 code=128 comm=system_server pid=11430 grp=1 res=1
           <...>-9083  [003] dN.3 88396.535370: signal_generate: sig=18 errno=0 code=128 comm=zygote pid=11158 grp=1 res=1

从log中能清楚的看到，这个9083线程给包括zygote在内的所有进程发送SIGHUP(1)和SIGCONT(18)。

这就能进一步确定问题点可能就是这个kill_orphaned_pgrp()，

这个函数是进程退出流程中发现自己成了“孤儿进程”时才会调用的。

下一步只需要监控fork、exec、exit等系统调用即可。

打开fork、exec、exit的tracing开关，并抓取tracing log：

# echo 1 > /d/tracing/events/sched/sched_process_fork/enable
# echo 1 > /d/tracing/events/sched/sched_process_exec/enable
# echo 1 > /d/tracing/events/sched/sched_process_exit/enable
# cat /d/tracing/trace_pipe
           <...>-9024  [003] ...1 88396.515526: sched_process_fork: comm=ipayGphone:push pid=9024 child_comm=ipayGphone:push child_pid=9080
           <...>-9080  [001] ...1 88396.525226: sched_process_exec: filename=/system/bin/sh pid=9080 old_pid=9080
           <...>-9080  [001] ...1 88396.527560: sched_process_fork: comm=sh pid=9080 child_comm=sh child_pid=9083
           <...>-9083  [003] ...1 88396.528224: sched_process_exec: filename=/system/bin/chmod pid=9083 old_pid=9083
           <...>-9080  [001] ...1 88396.528496: sched_process_exit: comm=sh pid=9080 prio=120
           <...>-9083  [003] ...1 88396.530442: sched_process_exit: comm=chmod pid=9083 prio=120
           <...>-9083  [003] d..3 88396.530478: signal_generate: sig=1 errno=0 code=128 comm=chmod pid=9083 grp=1 res=0
           <...>-9083  [003] d..3 88396.530567: signal_generate: sig=1 errno=0 code=128 comm=ipayGphone:push pid=9024 grp=1 res=0
           <...>-9083  [003] d..3 88396.530728: signal_generate: sig=1 errno=0 code=128 comm=m.taobao.taobao pid=8889 grp=1 res=0
           <...>-9083  [003] d..3 88396.530891: signal_generate: sig=1 errno=0 code=128 comm=id.AlipayGphone pid=8824 grp=1 res=0
           <...>-9083  [003] d..3 88396.531072: signal_generate: sig=1 errno=0 code=128 comm=.searchbox:push pid=8752 grp=1 res=0
           <...>-9083  [003] d..3 88396.531088: signal_generate: sig=1 errno=0 code=128 comm=om.uc.searchbox pid=8596 grp=1 res=0
           <...>-9083  [003] d..3 88396.531146: signal_generate: sig=1 errno=0 code=128 comm=encent.mobileqq pid=7818 grp=1 res=0
           <...>-9083  [003] d..3 88396.531201: signal_generate: sig=1 errno=0 code=128 comm=viders.calendar pid=7797 grp=1 res=0
           <...>-9083  [003] d..3 88396.531258: signal_generate: sig=1 errno=0 code=128 comm=ndroid.calendar pid=7772 grp=1 res=0
           <...>-9083  [003] d..3 88396.531261: signal_generate: sig=1 errno=0 code=128 comm=com.miui.player pid=18654 grp=1 res=0
           <...>-9083  [003] d..3 88396.531340: signal_generate: sig=1 errno=0 code=128 comm=id.thememanager pid=18636 grp=1 res=0
           <...>-9083  [003] d..3 88396.531343: signal_generate: sig=1 errno=0 code=128 comm=ugreport:remote pid=15473 grp=1 res=0

从log中我们可以看到：

1、9083是chmod进程，是它在执行exit时发送signal给所有进程的。

2、chmod(9083)进程的父进程是sh(9080)，这个sh(9080)fork完chmod(9083)后先退出。

3、sh(9080)正是阿里系应用com.eg.android.AlipayGphone应用的ipayGphone:push(9024)线程创建的。

这个log和之前的推理完全吻合，且多次验证后都是相同的时序。

我们再看看kill_orphaned_pgrp()发送SIGHUP的几个条件:

1、task_pgrp(parent) != pgrp

由chmod(9083)的父进程sh(9080)已经退出，因此它就会被托管到init(1)，它的parent是init。

init的pgrp是init自己,

而zygote(所有其他被init fork出来的native服务都相同)被init fork出来后，会调用setpgid()将自己的pgrp设置成自己：

@system/core/init.cpp

void service_start(struct service *svc, const char *dynamic_args)
{
    ...
    pid_t pid = fork();
    if (pid == 0) {
       ...
       setpgid(0, getpid());

zygote的子孙进程如没有显式调用setpgid()，则他们的pgrp都是zygote，如chmod。

因此这判断条件是满足的，不过要注意，必须是chmod在退出前，它的父进程sh要先退出，不然这个条件不会得到满足。

2、task_session(parent) == task_session(tsk)

Android下一般所有进程的session都指向swapper(0)进程，所以这个条件也满足

3、will_become_orphaned_pgrp(pgrp, ignored_task)

static int will_become_orphaned_pgrp(struct pid *pgrp, struct task_struct *ignored_task)
{
    struct task_struct *p;

    do_each_pid_task(pgrp, PIDTYPE_PGID, p) {
        if ((p == ignored_task) ||
            (p->exit_state && thread_group_empty(p)) ||
            is_global_init(p->real_parent))  // 这里排除了zygote，因为zygote的父进程是init
            continue;

        if (task_pgrp(p->real_parent) != pgrp &&
            task_session(p->real_parent) == task_session(p))
            return 0;
    } while_each_pid_task(pgrp, PIDTYPE_PGID, p);

    return 1;
}

这个函数在遍历当前进程组内的所有进程（除了zygote），如果它的父进程的pgrp合当前进程的pgrp不一样，则返回0，否则返回1。

前面已经说过，zygote的子孙进程，他们的pgrp都是zygote，因此，这个函数必然返回1，条件满足。

4、has_stopped_jobs(pgrp)

这个条件是判断进程组内有没有stop的进程，而出现问题时，前台有《神马搜索》在NE，

出现NE时Debuggerd进程会stop目标进程，然后再打印目标进程的tombstone。

因此这个条件也是有可能满足的。

看起来四个条件都能满足，其中2、3是必然条件，而1、4得有一定概率能满足。

为了提高复现概率，自己写了个app将1、4做成必然条件：

@HelloAndroid.java

public class HelloAndroid extends Activity {
    private static final String LOG_TAG = "PARK";

    static {
        try {
            System.loadLibrary("helloandroid");
        } catch (UnsatisfiedLinkError e) {
            e.printStackTrace();
        }
    }

    public static native void native_function();
    @Override
    public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.main);
            native_function();
            while(true) {
                try {
                     Thread.sleep(1000);
                } catch(Exception e) {
                }
            }
        }
}

@com_xl_helloandroid.cpp

static void native_function(){

    int child0= fork();
    if(child0 > 0) {
        int stop_proc = fork();

        if(stop_proc > 0) {
            kill(stop_proc,19);     // 制造stop进程来满足条件4        
        } else {
            while(true) {
                LOGD("stop_proc loop");
                sleep(1);
            }
        }
    } else {
        int child1 = fork();
        if(child1 > 0) {
            LOGD("parent..exit");   // 父进程退出，子进程的父进程会变成init，满足条件1
            exit(-1);
        } else {
            LOGD("child");
            sleep(5);
            LOGD("child exit..");
            exit(-1);               
        }
    }
}

编出APK后，在NEXUS4 4.4版本和NEXUS5 5.1.1、6.0版本上都能必现问题。

不过这个APK放到64位机器上却不能复现问题，原来64位机器上有两个zygote。

32位APP的父进程是zygote32，64位APP的父进程是zygote64。

但无论是32位APP还是64位APP，他们的pgrp都是zygote64。

因为在zygote在收到ActivityManagerService的socket请求，fork出子进程后，要修改子进程的pgrp。

@framework/base/core/java/com/android/internal/os/ZygoteConnection.java

    private boolean handleParentProc(int pid,
            FileDescriptor[] descriptors, FileDescriptor pipeFd, Arguments parsedArgs) {

        if (pid > 0) {
            setChildPgid(pid);
        }

        if (descriptors != null) {
            for (FileDescriptor fd: descriptors) {
                IoUtils.closeQuietly(fd);
            }
        }

    private void setChildPgid(int pid) {
        // Try to move the new child into the peer's process group.
        try {
            Os.setpgid(pid, Os.getpgid(peer.getPid()));
        } catch (ErrnoException ex) {
            // This exception is expected in the case where
            // the peer is not in our session
            // TODO get rid of this log message in the case where
            // getsid(0) != getsid(peer.getPid())
            Log.i(TAG, "Zygote: setpgid failed. This is "
                + "normal if peer is not in our session");
        }
    }

这里的peer.getPid()是system_server的pid。

system_server的pgid是zygote64，因此所有APP的pgrp被设置成zygote64。

我们再回过头来看条件3：

static int will_become_orphaned_pgrp(struct pid *pgrp, struct task_struct *ignored_task)
{
    struct task_struct *p;

    do_each_pid_task(pgrp, PIDTYPE_PGID, p) {
        if ((p == ignored_task) ||
            (p->exit_state && thread_group_empty(p)) ||
            is_global_init(p->real_parent)) 
            continue;

        if (task_pgrp(p->real_parent) != pgrp &&
            task_session(p->real_parent) == task_session(p))
            return 0;
    } while_each_pid_task(pgrp, PIDTYPE_PGID, p);

    return 1;
}

在遍历zygote64进程组时，必然有进程不满足下面这个条件：

task_pgrp(p->real_parent) != pgrp

因为对于32位APP来说，它的父进程是zygote32，而zygote32的pgrp是它自己。

所以在64位机器上，这个条件是必然不满足的，所以也不会重启。

到此，所有的疑惑都已经解决了，给aosp反馈问题，但收到的回复是暂时不改。

我们也决定不改，原因有如下几点：

1、这个问题是app的特殊行为引起的。

2、时间窗口实际上很小是tombstone的时长，只不过因为我们加的调试代码，把tombstone的时长拉长了，导致问题的概率增加。

3、64位下不会有问题。

后面遇到问题，再去考虑如何修复吧。