Linux 内核审计子系统

https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
https://github.com/linux-audit/audit-kernel

Linux 审计子系统提供了一个安全日志框架，用于捕获和记录安全相关事件。它由一个基于系统活动生成审计记录的内核组件、一个将这些记录记录到本地文件或远程聚合服务器的用户空间守护进程，以及一组用于审计日志检查和事后处理的用户空间工具组成。

Linux 内核的主 README 可以在 Documentation/admin-guide/README.rst 找到

在线资源

权威的审计内核仓库托管在 kernel.org 上：

• https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
• git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git

还有一个官方维护的 GitHub 镜像：

• https://github.com/linux-audit/audit-kernel

内核源码分支与开发流程

内核源码分支

开发流程涉及四个主要的 git 分支：stable-X.Y、dev、dev-staging 和 next。除了这四个主要分支之外，还有一些以 "working-" 前缀开头的、针对特定主题的进行中分支；除非您恰好参与该特定主题的开发，否则这些分支通常可以忽略。这些主题分支的管理方式可能因多种因素而异，但每个分支的详细信息将在上游邮件列表的相关讨论主题中公布。

stable-X.Y 分支

stable-X.Y 分支用于稳定版内核补丁，基于 Linus 的 X.Y-rc1 标签，或根据需要基于更晚的 X.Y.Z 稳定版内核发布标签。如果在内核发布候选周期内发现严重问题并开发出补丁，该补丁可能成为稳定版内核标记的候选者，并被纳入 stable-X.Y 分支。Linux 主内核关于稳定版内核补丁的文档提供了更多信息，包括哪些补丁可能成为稳定版内核候选者，以及如何恰当地标记这些补丁；也可以预期上游邮件列表会就该补丁是否值得标记为稳定的问题进行讨论。一旦补丁被合并到 stable-X.Y 分支，并在 next 分支中停留一两天（参见 next 分支说明），它将被发送给 Linus，以合并到下一个发布候选版本或最终内核发布中（参见本文档中关于 pull request 的说明）。如果补丁已被正确标记为稳定，其他稳定版内核树将尝试在补丁出现在 Linus 的树中后立即进行反向移植，更多细节请参阅 Linux 主内核文档。

除非特别要求，否则开发人员不应以 stable-X.Y 分支作为其补丁的基础。合并上游提交的补丁所产生的任何合并冲突都将由维护者处理，尽管在极端情况下可能会请求帮助和/或协助。

dev 分支

dev 分支用于针对即将到来的合并窗口的开发补丁，基于 Linus 最新的 X.Y-rc1 标签，或根据需要基于更晚的 rc 标签，以避免严重的 bug、合并冲突或其他重大问题。该分支是主要的开发分支，在正常的内核开发周期中，大多数补丁都在这里合并。合并到 dev 分支的补丁将出现在 next 分支中（参见 next 分支说明），并将在下一个合并窗口期间发送给 Linus。

开发人员应将 dev 分支作为其开发工作的稳定基础，只有在极端情况下，dev 分支才会在 X.Y-rc 周期内被变基，维护者将负责解决任何合并冲突，尽管在极端情况下可能会请求帮助和/或协助。

dev-staging 分支

dev-staging 分支用于不针对特定合并窗口的开发补丁。dev-staging 分支作为主 dev 分支的暂存区存在，因此其使用方式不可预测，并且会根据需要被变基。合并到 dev-staging 分支的补丁应在未来某个时候进入主 dev 分支，但这并不保证。

除非特别要求，否则开发人员不应将 dev-staging 分支作为任何开发工作的基础。

next 分支

next 分支是一个复合分支，通过按顺序合并最新的 stable-X.Y 和 dev 分支构建而成。next 分支的主要目的是为 linux-next 集成测试提供一个包含所有组件分支提交的单一分支。只要任一组件分支发生变化，next 分支就会更新，但在合并窗口期间它将保持冻结状态，以配合 linux-next 团队的意愿。

虽然开发人员可以使用 next 分支作为开发基础，但 dev 分支可能是更合适、更稳定的基础。

内核开发流程

Linus 关闭上游内核合并窗口后，与当前内核发布候选版本关联的 stable-X.Y 分支、dev 分支以及可能的 dev-staging 分支（参见 dev-staging 分支说明）将被重置，以匹配 Linus 树中最新的 vX.Y-rc1 标签。next 分支作为由这些分支组成的复合分支，将随之更新。

在从内核合并窗口关闭开始、到标记的内核发布结束的开发周期中，补丁将按照本文档各自章节的描述被接受进入 stable-X.Y 和 dev 分支。虽然补丁在任何时候都会被接受进入 stable-X.Y 分支，但当开发周期剩余两周或更少时，重大更改可能不会被接受进入 dev 分支；这通常意味着一旦 vX.Y-rc6 内核发布，只有关键的 bug 修复才会被接受。在此期间，next 分支将根据组件分支的变化按需重新生成，并会根据需要向 Linus 发送针对 stable-X.Y 分支中补丁的 pull request。

一旦 Linus 发布最终的 vX.Y 内核并打开合并窗口，将发生两件事。第一，dev 分支将被复制到一个新的 stable-X'.Y' 分支，代表即将到来的新内核版本；第二，将从该分支发送一个 pull request，以纳入当前的合并窗口。在合并窗口期间，dev 和 next 分支应保持冻结，尽管某些补丁有可能因测试或流程相关原因被合并到 dev-staging。

发送给 Linus 的 Pull Request

为了向 Linus 发送 pull request，无论是针对关键 bug 修复还是作为合并窗口的一部分，都必须创建一个指向 pull request 点的签名 git 标签。标签应使用 "{subsystem}-pr-{date}" 格式命名，并可通过以下 git 命令生成：

% git tag -s -m "{subsystem}/stable-X'.Y' PR {date}" {subsystem}-pr-{date}

创建签名标签后，应将其用作 pull request 的基础。

用户空间工具与测试套件

审计用户空间工具和测试套件托管在 GitHub 上：

• https://github.com/linux-audit