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)=[{"\0\0]�", 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)=[{"\0", 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位下不会有问题。
后面遇到问题，再去考虑如何修复吧。
