探索 AIX 6：新特性概览（下）

本系列文章旨在带领读者探索 AIX 6.1 中的新特性和对 AIX 5L 中已有功能的增强，并了解这些新特性对用户的影响。在本文的第 1 部分中，我们介绍了 AIX 6.1 在系统基础功能，存储、I/O 和文件系统方面的新功能和增强。在本文的第 2 部分中，向您了网络，性能，虚拟化和可管理性方面的变化。本文为第 3 部分，向您介绍了关于可用性、安全性以及开发方面的一些新的特性和功能。

企业级的 RAS（Reliability，Availability，Serviceability）历来是 IBM System p 服务器和 AIX 操作系统的核心优势，在 AIX 6 中，其 RAS 特性又有了大幅增强，提供了一个组件式的 RAS 基础框架，其中包含以下组件（又称之为 Domain）：

• RTEC（Run-Time Error Checking）：运行时故障检查，可对系统组件（包括硬件和软件）的故障检测，严重程度级别和处理动作进行定义。AIX 6 中很多设备驱动和子系统都使用了该组件提供的服务，例如 VMM 子系统，存储和磁盘驱动，网络驱动等等。
• CT（Component Tracing）：新增的跟踪（Tracing）调试手段。可以用于系统跟踪时提供额外的更加细致的过滤，或者作为单独的跟踪手段来帮助诊断系统问题。
• CD（Component Dump）：对 Dump 功能的增强。Dump 信息的详细程度可以进行细化控制，并且可执行 Live Dump（dump 过程不需要停止系统，dump 结束后系统继续运行）。

基于这个框架，AIX 系统自身的各个部分和第三方的软件都可以向系统注册并执行其特有的故障检测和控制，tracing 和 dump 等功能，以提供更加强大和灵活的 RAS 特性。

伴随着 RAS 组件框架还增加了一系列的系统管理命令，其中最主要的是 errctrl，ctctrl 和 dumpctrl 命令，可对各个 AIX 各个子系统或者设备的 RTEC，CT 和 CD 属性进行控制。

Dump 是 AIX 系统中用于故障诊断的一项非常重要的功能，dump 数据中包括了故障发生时的内存内容和处理器状态等信息，可用于重现故障时的场景以进行分析。旧式的 dump 方法是在崩溃时对整个系统的内存都进行转储，由于现代系统的物理内存越来越大，进行一次完整 dump 的时间也越来越长，间接的增加了由于宕机带来的停机时间。AIX 6 中引入了几种新的 dump 手段，更加灵活方便，对业务影响更小。下表对各种 dump 方式做了总结：

方式	AIX 版本	说明
传统 dump	所有	原始方式，随着 CPU 数量的增加，物理内存的加大，dump 需要的时间也越来越长。
Minidump	V5.3 TL3	数据不是像传统的 dump 方式那样保存到磁盘上，而是保存到 NVRAM 中，系统下次启动时，再写入到 error log 中。因此 Minidump 的容量非常小，只保存了关键的信息，同时转储所需要的时间也很短。
Parallel dump	V5.3 TL5	Dump 数据存储的格式发生改变，数据块以无序方式存储，使得多处理器的系统可以按照每个处理器同时转储一块区域的方式将内存数据写入到 dump 设备。此改进使得大型系统（多 CPU，大内存）的 dump 速度得到大大提升，仅仅受限于 I/O 速度。
Component Dump	V6	在上一主题“RAS 组件框架”中我们已经提到，Component Dump 使得管理员可以对 dump 的详细程度和各组件的 dump 属性进行更加精确的控制。
Live Dump	V6	Live Dump 方式基于新的 Component Dump 框架。执行时，只有那些注册到 CD 框架并且声明为支持 Live Dump 特性的组件才会有数据转储。Live Dump 还有另外一项非常重要的特性，就如其名称表明的一样，在 dump 时不需要重新启动系统。因此 Live Dump 方式减少了需要转储的数据并显著的降低了 dump 所需要的停机时间。
Firmware-Assisted Dump	V6	传统的 dump 方式实际上是由已经发生故障的 AIX 内核进行的，这样存在两个问题： 如何保证由已经故障的内核所写入的数据的正确性 故障严重到内核已经无法进行 dump 时，即无法收集任何 dump 信息 在 POWER 6 平台上，系统微码引入了对 AIX dump 的支持。AIX 6 可以在发生崩溃时立即重启，系统微码会保护崩溃时的内存区域的内容不受影响。在 AIX 6 系统启动过程中，内核会将由微码保护起来的内存区域转储并释放。使用此方式，dump 的可靠性得到了大幅提升。

可见，在 AIX 6 中，dump 方式的改进主要在于可更加细致的控制 dump 的内容，减少 dump 对系统的影响，增加 dump 过程的可靠性这几方面。

Storage protection keys 是 POWER 6 处理器新增加的一项功能，系统内存可以按照区域分配不同的 key，通过硬件提供支持来保证只有持有正确的 key 的代码可以修改其内容。该技术可以应用在 AIX 内核或者用户应用程序代码中，防止由于代码的错误行为（无论是有意还是无意）而可以任意破坏其它内存区域，因此可以进一步提高系统的稳定性。AIX 5.3 TL6 中加入了 Storage protection keys 的 API，应用程序可以使用此功能，但是内核并不支持使用 key 来保护。而 AIX 6 中，内核代码和用户应用代码都可以使用 Storage protection keys 功能。

作为系统的关键部分，AIX 内核的稳定性直接影响到整个系统的可用性。如果内核出现了错误，往往造成整个系统直接崩溃。AIX 6 内核包括了自动故障恢复功能（Kernel error recovery），当错误出现时，可以自动采取动作，避免造成崩溃。

AIX 6 内核中增加了一个称之为恢复管理器（Recovery Manager）的组件，所有需要提供故障自动回复的内核组件或者扩展模块都会向 Recovery Manager 注册其特定的恢复例程（Recovery Routine）。当某个组件发生错误时，它会产生一个异常，将执行转交给 Recovery Manager，由其执行该组件的恢复例程。当恢复例程执行结束后，Recovery Manager 会将执行交还该组件，使其继续运行下去。

恢复例程内通常会执行以下操作，使得出错的组件可以恢复到正常的执行状态：

• 收集故障数据
• 检查并恢复数据结构
• 对组件出错时持有的资源进行相应的处理或者释放
• 决定修复为故障而应采取的措施

恢复例程通常在尝试进行任何恢复动作前会先触发一个 Live Dump，并在 AIX error log 中会记录一次内核故障恢复事件（Lable 为 RECOVERY、RECOVERY_NOTIF 或 RECOVERY_TIME）。

内核故障恢复功能的开启可以通过 raso 命令来进行控制，包括受限参数 recovery_action、recovery_average_threshold、recovery_debugger 和 recovery_framework。也可以通过 SMIT 菜单来访问，快捷路径为 krecovery。

在线内核升级（Concurrent update）

在 AIX 6 之前的版本中，任何对 AIX 内核进行更新的操作之后都必须要执行 bosboot 命令更新 Boot LV 然后重新引导系统才会生效，在补丁升级任务结束后经常会看到这样的提示信息，

 * * * A T T E N T I O N * * *
 System boot image has been updated. You should reboot the
 system as soon as possible to properly integrate the changes
and to avoid disruption of current functionality.

就是因为这个原因。因此当 IBM 发布一个关键的内核补丁时，用户通常会面临一个两难的局面：如果升级补丁，必须要重新启动，这会带来一段宕机时间；而如果不更新补丁，又会面临潜在的问题。

AIX 6 通过引入在线内核升级（Concurrent update）功能改善了这个问题，该功能的特点在于：

• 安装后不需要重启，即时生效。补丁可以设置为在重启后持续生效，或者仅对本次有效。
• 以临时补丁（Interim Fix）的形式提供，使用 emgr 命令来安装和管理。emgr 命令新增加 -i 参数来安装 concurrent update，具体的信息可以参考 man emgr。
• 如果补丁被安装为应用（Applied）状态，而没有被提交（Commit），那么移除该补丁同样不需要重新启动系统。
• 由于对运行中的内核代码进行动态的修改和替换是一个复杂的过程（AIX 6 的内核专门为此引入了相应的机制和系统调用），因此并不是所有的内核补丁都能够以在线方式升级。对内核的重大改变或者关键部分的升级还是需要计划相应的宕机时间。

AIX 6 增加了对换页空间（Paging space）数据的正确性校验，通过记录被换页的内存数据的校验和（checksum），AIX 6 确保内存数据在写入到磁盘时和从磁盘读入时是一致的。如果校验数据表明 Paging space 中的数据不正确，AIX 会记录一个错误日志，并根据错误的内存数据属于哪个区域而采取相应的行为：如果属于内核使用的系统内存，那么停机；如果属于应用程序使用的部分，则给相应的进程发送异常信号。

Paging space 的中的数据以 4KB 为单位计算校验和，校验和长度（checksum size）可以在 8/16/32 bit 中进行选择，如果 checksum size 设置为 0，则关闭了该功能。当打开校验功能时，每个 Paging space 设备会对应一段大小为 256MB 的专用内存区域，用来记录存储到该设备上的每个内存页的校验和。Paging space 的校验和长度设置记录在 /etc/swapspaces 文件中，可以在创建时使用 mkps –c 参数来指定，也可以在创建好之后使用 chps –c 参数来修改。

Trusted AIX 是 AIX 6 提供的一种工作模式，在此模式下，AIX 系统使用 Label 对系统中的 Subjects（通常是系统中的进程）和 Objects（被访问的资源，包括文件，内存中的 IPC 对象，网络数据包，以及其他任何资源）进行标记，说明其安全属性。相比于普通的 AIX，在 Trusted AIX 环境下某个 Subject 是否可对某个 Object 执行相应的操作，均需根据其附属的 Label 来进行判断，而通过合理的设置 Label，可以对系统上的数据进行不同级别的保护。

在普通的 AIX 环境下用户可以使用以下一些手段来对数据进行隔离和访问控制：

• 按照 User/Group/Others 角色来分配 Read/Write/Execute 权限，初步控制文件权限
• 用户自主设置的 ACL，文件的属主可以控制 ACL，将访问授权给任何人
• 进程的权限由其有效 UID 和 GID 来决定
• 审计子系统（Audit subsystem）用来审计用户和进程的操作
• 基于角色的访问控制（RBAC）

这些手段也是 UNIX 世界中传统的方式，简单，实用，但是却有着各种不足，例如：

• 文件的属主拥有对文件访问权限的全面控制，一旦设置不当（不论有意或无意），都会有敏感数据泄漏的风险。
• 不论是普通的文件权限位还是 ACL，都只能对“文件”资源进行控制，对诸如内存对象和网络数据包则无能为力。
• 即便是使用了 ACL，文件权限的设定粒度也不够精细。
• 存在一个特殊的用户：root。他可以访问和修改系统内的几乎所有资源，是严重的安全隐患。

Trusted AIX 在这些传统方法的基础之上进一步提供了更加强大和全面的手段，来加强对数据的保护。在 Trusted AIX 环境下可以做到：

• 强制访问控制：文件的属主不能随意修改文件的安全属性，只有被授权的操作员才可以执行这类操作，保证敏感数据的访问受到控制。
• 对进程，文件和其他各种数据设置 Security Label 和 Integrity Label。通过这些 Label 可以精确控制进程对数据的访问和修改权限。
• 细分用户权限，任何用户要访问某个资源或执行某个操作，都必须要有相应的权限。root 不再是一个特殊的万能用户，它与普通用户一样，只能访问有授权的文件。
• 进程和用户执行的操作和其多需的对应权限细分后，系统可以对其进行更加详细的记账和审计操作。

Trusted AIX 设计主要是针对需要极高安全性的用户，例如军事国防等领域。由于控制更加严格，不可避免的增加了管理难度，降低了易用性，并带来一些特定的限制。用户在部署 Trusted AIX 之前需要对此有充分的了解：

• Trusted AIX 模式是否开启由安装时的选项决定，普通模式和 Trusted AIX 模式之间切换只有通过重新覆盖安装来完成。
• 在 Trusted AIX 环境下 root 用户无法登陆系统，这会对一些应用的行为产生影响，例如 NIM 和其他一些需要使用 root 用户通过网络登录执行管理操作的应用程序。
• 由于 root 用户不再可用，新增三个用户 isso，sa 和 so 供系统管理和操作用途。这三个帐户必须在安装结束后第一次启动时设置密码，否则系统无法使用。
• Trusted AIX 环境下创建的 WPAR，也受 Security Label 的控制。
• RBAC 和 Trusted Execution 功能在普通和 Trusted AIX 模式都可用，如果仅仅需要这两个功能，可以不必选择启用 Trusted AIX。
• Trusted AIX 与普通 AIX 兼容，在普通 AIX 模式下能正常工作的应用程序在 Trusted AIX 下也可以正常运行。但由于 Trusted AIX 下应用程序的操作都受到更多的限制，因此程序很可能会由于安全规则设置的原因无法正常工作。管理员可以使用 tracepriv 命令来帮助诊断此类问题。

Trusted Execution Environment

在 AIX 5L 中有一项称之为 Trusted Computing Base（TCB）的安全特性，该功能主要用于保证关键的系统文件是可信的。TCB 通过 crontab 定时对关键的系统文件属性进行扫描，并将结果与其保存在数据库内的数据进行对比，以鉴别这些文件是否被修改过。TCB 可以在一定程度上保证系统不受被篡改过的程序的危害。AIX 6 中开始提供了一个新的功能，称之为 Trusted Execution（TE） Environment，可以看作为 Trusted Computing Base 的增强。原有的 TCB 仍然可用，用户可以在这两者间选择启用任意一个。

TE 与 TCB 最大的不同在于，TCB 只能依赖于 crontab 这类方法来定时检查关键文件的正确性，两次检查之间会存在一个窗口期；而 TE 除此之外，还可以在文件 每次 被访问（执行）的时刻，即时进行检查，以确保任何时候载入的代码都是可信任的。TE 维护一个称之为 Trusted Signature Database（TSD）的数据库，其中记录了受到保护的文件的各类属性，最重要的是文件哈希值（Hash），通过对比 TSD 中和磁盘上的文件的 Hash 值，即可以判断文件是否处于完整可信，未被篡改的状态。

Trusted Execution 提供了 trustchk 命令来设置 TE 的工作策略，对系统的进行完整性检查和管理 TSD。正如前文曾经提到过的，完整性检查有两种工作方式：

系统完整性检查 在每次系统启动时，或者在 crontab 中定时运行，对整个系统中受到监控的文件的属性进行扫描，与 TSD 中存储的信息进行对比。

运行时完整性检查 在收到保护的文件每次被读入时对其签名进行检查，确保文件始终是可信的，而不是被篡改过（例如插入了木马，恶意代码）。

Trusted Execution 策略可以设置为对执行文件，共享库，脚本和内核扩展模块进行检查；可以锁定 TSD 数据库和受保护的文件为不可修改状态；还可以设置受信任的执行文件和共享库路径，只有在此路径下的执行文件和共享库才能被调用。将这些策略进行适当的设置和组合，可以对系统关键文件的完整性进行灵活而强大的保护。

Trusted Execution 与 Trusted Computing Base 另外一个不同在于，TCB 是安装时的选项，其开启和关闭必须在安装时就进行选择，而 TE 是一个动态选项，可以通过 trustchk 命令来动态控制开启或者关闭。

增强的 Role Based Access Control（RBAC）是 AIX 6 中另一项非常重要的安全特性，事实上，从 AIX 4.2 开始便包含了一个 RBAC 应用框架，但该框架有如下不足：

• 应用程序需要做相应的修改才能利用该框架支持 RBAC。
• 预定义的授权体系粒度不够。
• 为执行某些程序，用户经常需要具有某个特定的组身份（group membership）和角色（role）。
• 在用户角色（role）的管理上不够强大和灵活。
• 尚未达到“最小权限”原则的要求，许多特权命令依然还是需要被设置为 SUID。

为了解决这些问题，AIX 6 中引入的了一个新的 RBAC 框架，称之为 Enhanced RBAC，原有的框架改称为 Legacy RBAC。

RBAC 的核心思想是将权限细分，并与用户分离，用户在执行某个特权操作时，只需要具有相应的最小权限，而不需要拥有某个特殊的用户身份和其他不相干的权限。RBAC 框架中有以下几个重要的概念：

授权（Authorizations）授权是对用户的能力的定义。在执行任务时，用户必须要具有对应的授权才能够使用特定的命令。

特权（Privileges）特权是对进程的能力的定义。进程需要有足够的特权级才能进行受到安全限制的操作。

角色（Roles）角色是将授权赋予给某个用户的手段。一个角色可以包含有为执行某个任务而需要的多个授权，当该角色被赋予某个用户时，该用户即拥有了这些授权，可以执行对应的系统管理任务。

如果没有 RBAC，系统的权限实际上集中在特定的用户手上，无法分离。典型的是 root 用户，可以访问系统中所有资源，以 root 身份运行的程序也就可以执行任意的操作。如果普通的用户需要执行某个操作，比如管理文件系统，由于权限与用户身份绑定在一起，那么他只能设法以 root 身份来执行任务，例如使用 SUID 的程序。引入 RBAC 支持之后，权限和用户不再是绑定的。用户如果需要某个特权来执行管理操作，他只需要获得相应的授权即可，不需要改变自己的身份。

默认情况下 RBAC 的配置文件位于 /etc/security 目录下，保存了角色，授权，特权命令，特权设备和特权文件数据。对这些配置修改后，管理员需要使用 setkst 命令将配置文件中的数据上传到 AIX 内核中的 Kernel Security Table（KST）才会生效。配置文件数据还可以存放在 LDAP 目录中，该特性由 /etc/nscontrol.conf 文件控制。通过将 RBAC 配置保存在 LDAP 目录中，多个 AIX 服务器可以共享同样的 RBAC 配置，简化企业网络的安全管理。

AIX 5L 中支持的最大密码长度为 8 个字符长，这是由于密码加密过程算法使用的是 crypt() 调用，该方法会将密码在 8 字节处截断。从 AIX 6.1 和 AIX 5.3 TL7 开始，支持可加载的密码算法（Loadable Password Algorithm），这样 AIX 系统可以支持更多种密码算法来对密码进行加密，并且密码的最大长度也扩展到了 255 个字符（各种密码加密算法支持的最大长度不同）。由于密码算法可变，密码长度更长，用户密码被暴力破解的可能性也就相应降低了。

AIX 6 中引入了称之为 ProbeVue 的新的的跟踪手段，它的最大特点在动态跟踪。“动态”意味着应用程序不需要做任何修改就可以在运行过程中随时插入跟踪点，收集执行时的状态数据。而以往的跟踪方法（静态跟踪）需要在程序源代码中加入跟踪点，并在编译时使用对应的选项以生成带跟踪和调试信息的执行文件。由于加入这些额外信息的程序往往执行速度更慢并占用更多内存，因此生产系统通常不会运行运行这些调试版本的代码，导致发生程序发生问题时，往往需要停止原来的生产版本程序，启动带跟踪信息的版本，等待问题再次发生然后进行跟踪调试。相比之下使用 ProbeVue 可以在生产系统中不用中断应用程序，随时可以被跟踪收集信息。

ProbeVue 中重要的概念包括：

Probe 中断正在执行的代码，以收集当时系统状态和进程上下文信息的动作。

Probe Action 在一个 Probe 中执行的具体动作，通常包括收集各种系统全局数据和进程特有的上下文信息的过程，并将这些信息保存到缓冲区，供跟踪工具读取和分析。

Probe Point 程序代码执行过程中可以进行 Probe 操作的位置。ProbeVue 支持两种类型的 Probe Point：Probe Location 和 Probe Event

Probe Location 代码中的某个具体的位置，当执行到这个位置时，该点的 Probe Action 就会被触发

Probe Event 对应于一个抽象的事件（Event）而不是具体的代码位置，当某个 Event 发生时，触发具体的 Probe Action。

ProbeVue 使用称之为 Vue 的专用脚本语言来进行具体的跟踪工作， Vue 脚本的主要内容可以归纳为

• 一个或多个 Probe 语句：在某个 Probe Point，如果满足某个条件断言（Predicate），则执行某个 Probe Action 代码段。简单来讲，就是何时，何处执行什么跟踪操作。
• 可选的初始化操作和退出时的清理操作。

Vue 脚本通过将多个 Probe 语句组合到一起可以完成非常复杂的跟踪操作，收集丰富的调试信息，大大的增强了 AIX 系统下的调试手段。

传输无关的 RPC（Transport Independent Remote Procedure Call）是 AIX 内包含的一套应用编程接口（API），它使得在编写使用 RPC 方式进行网络计算的应用程序时不再需要关注下层具体的传输协议（常见的如 TCP，UDP，或者其他任何支持的网络传输协议）。应用程序只需要关注具体的 RPC 问题，而 TI-RPC 会处理下层的传输细节，这样可以大大增加应用程序的可移植性。

在 AIX 6 之前，AIX 系统内部已经提供了 TI-RPC 接口，主要供操作系统自身使用（例如 NFS 功能），但是 IBM 并不为客户使用该 API 提供支持。从 AIX 6 开始，IBM 正式支持 TI-RPC 作为 AIX 标准的编程接口。同时该接口也保持与 Sun Solaris 系统中的 TI-RPC API 的兼容性，应用程序移植时几乎不需要做任何修改。

到此为止，我们对 AIX 6 中的新增功能和对原有特性的增强做了一个比较全面的介绍，由于篇幅的关系，很多细节没有进行详细的描述，并且还有不少特性由于涉及内容太过于深入也没有介绍到。读者可以参考 IBM 红皮书《IBM AIX Version 6.1 Differences Guide》来学习更多具体的内容。