1.7.1 init386()

　　init386()定义在 sys/i386/i386/machdep.c中， 它针对Intel 386芯片进行低级初始化。loader已将CPU切换至保护模式。 loader已经建立了最早的任务。

• 初始化内核的可调整参数，这些参数由引导程序传来

• 准备GDT(全局描述符表)

• 准备IDT(中断描述符表)

• 初始化系统控制台

• 初始化DDB(内核的点调试器)，如果它被编译进内核的话

• 初始化TSS(任务状态段)

• 准备LDT(局部描述符表)

• 建立proc0(0号进程，即内核的进程)的pcb(进程控制块)

　　init386()首先初始化内核的可调整参数， 这些参数由引导程序传来。先设置环境指针(environment pointer, envp)调用， 再调用init_param1()。 envp指针已由loader存放在结构bootinfo中:

sys/i386/i386/machdep.c:
        kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;

    /* 初始化基本可调整项,如hz等 */
    init_param1();

　　init_param1()定义在 sys/kern/subr_param.c之中。 这个文件里有一些sysctl项，还有两个函数， init_param1()和init_param2()。 这两个函数从init386()中调用:

sys/kern/subr_param.c
    hz = HZ;
    TUNABLE_INT_FETCH("kern.hz", &hz);

　　TUNABLE_<typename>_FETCH用来获取环境变量的值:

/usr/src/sys/sys/kernel.h
#define TUNABLE_INT_FETCH(path, var)    getenv_int((path), (var))

　　Sysctlkern.hz是系统时钟频率。同时， 这些sysctl项被init_param1()设定: kern.maxswzone, kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.maxdsiz, kern.dflssiz, kern.maxssiz, kern.sgrowsiz。

　　然后init386() 准备全局描述符表 (Global Descriptors Table, GDT)。在x86上每个任务都运行在自己的虚拟地址空间里， 这个空间由"段址:偏移量"的数对指定。举个例子，当前将要由处理器执行的指令在 CS:EIP，那么这条指令的线性虚拟地址就是“代码段虚拟段地址CS” + EIP。 为了简便，段起始于虚拟地址0，终止于界限4G字节。所以，在这个例子中， 指令的线性虚拟地址正是EIP的值。段寄存器，如CS、DS等是选择符， 即全局描述符表中的索引(更精确的说，索引并非选择符的全部， 而是选择符中的INDEX部分)。

sys/i386/i386/machdep.c:
union descriptor gdt[NGDT * MAXCPU];    /* 全局描述符表 */

sys/i386/include/segments.h:
/*
 * 全局描述符表(GDT)中的入口
 */
#define GNULL_SEL   0   /* 空描述符 */
#define GCODE_SEL   1   /* 内核代码描述符 */
#define GDATA_SEL   2   /* 内核数据描述符 */
#define GPRIV_SEL   3   /* 对称多处理(SMP)每处理器专有数据 */
#define GPROC0_SEL  4   /* Task state process slot zero and up, 任务状态进程 */
#define GLDT_SEL    5   /* 每个进程的局部描述符表 */
#define GUSERLDT_SEL    6   /* 用户自定义的局部描述符表 */
#define GTGATE_SEL  7   /* 进程任务切换关口 */
#define GBIOSLOWMEM_SEL 8   /* BIOS低端内存访问(必须是这第8个入口) */
#define GPANIC_SEL  9   /* 会导致全系统异常中止工作的任务状态 */
#define GBIOSCODE32_SEL 10  /* BIOS接口(32位代码) */
#define GBIOSCODE16_SEL 11  /* BIOS接口(16位代码) */
#define GBIOSDATA_SEL   12  /* BIOS接口(数据) */
#define GBIOSUTIL_SEL   13  /* BIOS接口(工具) */
#define GBIOSARGS_SEL   14  /* BIOS接口(自变量，参数) */

　　请注意，这些#defines并非选择符本身，而只是选择符中的INDEX域， 因此它们正是全局描述符表中的索引。 例如，内核代码的选择符(GCODE_SEL)的值为0x08。

　　下一步是初始化中断描述符表(Interrupt Descriptor Table, IDT)。 这张表在发生软件或硬件中断时会被处理器引用。例如，执行系统调用时， 用户应用程序提交INT 0x80 指令。这是一个软件中断， 处理器用索引值0x80在中断描述符表中查找记录。这个记录指向处理这个中断的例程。 在这个特定情形中，这是内核的系统调用关口。

sys/i386/i386/machdep.c:
static struct gate_descriptor idt0[NIDT];
struct gate_descriptor *idt = &idt0[0]; /* 中断描述符表 */

　　每个中断都被设置一个合适的中断处理程序。 系统调用关口INT 0x80也是如此:

sys/i386/i386/machdep.c:
    setidt(0x80, &IDTVEC(int0x80_syscall),
            SDT_SYS386TGT, SEL_UPL, GSEL(GCODE_SEL, SEL_KPL));

　　所以当一个用户应用程序提交INT 0x80指令时， 全系统的控制权会传递给函数_Xint0x80_syscall， 这个函数在内核代码段中，将被以管理员权限执行。

　　然后，控制台和DDB(调试器)被初始化:

sys/i386/i386/machdep.c:
    cninit();
/* 以下代码可能因为未定义宏DDB而被跳过 */
#ifdef DDB
    kdb_init();
    if (boothowto & RB_KDB)
        Debugger("Boot flags requested debugger");
#endif

　　任务状态段(TSS)是另一个x86保护模式中的数据结构。当发生任务切换时， 任务状态段用来让硬件存储任务现场信息。

　　局部描述符表(LDT)用来指向用户代码和数据。系统定义了几个选择符， 指向局部描述符表，它们是系统调用关口和用户代码、用户数据选择符:

/usr/include/machine/segments.h
#define LSYS5CALLS_SEL  0   /* Intel BCS强制要求的 */
#define LSYS5SIGR_SEL   1
#define L43BSDCALLS_SEL 2   /* 尚无 */
#define LUCODE_SEL  3
#define LSOL26CALLS_SEL 4   /* Solaris >=2.6版系统调用关口 */
#define LUDATA_SEL  5
/* separate stack, es,fs,gs sels ? 分别的栈、es、fs、gs选择符？ */
/* #define  LPOSIXCALLS_SEL 5*/ /* notyet, 尚无 */
#define LBSDICALLS_SEL  16  /* BSDI system call gate, BSDI系统调用关口 */
#define NLDT        (LBSDICALLS_SEL + 1)

　　然后，proc0(0号进程，即内核所处的进程)的进程控制块(Process Control Block) (struct pcb)结构被初始化。proc0是一个 struct proc 结构，描述了一个内核进程。 内核运行时，该进程总是存在，所以这个结构在内核中被定义为全局变量:

sys/kern/kern_init.c:
    struct  proc proc0;

　　结构struct pcb是proc结构的一部分， 它定义在/usr/include/machine/pcb.h之中， 内含针对i386硬件结构专有的信息，如寄存器的值。

1.7.2 mi_startup()

　　这个函数用冒泡排序算法，将所有系统初始化对象，然后逐个调用每个对象的入口:

sys/kern/init_main.c:
    for (sipp = sysinit; *sipp; sipp++) {

        /* ... 省略 ... */

        /* 调用函数 */
        (*((*sipp)->func))((*sipp)->udata);
        /* ... 省略 ... */
    }

　　尽管sysinit框架已经在《FreeBSD开发者手册》中有所描述， 我还是在这里讨论一下其内部原理。

　　每个系统初始化对象(sysinit对象)通过调用宏建立。 让我们以announce sysinit对象为例。 这个对象打印版权信息:

sys/kern/init_main.c:
static void
print_caddr_t(void *data __unused)
{
    printf("%s", (char *)data);
}
SYSINIT(announce, SI_SUB_COPYRIGHT, SI_ORDER_FIRST, print_caddr_t, copyright)

　　这个对象的子系统标识是SI_SUB_COPYRIGHT(0x0800001)， 数值刚好排在SI_SUB_CONSOLE(0x0800000)后面。 所以，版权信息将在控制台初始化之后就被很早的打印出来。

　　让我们看一看宏SYSINIT()到底做了些什么。 它展开成宏C_SYSINIT()。 宏C_SYSINIT()然后展开成一个静态结构 struct sysinit。结构里申明里调用了另一个宏 DATA_SET:

/usr/include/sys/kernel.h:
      #define C_SYSINIT(uniquifier, subsystem, order, func, ident) \
      static struct sysinit uniquifier ## _sys_init = { \ subsystem, \
      order, \ func, \ ident \ }; \ DATA_SET(sysinit_set,uniquifier ##
      _sys_init);

#define SYSINIT(uniquifier, subsystem, order, func, ident)  \
    C_SYSINIT(uniquifier, subsystem, order,         \
    (sysinit_cfunc_t)(sysinit_nfunc_t)func, (void *)ident)

　　宏DATA_SET()展开成MAKE_SET()， 宏MAKE_SET()指向所有隐含的sysinit幻数:

/usr/include/linker_set.h
#define MAKE_SET(set, sym)                      \
    static void const * const __set_##set##_sym_##sym = &sym;   \
    __asm(".section .set." #set ",\"aw\"");             \
    __asm(".long " #sym);                       \
    __asm(".previous")
#endif
#define TEXT_SET(set, sym) MAKE_SET(set, sym)
#define DATA_SET(set, sym) MAKE_SET(set, sym)

　　回到我们的例子中，经过宏的展开过程，将会产生如下声明:

static struct sysinit announce_sys_init = {
    SI_SUB_COPYRIGHT,
    SI_ORDER_FIRST,
    (sysinit_cfunc_t)(sysinit_nfunc_t)  print_caddr_t,
    (void *) copyright
};

static void const *const __set_sysinit_set_sym_announce_sys_init =
    &announce_sys_init;
__asm(".section .set.sysinit_set" ",\"aw\"");
__asm(".long " "announce_sys_init");
__asm(".previous");

　　第一个__asm指令在内核可执行文件中建立一个ELF节(section)。 这发生在内核链接的时候。这一节将被命令为.set.sysinit_set。 这一节的内容是一个32位值——announce_sys_init结构的地址，这个结构正是第二个 __asm指令所定义的。第三个__asm指令标记节的结束。 如果前面有名字相同的节定义语句，节的内容(那个32位值)将被填加到已存在的节里， 这样就构造出了一个32位指针数组。

　　用objdump察看一个内核二进制文件， 也许你会注意到里面有这么几个小的节:

% objdump -h /kernel
  7 .set.cons_set 00000014  c03164c0  c03164c0  002154c0  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .set.kbddriver_set 00000010  c03164d4  c03164d4  002154d4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .set.scrndr_set 00000024  c03164e4  c03164e4  002154e4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 10 .set.scterm_set 0000000c  c0316508  c0316508  00215508  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 11 .set.sysctl_set 0000097c  c0316514  c0316514  00215514  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 12 .set.sysinit_set 00000664  c0316e90  c0316e90  00215e90  2**2
                  CONTENTS, ALLOC, LOAD, DATA

　　这一屏信息显示表明节.set.sysinit_set有0x664字节的大小， 所以0x664/sizeof(void *)个sysinit对象被编译进了内核。 其它节，如.set.sysctl_set表示其它链接器集合。

　　通过定义一个类型为struct linker_set的变量， 节.set.sysinit_set将被“收集”到那个变量里:

sys/kern/init_main.c:
      extern struct linker_set sysinit_set; /* XXX */

　　struct linker_set定义如下:

/usr/include/linker_set.h:
  struct linker_set {
    int ls_length;
    void    *ls_items[1];       /* ls_length个项的数组, 以NULL结尾 */
};

　　回到对mi_startup()的讨论， 我们清楚了sysinit对象是如何被组织起来的。 函数mi_startup()将它们排序， 并调用每一个对象。最后一个对象是系统调度器:

/usr/include/sys/kernel.h:
enum sysinit_sub_id {
    SI_SUB_DUMMY        = 0x0000000,    /* 不被执行，仅供链接器使用 */
    SI_SUB_DONE     = 0x0000001,    /* 已被处理*/
    SI_SUB_CONSOLE      = 0x0800000,    /* 控制台*/
    SI_SUB_COPYRIGHT    = 0x0800001,    /* 最早使用控制台的对象 */
...
    SI_SUB_RUN_SCHEDULER    = 0xfffffff /* 调度器:不返回 */
};

　　系统调度器sysinit对象定义在文件sys/vm/vm_glue.c中， 这个对象的入口点是scheduler()。 这个函数实际上是个无限循环，它表示那个进程标识(PID)为0的进程——swapper进程。 前面提到的proc0结构正是用来描述这个进程。

　　第一个用户进程是init， 由sysinit对象init建立:

sys/kern/init_main.c:
static void
create_init(const void *udata __unused)
{
    int error;
    int s;

    s = splhigh();
    error = fork1(&proc0, RFFDG | RFPROC, &initproc);
    if (error)
        panic("cannot fork init: %d\n", error);
    initproc->p_flag |= P_INMEM | P_SYSTEM;
    cpu_set_fork_handler(initproc, start_init, NULL);
    remrunqueue(initproc);
    splx(s);
}
SYSINIT(init,SI_SUB_CREATE_INIT, SI_ORDER_FIRST, create_init, NULL)

　　create_init()通过调用fork1() 分配一个新的进程，但并不将其标记为可运行。当这个新进程被调度器调度执行时， start_init()将会被调用。 那个函数定义在init_main.c中。 它尝试装载并执行二进制代码init， 先尝试/sbin/init，然后是/sbin/oinit， /sbin/init.bak，最后是/stand/sysinstall:

sys/kern/init_main.c:
static char init_path[MAXPATHLEN] =
#ifdef  INIT_PATH
    __XSTRING(INIT_PATH);
#else
    "/sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall";
#endif

3.3.1 结构

struct kobj_method

3.3.2 函数

void kobj_class_compile(kobj_class_t cls);
void kobj_class_compile_static(kobj_class_t cls, kobj_ops_t ops);
void kobj_class_free(kobj_class_t cls);
kobj_t kobj_create(kobj_class_t cls, struct malloc_type *mtype, int mflags);
void kobj_init(kobj_t obj, kobj_class_t cls);
void kobj_delete(kobj_t obj, struct malloc_type *mtype);

3.3.3 宏

KOBJ_CLASS_FIELDS
KOBJ_FIELDS
DEFINE_CLASS(name, methods, size)
KOBJMETHOD(NAME, FUNC)

3.3.4 头文件

<sys/param.h>
<sys/kobj.h>

3.3.5 建立一个接口的模板

　　使用Kobj的第一步是建立一个接口。建立接口包括建立模板的工作。 建立模板可用脚本src/sys/kern/makeobjops.pl完成， 它会产生申明方法的头文件和代码，脚本还会生成方法查找函数。

　　在这个模板中如下关键词会被使用: #include, INTERFACE, CODE, METHOD, STATICMETHOD, 和 DEFAULT.

　　#include语句的整行内容将被一字不差的 复制到被生成的代码文件的头部。

　　例如:

#include <sys/foo.h>

　　关键词INTERFACE用来定义接口名。 这个名字将与每个方法名接合在一起，形成 [interface name]_[method name]。 语法是：INTERFACE [接口名];

　　例如:

INTERFACE foo;

　　关键词CODE会将它的参数一字不差的复制到代码文件中。 语法是CODE { [任何代码] };

　　例如:

CODE {
    struct foo * foo_alloc_null(struct bar *)
    {
        return NULL;
}
};

　　关键词METHOD用来描述一个方法。语法是: METHOD [返回值类型] [方法名] { [对象 [, 参数若干]] };

　　例如:

METHOD int bar {
    struct object *;
    struct foo *;
    struct bar;
};

　　关键词DEFAULT跟在关键词METHOD之后， 是对关键词METHOD的补充。它给这个方法补充上缺省函数。语法是： METHOD [返回值类型] [方法名] { [对象; [其它参数]] }DEFAULT [缺省函数];

　　例如:

METHOD int bar {
    struct object *;
    struct foo *;
    int bar;
} DEFAULT foo_hack;

　　关键词STATICMETHOD类似关键词METHOD。 对于每个Kobj对象，一般其头部都有一些Kobj专有的数据。 METHOD定义的方法就假设这些专有数据位于对象头部； 假如对象头部没有这些专有数据，这些方法对这个对象的访问就可能出错。 而STATICMETHOD定义的对象可以不受这个限制： 这样描述出的方法，其操作的数据不由这个类的某个对象实例给出， 而是全都由调用这个方法时的操作数(译者注:即参数)给出。 这也对于在某个类的方法表之外调用这个方法有用。

　　其它完整的例子:

src/sys/kern/bus_if.m
src/sys/kern/device_if.m

3.3.6 建立一个类

　　使用Kobj的第二步是建立一个类。一个类的组有名字、方法表； 假如使用了Kobj的“对象管理工具”(Object Handling Facilities)， 类中还包含对象的大小。建立类时使用宏DEFINE_CLASS()。 建立方法表时，须建立一个kobj_method_t数组，用NULL项结尾。 每个非NULL项可用宏KOBJMETHOD()建立。

　　例如:

DEFINE_CLASS(fooclass, foomethods, sizeof(struct foodata));

kobj_method_t foomethods[] = {
    KOBJMETHOD(bar_doo, foo_doo),
    KOBJMETHOD(bar_foo, foo_foo),
    { NULL, NULL}
};

　　类须被“编译”。根据该类被初始化时系统的状态， 将要用到一个静态分配的缓存和“操作数表”(ops table， 译者注：即“参数表”)。这些操作可通过声明一个结构体 struct kobj_ops并使用 kobj_class_compile_static()， 或是只使用kobj_class_compile()来完成。

3.3.7 建立一个对象

　　使用Kobj的第三步是定义对象。Kobj对象建立程序假定Kobj 专有数据在一个对象的头部。如果不是如此，应当先自行分配对象， 再使用kobj_init()初始化对象中的Kobj专有数据； 其实可以使用kobj_create()分配对象， 并自动初始化对象中的Kobj专有内容。kobj_init() 也可以用来改变一个对象所使用的类。

　　将Kobj的数据集成到对象中要使用宏KOBJ_FIELDS。

　　例如

struct foo_data {
    KOBJ_FIELDS;
    foo_foo;
    foo_bar;
};

3.3.8 调用方法

　　使用Kobj的最后一部就是通过生成的函数调用对象类中的方法。 调用时，接口名与方法名用'_'接合，而且全部使用大写字母。

　　例如，接口名为foo，方法为bar，调用就是:

[返回值 = ] FOO_BAR(对象 [, 其它参数]);

3.3.9 善后处理

　　当一个用kobj_create()不再需要被使用时， 可对这个对象调用kobj_delete()。 当一个类不再需要被使用时， 可对这个类调用kobj_class_free()。

4.1.1 用户级代码

　　Jail的用户级源代码在/usr/src/usr.sbin/jail， 由一个文件jail.c组成。这个程序有这些参数：jail的路径， 主机名，IP地址，还有需要执行的命令。

/usr/include/sys/jail.h: 

struct jail {
        u_int32_t       version;
        char            *path;
        char            *hostname;
        u_int32_t       ip_number;
};

/usr/src/usr.sbin/jail.c
char path[PATH_MAX];
...
if(realpath(argv[0], path) == NULL)
    err(1, "realpath: %s", argv[0]);
if (chdir(path) != 0)
    err(1, "chdir: %s", path);
memset(&j, 0, sizeof(j));
j.version = 0; 
j.path = path;
j.hostname = argv[1];

/usr/src/usr.sbin/jail/jail.c:
struct in_addr in; 
... 
if (inet_aton(argv[2], &in) == 0)
    errx(1, "Could not make sense of ip-number: %s", argv[2]);
j.ip_number = ntohl(in.s_addr);

/usr/src/usr.sbin/jail/jail.c
i = jail(&j); 
...
if (execv(argv[3], argv + 3) != 0)
    err(1, "execv: %s", argv[3]);

4.1.2 相关的内核源代码

　　现在我们来看文件/usr/src/sys/kern/kern_jail.c。 在这里定义了jail(2)的系统调用、相关的sysctl项，还有网络函数。

/usr/src/sys/kern/kern_jail.c:

int     jail_set_hostname_allowed = 1;
SYSCTL_INT(_security_jail, OID_AUTO, set_hostname_allowed, CTLFLAG_RW,
    &jail_set_hostname_allowed, 0,
    "Processes in jail can set their hostnames");
    /* Jail中的进程可设定自身的主机名 */

int     jail_socket_unixiproute_only = 1;
SYSCTL_INT(_security_jail, OID_AUTO, socket_unixiproute_only, CTLFLAG_RW,
    &jail_socket_unixiproute_only, 0,
    "Processes in jail are limited to creating UNIX/IPv4/route sockets only");
    /* Jail中的进程被限制只能建立UNIX套接字、IPv4套接字、路由套接字 */

int     jail_sysvipc_allowed = 0;
SYSCTL_INT(_security_jail, OID_AUTO, sysvipc_allowed, CTLFLAG_RW,
    &jail_sysvipc_allowed, 0,
    "Processes in jail can use System V IPC primitives");
    /* Jail中的进程可以使用System V进程间通讯原语 */

static int jail_enforce_statfs = 2;
SYSCTL_INT(_security_jail, OID_AUTO, enforce_statfs, CTLFLAG_RW,
    &jail_enforce_statfs, 0,
    "Processes in jail cannot see all mounted file systems");
    /* jail 中的进程查看系统中挂接的文件系统时受到何种限制 */

int    jail_allow_raw_sockets = 0;
SYSCTL_INT(_security_jail, OID_AUTO, allow_raw_sockets, CTLFLAG_RW,
    &jail_allow_raw_sockets, 0,
    "Prison root can create raw sockets");
    /* jail 中的 root 用户是否可以创建 raw socket */

int    jail_chflags_allowed = 0;
SYSCTL_INT(_security_jail, OID_AUTO, chflags_allowed, CTLFLAG_RW,
    &jail_chflags_allowed, 0,
    "Processes in jail can alter system file flags");
    /* jail 中的进程是否可以修改系统级文件标记 */

int     jail_mount_allowed = 0;
SYSCTL_INT(_security_jail, OID_AUTO, mount_allowed, CTLFLAG_RW,
    &jail_mount_allowed, 0,
    "Processes in jail can mount/unmount jail-friendly file systems");
    /* jail 中的进程是否可以挂载或卸载对jail友好的文件系统 */

/usr/src/sys/kern/kern_jail.c:
/*
 * struct jail_args {
 *      struct jail *jail;
 * };
 */
int
jail(struct thread *td, struct jail_args *uap)

/usr/src/sys/kern/kern_jail.c: 
error = copyin(uap->jail, &j, sizeof(j));

/usr/include/sys/jail.h:
struct prison {
        LIST_ENTRY(prison) pr_list;                     /* (a) all prisons */
        int              pr_id;                         /* (c) prison id */
        int              pr_ref;                        /* (p) refcount */
        char             pr_path[MAXPATHLEN];           /* (c) chroot path */
        struct vnode    *pr_root;                       /* (c) vnode to rdir */
        char             pr_host[MAXHOSTNAMELEN];       /* (p) jail hostname */
        u_int32_t        pr_ip;                         /* (c) ip addr host */
        void            *pr_linux;                      /* (p) linux abi */
        int              pr_securelevel;                /* (p) securelevel */
        struct task      pr_task;                       /* (d) destroy task */
        struct mtx       pr_mtx;
        void            **pr_slots;                     /* (p) additional data */
};

/usr/src/sys/kern/kern_jail.c:
MALLOC(pr, struct prison *, sizeof(*pr), M_PRISON, M_WAITOK | M_ZERO);
...
error = copyinstr(j.path, &pr->pr_path, sizeof(pr->pr_path), 0);
if (error)
    goto e_killmtx;
...
error = copyinstr(j.hostname, &pr->pr_host, sizeof(pr->pr_host), 0);
if (error)
        goto e_dropvnref;
pr->pr_ip = j.ip_number;

/usr/src/sys/kern/kern_jail.c
/*
 * struct jail_attach_args {
 *      int jid;
 * };
 */
int
jail_attach(struct thread *td, struct jail_attach_args *uap)

/usr/include/sys/proc.h: 
struct thread {
    ...
    struct proc *td_proc;
    ...
};
struct proc {
    ...
    struct ucred *p_ucred;
    ...
};
/usr/include/sys/ucred.h
struct ucred {
    ...
    struct prison *cr_prison;
    ...
};

/usr/src/sys/kern/kern_jail.c
int
jail(struct thread *td, struct jail_args *uap)
{
...
    struct jail_attach_args jaa;
...
    error = jail_attach(td, &jaa);
    if (error)
        goto e_dropprref;
...
}
  
int
jail_attach(struct thread *td, struct jail_attach_args *uap)
{
    struct proc *p;
    struct ucred *newcred, *oldcred;
    struct prison *pr;
...
    p = td->td_proc;
...
    pr = prison_find(uap->jid);
...
    change_root(pr->pr_root, td);
...
    newcred->cr_prison = pr;
    p->p_ucred = newcred;
...
}

/usr/src/sys/kern/kern_fork.c:
p2->p_ucred = crhold(td->td_ucred);
...
td2->td_ucred = crhold(p2->p_ucred);

4.2.1 SysV进程间通信(IPC)

　　System V 进程间通信 (IPC) 是通过消息实现的。 每个进程都可以向其它进程发送消息， 告诉对方该做什么。 处理消息的函数是： msgctl(3)、msgget(3)、msgsnd(3) 和 msgrcv(3)。前面已经提到，一些 sysctl 开关可以影响 jail 的行为， 其中有一个是 security.jail.sysvipc_allowed。 在大多数系统上， 这个 sysctl 项会设成0。 如果将它设为1， 则会完全失去 jail 的意义： 因为那样在 jail 中特权进程就可以影响被监禁的环境外的进程了。 消息与信号的区别是：消息仅由一个信号编号组成。

　　/usr/src/sys/kern/sysv_msg.c:

• msgget(key, msgflg): msgget返回(也可能创建)一个消息描述符， 以指派一个在其它函数中使用的消息队列。

• msgctl(msgid, cmd, buf): 通过这个函数， 一个进程可以查询一个消息描述符的状态。

• msgsnd(msgid, msgp, msgsz, msgflg): msgsnd向一个进程发送一条消息。

• msgrcv(msgid, msgp, msgsz, msgtyp, msgflg): 进程用这个函数接收消息。

　　在这些函数对应的系统调用的代码中，都有这样一个条件判断：

/usr/src/sys/kern/sysv_msg.c:
if (!jail_sysvipc_allowed && jailed(td->td_ucred))
    return (ENOSYS);

　　信号量系统调用使得进程可以通过一系列原子操作实现同步。 信号量为进程锁定资源提供了又一种途径。 然而，进程将为正在被使用的信号量进入等待状态，一直休眠到资源被释放。 在jail中如下的信号量系统调用将会失效: semget(2), semctl(2) 和semop(2)。

　　/usr/src/sys/kern/sysv_sem.c:

• semctl(semid, num, cmd, ...): semctl对在信号量队列中用semid标识的信号量执行cmd指定的命令。

• semget(key, nsems, flag): semget建立一个对应于key的信号量数组。

  参数key和flag与他们在msgget()的意义相同。

• setop(semid, array, nops): semop对semid标识的信号量完成一组由array所指定的操作。

　　System V IPC使进程间可以共享内存。进程之间可以通过它们虚拟地址空间 的共享部分以及相关数据读写操作直接通讯。这些系统调用在被监禁的环境中将会失效: shmdt(2)、shmat(2)、shmctl(2)和shmget(2)

　　/usr/src/sys/kern/sysv_shm.c:

• shmctl(shmid, cmd, buf): shmctl对id标识的共享内存区域做各种各样的控制。

• shmget(key, size, flag): shmget建立/打开size字节的共享内存区域。

• shmat(shmid, addr, flag): shmat将shmid标识的共享内存区域指派到进程的地址空间里。

• shmdt(addr): shmdt取消共享内存区域的地址指派。

4.2.2 套接字

　　Jail以一种特殊的方式处理socket(2)系统调用和相关的低级套接字函数。 为了决定一个套接字是否允许被创建，它先检查sysctl项 security.jail.socket_unixiproute_only是否被设置为1。 如果被设为1，套接字建立时将只能指定这些协议族： PF_LOCAL, PF_INET, PF_ROUTE。否则，socket(2)将会返回出错。

/usr/src/sys/kern/uipc_socket.c:
int
socreate(int dom, struct socket **aso, int type, int proto,
    struct ucred *cred, struct thread *td)
{
    struct protosw *prp;
...
    if (jailed(cred) && jail_socket_unixiproute_only &&
        prp->pr_domain->dom_family != PF_LOCAL &&
        prp->pr_domain->dom_family != PF_INET &&
        prp->pr_domain->dom_family != PF_ROUTE) {
        return (EPROTONOSUPPORT);
    }
...
}

4.2.3 Berkeley包过滤器

　　Berkeley包过滤器提供了一个与协议无关的，直接通向数据链路层的低级接口。 现在BPF是否可以在监禁的环境中被使用是通过devfs(8)来控制的。

4.2.4 网络协议

　　网络协议TCP, UDP, IP和ICMP很常见。IP和ICMP处于同一协议层次：第二层， 网络层。当参数nam被设置时， 有一些限制措施会防止被囚禁的程序绑定到一些网络接口上。 nam是一个指向sockaddr结构体的指针， 描述可以绑定服务的地址。一个更确切的定义：sockaddr“是一个模板，包含了地址的标识符和地址的长度”。 在函数in_pcbbind_setup()中sin是一个指向sockaddr_in结构体的指针， 这个结构体包含了套接字可以绑定的端口、地址、长度、协议族。 这就禁止了在jail中的进程指定不属于这个进程所存在于的jail的IP地址。

/usr/src/sys/kern/netinet/in_pcb.c: 
int
in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, in_addr_t *laddrp,
    u_short *lportp, struct ucred *cred)
{
    ...
    struct sockaddr_in *sin;
    ...
    if (nam) {
        sin = (struct sockaddr_in *)nam;
        ...
        if (sin->sin_addr.s_addr != INADDR_ANY)
            if (prison_ip(cred, 0, &sin->sin_addr.s_addr))
                return(EINVAL);
        ...
        if (lport) {
            ...
            if (prison && prison_ip(cred, 0, &sin->sin_addr.s_addr))
                return (EADDRNOTAVAIL);
            ...
        }
    }
    if (lport == 0) {
        ...
        if (laddr.s_addr != INADDR_ANY)
            if (prison_ip(cred, 0, &laddr.s_addr))
                return (EINVAL);
        ...
    }
...
    if (prison_ip(cred, 0, &laddr.s_addr))
        return (EINVAL);
...
}

　　你也许想知道函数prison_ip()做什么。 prison_ip()有三个参数，一个指向身份凭证的指针(用cred表示)， 一些标志和一个IP地址。当这个IP地址不属于这个jail时，返回1； 否则返回0。正如你从代码中看见的，如果，那个IP地址确实不属于这个jail， 就不再允许向这个网络地址绑定协议。

/usr/src/sys/kern/kern_jail.c:
int
prison_ip(struct ucred *cred, int flag, u_int32_t *ip)
{
    u_int32_t tmp;

    if (!jailed(cred))
        return (0);
    if (flag)
        tmp = *ip;
    else
        tmp = ntohl(*ip);
    if (tmp == INADDR_ANY) {
        if (flag)
            *ip = cred->cr_prison->pr_ip;
        else
            *ip = htonl(cred->cr_prison->pr_ip);
        return (0);
    }
    if (tmp == INADDR_LOOPBACK) {
        if (flag)
            *ip = cred->cr_prison->pr_ip;
        else
            *ip = htonl(cred->cr_prison->pr_ip);
        return (0);
    }
    if (cred->cr_prison->pr_ip != tmp)
        return (1);
    return (0);
}

4.2.5 文件系统

　　如果完全级别大于0，即便是jail里面的root， 也不允许在Jail中取消或更改文件标志，如“不可修改”、“只可添加”、“不可删除”标志。

/usr/src/sys/ufs/ufs/ufs_vnops.c:
static int
ufs_setattr(ap)
    ...
{
    ...
        if (!priv_check_cred(cred, PRIV_VFS_SYSFLAGS, 0)) {
            if (ip->i_flags
                & (SF_NOUNLINK | SF_IMMUTABLE | SF_APPEND)) {
                    error = securelevel_gt(cred, 0);
                    if (error)
                        return (error);
            }
            ...
        }
}
/usr/src/sys/kern/kern_priv.c
int
priv_check_cred(struct ucred *cred, int priv, int flags)
{
    ...
    error = prison_priv_check(cred, priv);
    if (error)
        return (error);
    ...
}
/usr/src/sys/kern/kern_jail.c
int
prison_priv_check(struct ucred *cred, int priv)
{
    ...
    switch (priv) {
    ...
    case PRIV_VFS_SYSFLAGS:
        if (jail_chflags_allowed)
            return (0);
        else
            return (EPERM);
    ...
    }
    ...
}

5.3.1 接口

<sys/kernel.h>

SYSINIT(uniquifier, subsystem, order, func, ident)
SYSUNINIT(uniquifier, subsystem, order, func, ident)

5.3.2 启动

　　宏SYSINIT()在SYSINIT启动数据集合中 建立一个SYSINIT数据项，以便SYSINIT在系统启动或模块加载时排序 并执行其中的函数。SYSINIT()有一个参数uniquifier， SYSINIT用它来标识数据项，随后是子系统顺序号、子系统元素顺序号、 待调用函数、传递给函数的数据。所有的函数必须有一个恒量指针参数。

#include <sys/kernel.h>

void foo_null(void *unused)
{
        foo_doo();
}
SYSINIT(foo, SI_SUB_FOO, SI_ORDER_FOO, foo_null, NULL);

struct foo foo_voodoo = {
        FOO_VOODOO;
}

void foo_arg(void *vdata)
{
        struct foo *foo = (struct foo *)vdata;
        foo_data(foo);
}
SYSINIT(bar, SI_SUB_FOO, SI_ORDER_FOO, foo_arg, &foo_voodoo);
   

　　注意，SI_SUB_FOO和SI_ORDER_FOO 应当分别在上面提到的枚举sysinit_sub_id和 sysinit_elem_order之中。既可以使用已有的枚举项， 也可以将自己的枚举项添加到这两个枚举的定义之中。 你可以使用数学表达式微调SYSINIT的执行顺序。 以下的例子示例了一个需要刚好要在内核参数调整的SYSINIT之前执行的SYSINIT。

static void
mptable_register(void *dummy __unused)
{

    apic_register_enumerator(&mptable_enumerator);
}

SYSINIT(mptable_register, SI_SUB_TUNABLES - 1, SI_ORDER_FIRST,
    mptable_register, NULL);

5.3.3 析构

　　宏SYSUNINIT()的行为与SYSINIT()的相当， 只是它将数据项填加至SYSINIT的析构数据集合。

#include <sys/kernel.h>

void foo_cleanup(void *unused)
{
        foo_kill();
}
SYSUNINIT(foobar, SI_SUB_FOO, SI_ORDER_FOO, foo_cleanup, NULL);

struct foo_stack foo_stack = {
        FOO_STACK_VOODOO;
}

void foo_flush(void *vdata)
{
}
SYSUNINIT(barfoo, SI_SUB_FOO, SI_ORDER_FOO, foo_flush, &foo_stack);
   

6.5.1 内核元素

　　MAC 框架由下列内核元素组成：

• 框架管理接口

• 并发与同步原语

• 策略注册

• 内核对象的扩展性安全标记

• 策略入口函数的组合操作

• 标记管理原语

• 由内核服务调用的入口函数 API

• 策略模块的入口函数 API

• 入口函数的实现（包括策略生命周期管理、标记管理和访问控制检查三部分）

• 管理策略无关标记的系统调用

• 复用的mac_syscall() 系统调用

• 以 MAC 的策略加载模块形式实现的各种安全策略

6.5.2 框架管理接口

　　对 TrustedBSD MAC 框架进行直接管理的方式有三种:通过 sysctl 子系统、通过 loader 配置, 或者使用系统调用。

　　多数情况下，与同一个内核内部变量相关联的 sysctl 变量和 loader 参数的名字是相同的， 通过设置它们，可以控制保护措施的实施细节，比如，某个策略在各个内核子系统中的实施与否等等。 另外，如果在内核编译时选择支持 MAC 调试选项，内核将维护若干计数器以跟踪标记的分配使用情况。 通常不建议在实用环境下通过在不同子系统上设置不同的变量或参数来实施控制，因为这种方法将会作用于系统中所有的活跃策略。 如果希望对具体策略实施管理而不相影响其他活跃策略,则应当使用策略级别的控制，因为这种方法的控制粒度更细， 并能更好地保证策略模块的功能一致性。

　　与其他内核模块一样，系统管理员可以通过系统的模块管理系统调用和其他系统接口，包括 boot loader 变量，对策略模块执行加载与卸载操作； 策略模块可以在加载时,设置加载标志,来指示系统对其加载、卸载操作进行相应控制，比如阻止非期望的卸载操作。

6.5.3 策略链表的并发与同步

　　在运行时,系统中活跃的策略集合可能发生变化，然而对策略入口函数的使用操作并不是原子性的，因此，当某一个入口函数正被使用时， 系统需要提供额外的同步机制来阻止对该策略模块的加载与卸载，以确保当前活跃的策略集合不会在此过程中发生改变。 通过使用"框架忙”计数器,就可以做到这一点：一旦某个入口函数被调用，计数器的值被增加1；而每当一个入口函数调用结束时，计数器的值被减少1。 检查计数器的值，如果其值为正，框架将阻止对策略链表的修改操作，请求操作的线程将被迫进入睡眠，直到计数器的值重新减少到0为止。 计数器本身由一个互斥锁保护，同时结合一个条件变量(用于唤醒等待对策略链表进行修改操作的睡眠线程)。 采用这种同步模型的一个副作用是，在同一个策略模块内部，允许嵌套地调用框架，不过这种情况其实很少出现。

　　为了减少由于采用计数器引入的额外开销，设计者采用了各种优化措施。其中包括，当策略链表为空或者其中仅含有静态表项 （那些只能在系统运行之前加载而且不能动态卸载的策略）时，框架不对计数器进行操作，其值总是为0，从而将此时的同步开销减到0。 另一个极端的办法是，使用一个编译选项来禁止在运行时对加载的策略链表进行修改，此时不再需要对策略链表的使用进行同步保护。

　　因为 MAC 框架不允许在某些入口函数之内阻塞，所以不能使用普通的睡眠锁。 故而，加载或卸载操作可能会为等待框架空闲而被阻塞相当长的一段时间。

6.5.4 标记同步

　　MAC 框架必须对其负责维护的安全属性标记的存储访问提供同步保护。下列两种情形，可能导致对安全属性标记的不一致访问： 第一，作为安全属性标记的持有者，内核对象本身可能同时被多个线程访问；第二，MAC 框架代码是可重入的， 即允许多个线程同时在框架内执行。通常，MAC 框架使用内核对象数据上已有的内核同步机制来保护该其上附加的 MAC 安全标记。 例如，套接字上的 MAC 标记由已有的套接字互斥锁保护。类似的，对于安全标记的并发访问的过程与对其所在对象进行的并发访问在语义上是一样的， 例如，信任状安全标记,将保持与该数据结构中其他内容一致的"写时复制"的更新过程。 MAC 框架在引用一个内核对象时，将首先对访问该对象上的标记需要用到的锁进行断言。 策略模块的编写者必须了解这些同步语义， 因为它们可能会限制对安全标记所能进行的访问类型。 举个例子，如果通过入口函数传给策略模块的是对某个信任状的只读引用，那么在策略内部，只能读该结构对应的标记状态。

6.5.5 策略间的同步与并发

　　FreeBSD 内核是一个可抢占式的内核，因此，作为内核一部分的策略模块也必须是可重入的，也就是说， 在开发策略模块时必须假设多个内核线程可以同时通过不同的入口函数进入该模块。 如果策略模块使用可被修改的内核状态，那么还需要在策略内部使用恰当的同步原语，确保在策略内部的多个线程不会因此观察到不一致的内核状态， 从而避免由此产生的策略误操作。为此，策略可以使用 FreeBSD 现有的同步原语，包括互斥锁、睡眠锁、条件变量和计数信号量。 对这些同步原语的使用必须慎重，需要特别注意两点：第一，保持现有的内核上锁次序； 第二，在非睡眠的入口函数之内不要使用互斥锁和唤醒操作。

　　为避免违反内核上锁次序或造成递归上锁，策略模块在调用其他内核子系统之前，通常要释放所有在策略内部申请的锁。 这样做的结果是，在全局上锁次序形成的拓朴结构中，策略内部的锁总是作为叶子节点， 从而保证了这些锁的使用不会导致由于上锁次序混乱造成的死锁。

6.5.6 策略注册

　　为了记录当前使用的策略模块集合，MAC 框架维护两个链表：一个静态链表和一个动态链表。 两个链表的数据结构和操作基本相同，只是动态链表还额外使用了一个"引用计数"以同步对其的访问操作。 当包含 MAC 框架策略的内核模块被加载时，该策略模块会通过 SYSINIT 调用一个注册函数； 相对应的，每当一个策略模块被卸载，SYSINIT 也会调用一个注销函数。 只有当遇到下列情况之一时，注册过程才会失败： 一个策略模块被加载多次，或者系统资源不足不能满足注册过程的需要（ 例如，策略模块需要对内核对象添加标记而可用资源不足），或者其他的策略加载前提条件不满足（有些策略要求只能在系统引导之前加载）。 类似的，如果一个策略被标记为不可卸载的，对其调用注销过程将会失败。

6.5.7 入口函数

　　内核服务与 MAC 框架之间进行交互有两种途径： 一是，内核服务调用一系列 API 通知 MAC 框架安全事件的发生； 二是，内核服务向 MAC 框架提供一个指向安全对象的策略无关安全标记数据结构的指针。 标记指针由 MAC 框架经由标记管理入口函数进行维护， 并且，只要对管理相关对象的内核子系统稍作修改，就可以允许 MAC 框架向策略模块提供标记服务。 例如，在进程、进程信任状、套接字、管道、Mbuf、网络接口、IP 重组队列和其他各种安全相关的数据结构中均增加了指向安全标记的指针。 另外，当需要做出重要的安全决策时，内核服务也会调用 MAC 框架，以便各个策略模块根据其自己的标准（可以使用存储在安全标记中的数据）完善这些决策。 绝大多数安全相关的关键决策是显式的访问控制检查； 也有少数涉及更加一般的决策函数，比如，套接字的数据包匹配和程序执行时刻的标记转换。

6.5.8 策略组合

　　如果内核中同时加载了多个策略模块，这些策略的决策结果将由框架使用一个合成运算子来进行组合汇总，得出最终的结果。 目前，该算子是硬编码的，并且只有当所有的活跃策略均对请求表示同意时才会返回成功。 由于各个策略返回的出错条件可能并不相同（成功、访问被拒绝、请求对象不存在等等）， 需要使用一个选择子先从各个策略返回的错误条件集合中选择出一个作为最终返回结果。 一般情况下，与“访问被拒绝”相比，将更倾向于选择“请求对象不存在”。 尽管不能从理论上保证合成结果的有效性与安全性，但试验结果表明，对于许多实用的策略集合来说，事实的确如此。 例如，传统的可信系统常常采用类似的方法对多个安全策略进行组合。

6.5.9 标记支持

　　与许多需要给对象添加安全标记的访问控制扩展一样，MAC 框架为各种用户可见的对象提供了一组用于管理策略无关标记的系统调用。 常用的标记类型有，partition标识符、机密性标记、完整性标记、区间（非等级类别）、域、角色和型。 “策略无关”的意思是指，标记的语法与使用它的具体策略模块无关，而同时策略模块能够完全独立地定义和使用与对象相关联的元数据的语义。 用户应用程序提供统一格式的基于字符串的标记，由使用它的策略模块负责解析其内在含义并决定其外在表示。 如果需要，应用程序可以使用多重标记元素。

　　内存中的标记实例被存放在由 slab 分配的struct label数据结构中。 该结构是一个固定长度的数组，每个元素是由一个 void * 指针和一个 long组成的联合结构。 申请标记存储的策略模块在向 MAC 注册时，将被分配一个“slot”值，作为框架分配给其使用的策略标记元素在整个标记存储结构中的位置索引。 而所分配的存储空间的语义则完全由该策略模块来决定：MAC 框架向策略模块提供了一系列入口函数用于对内核对象生命周期的各种事件进行控制，包括， 对象的初始化、标记的关联/创建和对象的注销。使用这些接口，可以实现诸如访问计数等存储模型。 MAC 框架总是给入口函数传入一个指向相关对象的指针和一个指向该对象标记的指针，因此，策略模块能够直接访问标记而无需知悉该对象的内部结构。 唯一的例外是进程信任状结构，指向其标记的指针必须由策略模块手动解析计算。今后的 MAC 框架实现可能会对此进行改进。

　　初始化入口函数通常有一个睡眠标志位，用来表明一个初始化操作是否允许中途睡眠等待； 如果不允许，则可能会失败返回，并要求撤销此次标记分配操作（乃至对象分配操作）。 例如，如果在网络栈上处理中断时因为不允许睡眠或者调用者持有一个互斥锁，就可能出现这种情况。 考虑到在处理中的网络数据包（Mbufs）上维护标记的性能损失太大，策略必须就自己对 Mbuf 进行标记的要求向 MAC 框架做出特别声明。 动态加载到系统中而又使用标记的策略必须为处理未被其初始化函数处理过的对象作好准备， 这些对象在策略加载之前就已经存在,故而无法在初始化时调用策略的相关函数进行处理。 MAC 框架向策略保证，没有被初始化的标记 slot 的值必为0或者 NULL，策略可以借此检测到未初始化的标记。 需要注意的是，因为对 Mbuf 标记的存储分配是有条件的，因此需要使用其标记的动态加载策略还可能需要处理 Mbuf 中值为 NULL 的标记指针。

　　对于文件系统对象的标记，MAC 框架在文件的扩展属性中为其分配永久存储。 只要可能，扩展属性的原子化的事务操作就被用于保证对 vnode 上安全标记的复合更新操作的一致性－－目前，该特性只被 UFS2 文件系统支持。 为了实现细粒度的文件系统对象标记（即每个文件系统对象一个标记），策略编写者可能选择使用一个（或者若干）扩展属性块。 为了提高性能， vnode 数据结构中有一个标记 (v_label)字段，用作磁盘标记的缓冲； vnode 结构实例化时，策略可以将标记值装入该缓冲，并在需要时对其进行更新。 如此，不必在每次进行访问控制检查时，均无条件地访问磁盘上的扩展属性。

6.5.10 相关系统调用

　　MAC 框架向应用程序提供了一组系统调用：其中大多数用于向进行查询和修改策略无关标记操作的应用 API提供支持。

　　这些标记管理系统调用，接受一个标记描述结构， struct mac，作为输入参数。 这个结构的主体是一个数组，其中每个元素包含了一个应用级的 MAC 标记形式。每个元素又由两部分组成:一个字符串名字，和其对应的值。 每个策略可以向系统声明一个特定的元素名字，这样一来，如果需要，就可以将若干个相互独立的元素作为一个整体进行处理。 策略模块经由入口函数，在内核标记和用户提供的标记之间作翻译转换的工作，这种实现提供了标记元素语义上的高度灵活性。 标记管理系统调用通常有对应的库函数包装，这些包装函数可以提供内存分配和错误处理功能，从而简化了用户应用程序的标记管理工作。

　　目前的FreeBSD 内核提供了下列 MAC 相关的系统调用：

• mac_get_proc() 用于查询当前进程的安全标记。

• mac_set_proc() 用于请求改变当前进程的安全标记。

• mac_get_fd() 用于查询由文件描述符所引用的对象（ 文件、 套接字、 管道文件等等） 的安全标记。

• mac_get_file() 用于查询由文件系统路径所描述的对象的安全标记。

• mac_set_fd() 用于请求改变由文件描述符所引用的对象（ 文件、套接字、 管道文件等等） 的安全标记。

• mac_set_file() 用于请求改变由文件系统路径所描述的对象的安全标记。

• mac_syscall() 通过复用该系统调用,策略模块能够在不修改系统调用表的前提下创建新的系统调用； 其调用参数包括：目标策略名字、 操作编号和将被该策略内部使用的参数。

• mac_get_pid() 用于查询由进程号指定的另一个进程的安全标记。

• mac_get_link() 与 mac_get_file() 功能相同， 只是当路径参数的最后一项为符号链接时， 前者将返回该符号链接的安全标记， 而后者将返回其所指文件的安全标记。

• mac_set_link() 与 mac_set_file() 功能相同， 只是当路径参数的最后一项为符号链接时， 前者将设置该符号链接的安全标记， 而后者将设置其所指文件的安全标记。

• mac_execve() 与 execve() 功能类似， 只是前者还可以在开始执行一个新程序时,根据传入的请求参数,设置执行进程的安全标记。 由于执行一个新程序而导致的进程安全标记的改变,被称为“转换”。

• mac_get_peer()， 通过一个套接字选项自动实现， 用于查询一个远程套接字对等实体的安全标记。

　　除了上述系统调用之外， 也可以通过 SIOCSIGMAC 和 SIOCSIFMAC 网络接口的 ioctl 类系统调用来查询和设置网络接口的安全标记。

6.6.1 策略注销

　　策略模块可以使用 MAC_POLICY_SET() 宏来声明。 该宏完成以下工作：为该策略命名（向系统声明该策略提供的名字）；提交策略定义的 MAC 入口函数向量的地址； 按照策略的要求设置该策略的加载标志位，保证 MAC 框架将以策略所期望的方式对其进行操作； 另外，还可能请求框架为策略分配标记状态 slot 值。

static struct mac_policy_ops mac_policy_ops =
{                                   
        .mpo_destroy = mac_policy_destroy,
        .mpo_init = mac_policy_init,
        .mpo_init_bpfdesc_label = mac_policy_init_bpfdesc_label,  
        .mpo_init_cred_label = mac_policy_init_label,
/* ... */
        .mpo_check_vnode_setutimes = mac_policy_check_vnode_setutimes,
        .mpo_check_vnode_stat = mac_policy_check_vnode_stat,
        .mpo_check_vnode_write = mac_policy_check_vnode_write,
};

　　如上所示，MAC 策略入口函数向量，mac_policy_ops， 将策略模块中定义的功能函数挂接到特定的入口函数地址上。 在稍后的“入口函数参考”小节中，将提供可用入口函数功能描述和原型的完整列表。 与模块注册相关的入口函数有两个：.mpo_destroy和.mpo_init。 当某个策略向模块框架注册操作成功时，.mpo_init将被调用，此后其他的入口函数才能被使用。 这种特殊的设计使得策略有机会根据自己的需要，进行特定的分配和初始化操作，比如对特殊数据或锁的初始化。 卸载一个策略模块时，将调用 .mpo_destroy 用来释放策略分配的内存空间或注销其申请的锁。 目前，为了防止其他入口函数被同时调用，调用上述两个入口函数的进程必须持有 MAC 策略链表的互斥锁：这种限制将被放开， 但与此同时，将要求策略必须谨慎使用内核原语,以避免由于上锁次序或睡眠造成死锁。

　　之所以向策略声明提供模块名字域，是为了能够唯一标识该模块，以便解析模块依赖关系。选择使用恰当的字符串作为名字。 在策略加载和卸载时，策略的完整字符串名字将经由内核日志显示给用户。另外，当向用户进程报告状态信息时也会包含该字符串。

6.6.2 策略标志

　　在声明时提供标志参数域的机制，允许策略模块在作为模块被加载时，就自身特性向 MAC 框架提供说明。 目前，已经定义的标志有三个：

6.6.3 策略入口函数

　　MAC 框架为注册的策略提供四种类型的入口函数： 策略注册和管理入口函数； 用于处理内核对象声明周期事件，如初始化、 创建和销毁，的入口函数； 处理该策略模块感兴趣的访问控制决策事件的入口函数； 以及用于管理对象安全标记的调用入口函数。 此外， 还有一个 mac_syscall() 入口函数， 被策略模块用于在不注册新的系统调用的前提下， 扩展内核接口。

　　策略模块的编写人员除了必须清楚在进入特定入口函数之后， 哪些对象锁是可用的之外， 还应该熟知内核所采用的加锁策略。 编程人员在入口函数之内应该避免使用非叶节点锁， 并且遵循访问和修改对象时的加锁规程， 以降低导致死锁的可能性。 特别地， 程序员应该清楚， 虽然在通常情况下， 进入入口函数之后， 已经上了一些锁， 可以安全地访问对象及其安全标记， 但是这并不能保证对它们进行修改（ 包括对象本身和其安全标记） 也是安全的。 相关的上锁信息，可以参考 MAC 框架入口函数的相关文档。

　　策略入口函数把两个分别指向对象本身和其安全标记的指针传递给策略模块。 这样一来，即使策略并不熟悉对象内部结构，也能基于标记作出正确决策。 只有进程信任状这个对象例外：MAC 框架总是假设所有的策略模块是理解其内部结构的。