gdb的远程调试

gdb的远程调试通过gdbserver和gdb配合完成， 在目标主机上运行gdbserver，宿主主机上通过gdb与gdbserver通信进行调试。

例如，需要调试目标机器上的chromium。
首先通过gdbserver来attach到需要被调试的chromium进程。gdbsever需要指定gdb与server通信的方式，通常采用TCP的方式，假设gdbserver在目标主机上的监听地址为”:8899″ (127.0.0.1:8899),下面的命令完成这一步周：

target$gdbserver :8899 --attach 13506
Attached; pid = 13506
Listening on port 8899
Remote debugging from host 127.0.0.1

Chromium浏览器中的Sandbox机制与实现（3）Seccomp sandbox

安全计算模式Seccomp（Secure Computing Mode） 是自Linux 2.6.10之后引入到kernel的特性，在进程进入了seccomp之后，它只能调用exit(), sigreturn(), read()和write()这几个系统调用(对应的文件描述符是在进入seccomp之前打开)，其他的任何的系统调用都会引起内核发送SIGKILL信号结束进程。进程通过下面的代码进入Secure Computing模式：

prctl(PR_SET_SECCOMP, 1, 0, 0, 0);
//after this point, any system call other than exit,signreturn, read, write shall cause SIGKILL

在Chromium中，Seccomp Sandbox是Linux平台sandbox的另外一个重要的机制，它独立于上一篇讲的SUID Sandbox。在Chromium中，可以通过”–disable-seccomp-sandbox”和”–enable-seccomp-sandbox”来关闭或者打开Seccomp Sandbox。Chromium 15以后的版本都是默认打开seccomp sandbox， 通过ps，可以看到在打开一个tab的情况下，有如下几个chrome进程。

Chromium浏览器中的Sandbox机制与实现（2） SUID sandbox

本篇主要探讨Chromium中的SUID sandbox的实现。

1. Chromium中的Zygote机制

首先介绍一下Chromium中的zygote机制， 我们知道Chromium是多进程架构的，主要由一个UI进程（Browser），和多个渲染进程（Renderer）组成。 在一个新Tab中打开URL，chromium会创建一个新的Renderer进程对应于这个tab， 同时在UI进程（Browser）中创建Render Host对象负责与该Renderer进程交互。在Linux中，创建新的Renderer进程是通过Zygote来完成的。
执行”ps ax |grep chrome”, 我们可以看到下面几个进程

21696 pts/0    Sl+    0:15 /chromium/src/out/Debug/chrome
21736 pts/0    Sl+    0:00 /chromium/src/out/Debug/chrome
21738 pts/0    S+     0:00 /chromium/src/out/Debug/chrome --type=zygote
21761 pts/0    Sl+    5:03 /chromium/src/out/Debug/chrome --type=renderer --lang=zh-CN

Chromium浏览器中的Sandbox机制与实现 (1) 概览

安全问题是浏览器所必须面对的，在Chromium中，通过Sandbox为浏览器提供了更好的安全性支持。本系列文章主要介绍Linux平台上的Chromium Sandbox的原理与实现

Chromium中，Sandbox设计的主要原则包括：

• 不重新发明轮子： 只利用现有操作系统已经提供的安全机制
• 最低权限原则：Sandbox中的进程只拥有最低权限
• 假定Sandbox中的代码都是恶意代码
• Sandbox的设计必须是灵巧的： 非恶意的代码不应该访问它没有权限访问的内容
• 模拟环境是不安全的：模拟器和虚拟机环境并不能够提供自身的安全性

宏的可变参数

C语言函数中的可变参数通过va_list和va_arg实现，利用了函数调用过程中，参数采用栈进行传递的方法。 比如

void debug_print(char *format, ...)
{
  va_list args;
  va_begin(args, format);
  vaprintf(format, args);
  va_end(args);
}

在宏定义里面同样可以使用可变参数__VA_ARGS__ (C99)

#define DEBUG_PRINT(...)  fprintf(stdout, __VA_ARGS__);

或者采用gcc扩展的方法：

#define DEBUG_PRINT(fmt, args...) fprintf(stdout, fmt, ##args)

Patch中的空文件

通过版本管理工具生成的patch中若包含空文件， 直接用patch在目标项目中去应用这个补丁，这个空文件不会被patch创建，这是因为patch会自动忽略掉补丁中的空文件。
例如，version0 和version1分别是同一个git项目的两个版本拷贝

$ ls version0/
001.txt
$ ls version1/
001.txt  002.txt

version1比version0多了一个002.txt的空文件， 用git diff生成test.patch

$cat test.patch
diff --git a/002.txt b/002.txt
new file mode 100644
index 0000000..e69de29

然后再version01中用patch命令应用test.path，出现提示“Only garbage was found…”

$ patch -p1

解决方法： 利用版本管理工具去应用补丁， 比如git中，利用“git apply”去打补丁。

$ git apply ../test.patch

一般情况下，很少直接创建空文件并提交， 但是这种情况一般发生在python package中， python package需要在目录中有个__init__.py文件
__init__.py是个空文件， 在patch的时候，目标目录中并不会创建这个文件， 如果直接用patch命令，于是悲剧发生了…

Traceback (most recent call last):
  File "gyp/gyp", line 18, in
    sys.exit(gyp.main(sys.argv[1:]))
  File "gyp/pylib/gyp/__init__.py", line 436, in main
    options.circular_check)
  File "gyp/pylib/gyp/__init__.py", line 55, in Load
    generator = __import__(generator_name, globals(), locals(), generator_name)
ImportError: No module named generator.make

另外一种解决方法 提交的__init__.py中插入一些空格字符或者注释，以避免上述情况的发生。