源码：https://github.com/microsoft/HardLog
Introduction
背景
有效的系统审计的持久障碍是日志篡改（log tampering）。
①原则上，审计系统可以通过立即将每个日志条目存储在安全的位置。但考虑到现有网络和存储设备对于大量小消息的低性能，这会导致不可接受的开销。因此，审计系统将花费相当长的时间对日志条目进行批处理，并异步存储更少、更大的消息。
② However，这种延迟为攻击者篡改批处理事件创造了一个时间窗口。
③ Finally，如果将日志存储在商用防篡改本地存储设备中，则管理员无法远程管理日志(即安全地检索和丢弃旧日志)，而商用防篡改本地存储设备缺乏认证和存储重用性。
传统上，防止日志篡改的主要防御措施是防篡改审计（tamper-evident auditing）。系统维护一个加密完整性证明，它在每个新事件时更新，并允许验证者确定日志没有被篡改。
However，这样的系统并不能阻止攻击者通过删除日志来干扰取证，且它们还会产生假警报，因为良性系统崩溃通常会导致完整性检查失败。
设计
HARDLOG启用以下属性：
- 细粒度日志可用性（Fine-grained log availability）。HARDLOG可以确保日志条目被同步保护，或者在其创建后的一小段有界延迟内得到保护。我们的原型实现了15毫秒的有限延迟，这比最先进的日志删除攻击成功所需的时间要短得多。
- 无假篡改告警（No false tamper alarms）。HARDLOG保护其受保护的审计设备中的日志，而不是检测篡改。因此，管理员不会受到虚假篡改警报的困扰。
- 性能适度放缓（Modest performance slowdown）。HARDLOG给被监视的机器带来了适度的开销。我们的原型在不同的实际程序中，与未经审计的执行相比，只会产生6.3%的几何平均减速。
- 远端设备管理（Remote device management）。HARDLOG允许远程管理员在正常操作下(即在系统被破坏之前)安全地管理日志。发生泄漏后，HARDLOG将保持日志的安全，直到系统恢复，此时可以再次安全地检索日志。
有关设计包括：
- 防篡改审计设备的部署友好规范（deployment-friendly specifications for a tamper-proof audit device）
- 临界感知日志保护（criticality-aware log protection）
- 有界异步保护保证（bounded-asynchronous protection guarantees）——事件的日志条目都在事件执行的微小有界延迟内得到保护，采用相关实时技术（real-time techniques）
Background On System Auditing
本文主要 focus on 取证分析（forensic analysis）和定期机器健康检查（periodic machine health checks）。
Motivation
Synchronous Log Protection and its Limitations
防止日志篡改的解决方案：
- 同步存储日志(在为安全相关的事件生成日志条目并在允许该事件执行之前)
- 在一个安全的位置，一个被破坏的机器无法访问，例如网络存储服务器或一个本地防篡改存储设备
缺点：
- 性能放缓（Prohibitive performance slowdown）。由于通信延迟和设置成本高，网络和本地存储在存储小消息方面的吞吐量都很低。
- 物理设备管理（Physical device management）。商用防篡改存储设备需要经常进行物理访问，这与远程工作的加速趋势不相符。这些设备不允许远程管理员安全地检索日志或重用设备存储。
Asynchronous Log Protection and its Limitations
为了在异步存储的日志中启用信任，现有的审计系统实现了防篡改机制来检测日志篡改。它们同步地为每个日志条目创建一个完整性证明，当条目被用于分析时，使用相应的证明来检查它们的完整性。
缺点：
- 粗粒度日志可用性（Coarse-grained log availability）。现有的审计系统，即使具有明显的篡改检测机制，也不能对日志可用性提供细粒度的保证。
- 假篡改警报（False tamper alarms）。
当由于内核恐慌或审计软件崩溃而在计算过程中终止现有系统时，会发出错误警报，这会导致内存中瞬态完整性证明或日志丢失。这将导致不正确的完整性检查失败。
区分完整性检查失败 from 良性崩溃和日志篡改事件非常重要，特别是因为管理员无法使用这些可能被篡改的日志执行结论性的取证分析。
Design Principles
实用有效审计系统的三个设计原则：
- Criticality-Aware（关键性感知） Log Protection
- 不同事件表明可能妥协的能力不同。我们将其分为(a)关键事件和(b)非关键事件，并提供不同的日志保护保证。
- 之前的研究表明攻击者大多使用关键事件以高权限执行恶意代码(例如，篡改存储在主机内核内存中的日志)。
- 为了防止关键事件破坏日志，我们应该在执行关键事件之前同步保护主机中存储的所有日志。这种同步保护确保，如果攻击者在关键事件中取得控制权，则可以获得完整的攻击跟踪。
- Bounded-Asynchronous Non-Critical Log Protection（有界异步非关键日志保护）
- 在极少数情况下，即使是非关键事件也可以启用代码执行，并允许攻击者篡改日志。
- 因此，我们应该在一个小的有界时间间隔内保护所有缓冲的非关键日志条目。
- Local Log Storage with Remote Management（支持远程管理的本地日志存储）
- 为了保护日志不被主机窃取，需要将日志存储在操作系统无法触及的地方。此存储位置必须是持久的，以避免在系统崩溃时丢失日志。
- 由于许多机器都是远程的，因此管理员需要远程管理受保护的日志。特别是，远程管理员应该能够(a)安全地检索日志，(b)在不再需要重用存储时丢弃存储的日志。
- 考虑到最可行的现有选项已经需要额外的硬件(例如，使用单独存储设备的虚拟化)，我们设计了避免其缺点的新硬件。如果新硬件支持远程管理并实现内部存储访问控制，那么它可以(a)在不使用时避免系统开销，(b)具有明确的小攻击面，(c)与已经虚拟化的操作系统兼容。
Threat Model
我们假设攻击者即使在操作系统被攻破之后也无法攻破或破坏存储日志的外部审计设备。我们在§VIII-C中讨论了该装置的简洁和受限攻击面。我们忽略操作系统被入侵后生成的任何日志条目，因为它们是不可信的。此外，与之前的审计系统一样，我们不考虑物理攻击，并做出标准假设，即攻击者无法破坏加密协议并危及密钥管理。
HARDLOG Design
A. System Model
HARDLOG 有三个参与者：
- Host machine。其是必须被审计的企业机器(例如，员工笔记本电脑或台式机，公司服务器)。它有一个称为记录器的系统组件，用于监视与安全相关的事件并为它们生成日志条目。在机器启动时，日志记录器等待审计设备准备好接收日志，然后才允许发生与安全相关的事件。一旦设备准备好，日志记录器将日志发送到设备进行安全存储。主机还运行审计服务，这是设备和管理员之间的通信中继，支持远程日志检索。
- Audit device。审计设备通过设备通信接口接收来自主机的日志。设备接收到日志后，不允许对日志进行修改和删除，除非系统管理员通过安全加密通道下发命令。
- System administrator。管理员使用主机生成的日志进行取证分析和定期健康检查。管理员处于远程，通过网络与主机通信。然后，管理员使用主机的审计服务(即中继)与设备通信。
B. Audit Device Specifications
Device-interposed storage（设备间存储）
- 该设备介于主机和其控制下的持久存储介质之间，以存储日志。
- 审计设备对所有接收到的日志强制执行只追加策略，以确保所有存储的日志都具有防篡改性。只追加策略是通过单调递增的索引来描述存储传入日志条目的位置(例如，文件偏移量)。该索引安全地存储在审计设备中，只有系统管理员可以通过安全通信通道重新初始化索引以重用设备存储。
- 管理员有责任建立一个日志记录策略（logging policy），在日志被消耗(例如，发送到网络存储)之前不会耗尽日志存储空间。
Multitasking processing unit（多任务处理单元）
审计设备同时执行多个任务，因此它应该能够在这些任务之间分时共享单个处理单元，或者为每个任务提供专用处理单元。具体来说，审计设备执行三个任务:(a)在其内存中接收来自主机的日志，(b)将收集到的日志安全地存储在其存储介质中，(c)响应系统管理员的请求。
Device key pair
为了实现安全的远程管理，系统管理员和设备必须相互认证。为了实现这一点，在配置每个审计设备(例如，第一次设置企业主机)时，管理员为设备生成一个非对称密钥对，并使用它们的签名密钥对其公共部分进行认证。
Fail-safe power management
审计设备可以由主机供电以进行正常操作，但它需要一个备用电源来优雅地处理电源故障。
C. Log Protection and Storage
criticality-aware log protection（临界感知日志保护）
Synchronous critical event log protection
应用程序线程试图执行与安全相关的事件(例如，系统调用)，因此操作系统将其执行转移到内核日志记录器(1)。日志记录器为与安全相关的事件创建一个条目，并将其存储在HOSTBUF中，HOSTBUF是一个循环缓冲区，在主机的内存中保存临时日志条目(2)。
然后，记录器根据提供的关键事件列表检查事件是否为关键事件(3)。如果事件非常重要，日志记录器将等待日志发送方保护日志条目(4a)。日志发送者将存储在HOSTBUF中的所有条目(即，先前的非关键条目和当前的关键条目)传输到审计设备(红1,2)。日志发送方收到来自审计设备的确认后，日志记录器允许应用程序线程继续执行关键事件(4b)。
Asynchronous non-critical event log protection
如果事件是非关键事件，则记录器允许应用程序继续执行(4b)，而无需等待日志发送方将非关键条目发送到审计设备(即跳过4a)。日志发送方在限定的时间间隔内异步发送缓冲的非关键日志条目。
Asynchronous log storage
所有日志条目(关键和非关键)都异步存储在审计设备上。特别是，HARDLOG实现了日志接收器，一个从主机(即日志发送者)接收日志条目的设备线程。日志接收器将所有接收到的条目存储在一个循环的内存缓冲区DEVBUF中，而不是包含的存储介质(1)。这允许日志接收器快速向主机确认日志条目已到达设备(红2)。日志条目(存储在DEVBUF中)由另一个线程(日志存储器(2,3))刷新到存储介质中，该线程使用单调索引将日志条目附加到存储中，并根据存储的条目数量增加索引。
D. Bounded-Asynchronous Protection Guarantees
每个非关键日志条目在执行相应的非关键事件后的一个很小的有界延迟内被发送到审计设备。
HARDLOG使用实时技术，通过控制非关键日志条目保护管道的各个方面(从在主机上创建到在设备内存储)来实现有界异步保证。这种控制限制了非特权对手和其他后台任务减慢非关键日志条目保护的速度。
为了在给定HARDLOG约束的情况下控制这些资源，我们根据它们是否可以在需要时获得(或抢占)将它们分类为(a)可抢占资源(即CPU)和(b)不可抢占资源(即通信接口和存储)。
Preemptible resource task prioritization（可抢占的资源任务优先级）
首先，HARDLOG分别在主机和设备上以最高优先级执行日志发送方线程和日志接收方线程。因此，其他进程(包括良性进程和恶意进程)不能抢占这些线程的执行。
一个系统可能有多个最高优先级的线程。
在这种情况下，HARDLOG将剩余的(非HARDLOG)最高优先级线程限制为小于机器CPU核心的数量，以确保它始终可以抢占CPU核心(例如，在需要时运行日志发送器)。重要的是，HARDLOG不会无限期地保留CPU核心。相反，它的线程在没有日志条目产生时进入睡眠状态，从而允许其他线程使用CPU核心。
HARDLOG在运行日志发送器时禁用所有硬件设备中断，除了来自审计设备的中断和CPU内核上的Inter-Processor interrupts (处理器间中断，IPIs)，这避免了日志发送者执行过程中不受控制的延迟。
Non-preemptible resource usage control（不可抢占的资源使用控制）
HARDLOG系统使用了两个非可抢占资源，类似于主机与审计设备之间的通信接口和存储介质。由于这些资源使用了直接内存访问（DMA）引擎处理请求，所以不能直接被抢占。这可能导致优先级反转的问题，即较高优先级的请求被较低优先级的请求阻塞，从而延迟了较高优先级请求的处理。
为了解决这个问题，HARDLOG系统控制所有访问这些非可抢占资源的线程，以实现间接资源抢占并限制延迟。它允许只有特定的线程可以发送请求到资源，而其他较低优先级的线程则需要将请求分解成小块，以保证在需要执行较高优先级任务时能够中断较低优先级线程的执行。
Micro-architectural component isolation（微架构组件隔离）
HARDLOG隔离了共享微架构组件(例如，TLB和缓存)的使用，以确保非特权对手不会滥用它们来减慢日志发送者的执行。例如，如果在主机上启用了同步多线程(SMT)，攻击者可能会试图滥用（abuse）每个核心组件(如L1/L2缓存)的共享来驱逐日志发送方的缓存行，从而迫使日志发送方从内存中检索其缓存行。
如果攻击者从另一个CPU核心访问大量内存以填满LLC，则在跨核心Last-Level Cache (LLC)上也会出现类似的驱逐场景。
为了隔离每核组件，当调度日志发送器时，HARDLOG会抢占在日志发送器的CPU内核上同时执行的任何线程。这可以防止对手滥用任何核心组件。此外，为了防止滥用跨核LLC, HARDLOG采用了使用英特尔缓存分配技术(CAT)的缓存分区，该技术在最近的英特尔机器中广泛使用。
Bounded thread execution（有界线程执行）
为确保攻击者和其他任务不能干扰其日志发送者和日志接收者线程，需要为非关键日志条目设置最大保护延迟。
为了实现有界的线程执行，需要满足两个条件：
- 一是避免出现无限执行路径，即代码中没有没有带有休眠或重新调度的无限循环；
- 二是限制发送和接收线程所处理的数据量。
- 控制HOSTBUF（主机缓冲区）的大小【其大小决定了一次发送日志条目所需的时间】
在绑定线程执行后，最大日志保护延迟 $d_p$ 为 $2t_b +c$，其中 $t_b$ 是日志发送方通过设备通信接口发送整个HOSTBUF并从日志接收方接收确认所需的最大时间，而 $c$ 表示抢占其他资源所需的(恒定的)最大时间。
E. Remote Log Retrieval and Filtration（远程日志检索和过滤）
HARDLOG使系统管理员能够通过远程连接安全地从审计设备检索所有或一组经过过滤的日志条目。HARDLOG使用(a)设备和管理员之间基于主机的通信中继和(b)处理来自管理员的查询的设备查询执行库来实现。
HARDLOG使主机能够使用主机的通信接口向设备转发管理员查询。管理员和设备之间的通信是基于传输层安全(TLS)等认证密钥交换(AKE)协议进行相互认证和加密的。
HARDLOG在主机上实现一个审计服务，该服务与系统管理员创建一个网络通道来接收查询(A)。审计服务将接收到的查询发送给内核内查询处理程序(B)，后者将查询缓冲在主机内存(C)中。
然后，主机内核中的查询中继将查询发送到审计设备(D, E)。然后，审计设备接收查询(白A, B)，并使用查询执行器(白C)执行查询。设备将查询结果返回给主机审计进程，主机审计进程将查询结果转发给管理员。
HARDLOG支持以下日志过滤参数:(a)进程名称或标识符和(b)事件类型。此外，HARDLOG允许管理员删除审计设备上不再需要重用存储的日志。
Implementation
详见原文
Security Analysis and Validation
Defense Analysis
Prevent log protection slowdown attacks（防止日志保护减速攻击）：攻击者可以强调HARDLOG的日志条目保护管道，以延迟非关键日志条目的保护，以篡改尽可能多的日志条目。
- HARDLOG确保日志发送方始终以最高优先级执行，并且最高优先级的非HARDLOG线程的数量始终小于CPU内核。
- HARDLOG确保除了审计设备之外的所有IPI和硬件设备中断都不会发送到CPU核心运行日志发送方。
- HARDLOG隔离日志发送者使用的每核微架构组件(例如，TLB和L1/L2缓存)和跨核LLC分区，攻击者无法通过这些组件影响日志发送方的执行。
- 系统管理员将HOSTBUF的大小固定为发送整个缓冲区的某个最坏情况延迟界限($t_b$)
Prevent log deletion attacks（防止日志删除攻击）：
- 在特权升级之后，攻击者可以尝试(a)删除主机上的日志条目(在HOSTBUF中)，(b)要求审计设备删除日志，或者(c)切断审计设备的电源，使设备失去其内存中的瞬时日志条目(在DEVBUF中)。
- 为了防止日志删除，HARDLOG确保在关键事件执行之前，日志被同步发送到审计设备，攻击者可能获得特权(§VI-C)。对于非关键事件，HARDLOG确保有界异步保护延迟(§VI-D)。我们的实验表明，对于我们的原型，这种延迟可以小到15 ms，适合防止强攻击(§VIII-B)。
- 一旦审计设备内的条目受到保护，它就不会接受非管理员发出的日志删除请求。由于攻击者无法绕过管理员和审计设备之间的安全连接(§VI-E)，因此他们无法发送有效的日志删除请求。
Prevent log modification attacks（防止日志修改攻击）：
- HARDLOG为所有的日志修改攻击提供了一种简单的防御:设备只接受来自主机的日志，以一种只追加的方式(§VI-B)。
- 攻击者还可以尝试用日志条目填充设备，以覆盖他们的攻击跟踪。但是，如果审计设备的存储已满，它将停止接受新的日志条目。因此，攻击者无法覆盖现有日志。
- Prevent relay communication attacks（防止中继通信攻击）：
- 有特权的攻击者可以尝试破坏设备与管理员之间的主机中继通信。特别是，它们可以尝试伪造查询响应或重播以前的命令。
- 为了防止这种情况，HARDLOG在设备和系统管理员之间建立了一个安全的相互认证连接(§VI-E)(使用他们的公私钥对)。
Bounded-Asynchronous Guarantee Validation
一些实验结果见原文
Attack Surface Analysis
HARDLOG的审计设备攻击面很小且受限。
特别是，与向潜在攻击者(例如，应用程序和硬件设备)公开大量接口的主机不同，审计设备只有一个公开的接口(例如，我们原型的USB接口)。
此外，尽管我们使用Linux快速构建审计设备的原型，但在实践中，经过验证的操作系统内核或小型实时操作系统可以支持我们的简单需求。该设备可以使用现有的接口加固技术、经过验证的解析器和经过验证的加密库进一步屏蔽。
Performance Evaluation
详见原文
Discussion
- Frequent critical events：某些程序可能频繁地执行一些关键事件，并引入不可忽略的同步日志保护开销。
- Other micro-architectural components：除了LLC，其他组件(例如，缓存目录和CPU环互连)在不同的CPU内核之间共享，但硬件目前不支持隔离这些组件。
- Post-compromise log retrieval（入侵后日志检索）：即使在主机被入侵后，HARDLOG也能安全地保存日志。然而，如果受损的主机停止中继网络通信，管理员必须恢复机器以物理方式或通过远程恢复机制。
- 通过HOSTBUF导致系统减速。当内存中的日志缓冲区(例如HOSTBUF)满时，每个审计系统(包括HARDLOG)都必须暂停执行任何与安全相关事件的线程，以避免丢失日志条目。攻击者可能会滥用此功能来降低系统速度。防止此类攻击的一种方法是通过分析良性程序行为来建立每秒允许多少安全相关事件的速率限制配额。Leave this to future work
