SukkaW · cike-567 · Jul 12, 2022 · Jul 12, 2022 · Jul 12, 2022 · Jul 12, 2022
diff --git a/source/11-uefi.md b/source/11-uefi.md
diff --git a/source/12-troubleshooting.md b/source/12-troubleshooting.md
@@ -3,7 +3,7 @@ title: 12. 排错
 description: 当你遇到问题的时候应该看看这个
 type: docs
 author_info: 由 xMuu、Sukka、derbalkon、cike-567 整理，由 Sukka、derbalkon、cike-567 翻译
-last_updated: 2023-02-19
+last_updated: 2024-02-9
 ---
 
 ## 12.1 旧版 Apple 操作系统
@@ -78,8 +78,8 @@ OpenCore 的设计初衷是在 固件 和 操作系统 之间提供一个安全
 6. 使用私钥给所有已安装的驱动程序和工具签名。不要对提供管理员权限的工具（例如：UEFI Shell）签名。
 7. 加密存储你的配置，详见 [Vault](8-misc.html#12-Vault) 部分。
 8. 使用同一私钥签名该系统使用的所有 OpenCore 二进制文件（`BOOTX64.efi`, `BOOTIa32.efi`, `OpenCore.efi`, 自定义启动器）。
-9. 如果需要用到第三方操作系统（非微软或 Apple 制造）的 bootloader，也同样为它们签名。对于 Linux，可以选择安装微软签名的 Shim bootloader，具体解释见 [Debian Wiki](https://wiki.debian.org/SecureBoot)。
-10. 在 BIOS 中开启 UEFI 安全启动，并用自己的私钥安装证书。很多文章都介绍了生成证书的具体方法，比如 [这篇文章](https://habr.com/en/post/273497)，本文档不再赘述。如果需要启动 Windows，还需要添加 [Microsoft Windows Production CA 2011](http://go.microsoft.com/fwlink/?LinkID=321192) 证书。如果需要启动 Option ROM，或决定使用已签名的 Linux 驱动程序，还需要添加 [Microsoft UEFI Driver Signing CA](http://go.microsoft.com/fwlink/?LinkId=321194)。
+9. 如有需要，对所有第三方操作系统（非微软或 Apple 制造）的 bootloader 进行签名。对于 Linux，可以选择安装一个用户构建的、用户签名的 Shim bootloader，实现 `SBAT` 和 `MOK` 集成，具体说明请参见 OpenCore 源代码或发布版本中的 /utilities/shimutils 目录。
+10. 在 BIOS 中开启 UEFI 安全启动，并用自己的私钥安装证书。很多文章都介绍了生成证书的具体方法，比如 [这篇文章](https://habr.com/en/post/273497)，本文档不再赘述。如果需要启动 Windows，还需要添加 [Microsoft Windows Production CA 2011](http://go.microsoft.com/fwlink/?LinkID=321192) 证书。如果不使用用户构建的 Shim 来启动选项 ROM 或使用签名的 Linux 驱动程序，还需要 [Microsoft UEFI Driver Signing CA](http://go.microsoft.com/fwlink/?LinkId=321194)。
 11. 设置密码保护防止固件设置被篡改，避免 UEFI 安全启动在你不知情的情况下被禁用。
 
 ## 12.3 Windows 支持
@@ -88,7 +88,7 @@ OpenCore 的设计初衷是在 固件 和 操作系统 之间提供一个安全
 
 虽然 OpenCore 并没有提供官方的 Windows 支持，但是使用 Boot Camp 安装 64 位 UEFI Windows（即 Windows 8 及更高版本）应该是可以正常工作的。安装第三方 UEFI、或者仅部分支持 UEFI 引导的系统（如 Windows 7）可能需要额外注意。不论如何，记住以下几点：
 
-- MBR (Master Boot Record) 属于 Legacy 引导，因此将不会被支持。
+- MBR（Master Boot Record）安装是一种 legacy 的方式，只能在 legacy 系统上通过 OpenLegacyBoot 驱动程序进行支持。
 - 在 OpenCore 上应用的所有更改（ACPI、NVRAM、SMBIOS）都应该与操作系统本身无关。OpenCore 会将这些改动生效于所有操作系统，这样在 Windows 上可以获得 Boot Camp 的体验。
 - macOS 要求硬盘中的第一份分区为 EFI 分区，并且与 Windows 的默认布局不支持。尽管 OpenCore 确实提供了一个 [解决方法](https://github.com/acidanthera/bugtracker/issues/327)，但是强烈建议不要依赖这个方法。
 - Windows 系统可能需要重新激活。为了避免这种情况发生，请考虑将 SystemUUID 设置为原始固件的 UUID。请注意，在旧固件上 UUID 可能是无效的（非随机的）。如果你还遇到了什么问题，可以考虑使用 HWID 或 KMS38 的 Windows 许可证。从 OpenCore 0.5.8 开始，你还可以通过设置 `UpdateSMBIOSMode` 为 `Custom` 来避免 OEM 激活失效。Windows 激活的细节不在本文档的讨论范围内，你应该能够在网上查找到相关资料。

diff --git a/source/4-acpi.md b/source/4-acpi.md
@@ -3,7 +3,7 @@ title: 4. ACPI
 description: 加载、屏蔽、修补 ACPI（DSDT/SSDT）表
 type: docs
 author_info: 由 Sukka、cike-567 整理、由 Sukka、derbalkon、EricKwok、cike-567 翻译。感谢黑果小兵提供的参考资料
-last_updated: 2022-08-04
+last_updated: 2023-05-22
 ---
 
 ## 4.1 简介

diff --git a/source/5-booter.md b/source/5-booter.md
@@ -3,7 +3,7 @@ title: 5. Booter
 description: 配置 OpenRuntime.efi（Slide 值计算、KASLR）
 type: docs
 author_info: 由 Sukka、derbalkon、cike-567 整理，由 Sukka、derbalkon、cike-567 翻译。
-last_updated: 2022-08-04
+last_updated: 2024-02-09
 ---
 
 ## 5.1 简介
@@ -246,7 +246,43 @@ Description: 搜索的最大字节数。
 
 *注*：这个 Quirk 可能会潜在地削弱固件的安全性。如果你的固件支持内存属性表 (MAT)，请优先使用下文中的 `RebuildAppleMemoryMap` Quirk。是否支持 MAT，请参考 `OCABC: MAT support is 1/0` 日志条目来确定。
 
-### 9. `ForceBooterSignature`
+### 9. `FixupAppleEfiImages`
+
+**Type**: `plist boolean`
+**Failsafe**: `false`
+**Description**: 修复在早期 Mac OS X 引导时出现的错误。
+
+由于这些文件包含 WˆX 错误（在所有版本中）和非法的重叠部分（仅在 10.4 和 10.5 的 32 位版本中），现代安全的 PE 加载器将拒绝从 macOS 10.4 到 10.12 加载 `boot.efi 镜像。
+
+这个 Quirk 可以检测这些问题并在内存中对这些镜像进行预处理，以便现代加载器可以接受它们。
+
+内存中的预处理与安全引导不兼容，因为加载的镜像与磁盘上的镜像不同，所以无法根据它们原始的磁盘镜像内容对以这种方式加载的文件进行签名。某些固件可以注册新的、未知镜像的哈希值——这仍然有效。另一方面，希望通过安全引导启动这些早期的、不安全的图像也不是特别现实的。
+
+*注 1*：这个特殊处理在较新版本的 macOS 中从未应用于苹果安全引导路径。苹果安全引导路径包括对 boot.efi 的 W^X 问题的独立应对措施。
+
+*注 2*：当启用并在处理苹果安全引导时，此 Quirk 被应用：
+
+- 所有来自 Apple 的 FAT 二进制文件（32 位和 64 位版本合并在一个镜像中）。
+- 所有 Apple 签名的镜像。
+- 文件系统中 `\system\Library\corsexvices\boot.efi` 中的所有镜像。
+
+*注 3*：这个 Quirk 在 macOS 10.4 到 10.12（以及更高版本，苹果安全引导未启用）时是必需的，但前提是固件本身包含现代、更安全的 PE COFF 镜像加载器。这适用于当前版本的 OpenDuet，以及如果是从 `audk` 源代码构建的 `OVMF`。
+
+### 10. `FixupAppleEfiImages`
+
+**Type**: `plist boolean`
+**Failsafe**: `false`
+**Description**: 修复早期 Mac OS X `boot.efi` 镜像中的错误。
+
+现代安全的 PE 加载器将拒绝加载来自 Mac OS X 10.4 和 10.5 的 `boot.efi` 镜像，因为这些文件包含 `W^X` 错误和非法重叠的部分。
+此特殊处理程序检测这些问题并在内存中对这些图像进行预处理，以便现代加载器可以接受它们。
+在内存中的预处理与安全启动不兼容，因为加载的图像不是磁盘上的图像，所以不能根据其原始磁盘图像内容签署文件。某些固件将提供注册新的未知图像的哈希值的选项 - 这仍将起作用。另一方面，无论如何，希望使用安全启动启动这样早期的不安全图像实际上并不切实际。
+
+*注 1*：该特殊处理程序仅适用于苹果特定的 “fat”（32 位和 64 位版本合并为一个镜像）`.efi` 文件，并且在较新版本 macOS 的苹果安全引导路径中永远不会应用。
+
+*注 2*：只有在加载 Mac OS X 10.4 和 10.5 时才需要此特殊处理程序，即使是在固件本身包含现代更安全的 `PE COFF` 镜像加载程序的情况下也是如此。这包括当前的 `OpenDuet` 构建。
+
+### 11. `ForceBooterSignature`
 
 **Type**: `plist boolean`
 **Failsafe**: `false`
@@ -256,7 +292,7 @@ Description: 搜索的最大字节数。
 
 *注*：OpenCore 启动器路径由 `LauncherPath` 属性决定。
 
-### 10. `ForceExitBootServices`
+### 12. `ForceExitBootServices`
 
 **Type**: `plist boolean`
 **Failsafe**: `false`
@@ -266,7 +302,7 @@ Description: 搜索的最大字节数。
 
 *注*：是否启用这个 Quirk 取决于你是否遇到了 Early Boot 故障。除非你详细了解这一选项可能导致的后果，否则请勿启用这一选项。
 
-### 11. `ProtectMemoryRegions`
+### 13. `ProtectMemoryRegions`
 
 **Type**: `plist boolean`
 **Failsafe**: `false`
@@ -281,7 +317,7 @@ Description: 搜索的最大字节数。
 
 *注*：是否启用这一 Quirk 取决于你是否遇到了休眠、睡眠无法唤醒、启动失败或其他问题。一般来说，只有古董固件才需要启用。
 
-### 12. `ProtectSecureBoot`
+### 14. `ProtectSecureBoot`
 
 **Type**: `plist boolean`
 **Failsafe**: `false`
@@ -291,7 +327,7 @@ Description: 搜索的最大字节数。
 
 *注*：这个 Quirk 主要试图避免碎片整理导致的 NVRAM 相关问题，例如：Insyde 或 `MacPro5,1`。
 
-### 13. `ProtectUefiServices`
+### 15. `ProtectUefiServices`
 
 **Type**: `plist boolean`
 **Failsafe**: `false`
@@ -305,7 +341,7 @@ GRUB-shim 对各种 UEFI image services 进行了类似的即时更改，这些
 
 *注 2*：如果 OpenCore 是从启用了 BIOS 安全启动的 GRUB 中链式加载的，则需要这个 Quirk。
 
-### 14. `ProvideCustomSlide`
+### 16. `ProvideCustomSlide`
 
 **Type**: `plist boolean`
 **Failsafe**: `false`
@@ -315,7 +351,7 @@ GRUB-shim 对各种 UEFI image services 进行了类似的即时更改，这些
 
 *注*：OpenCore 会自动检查是否需要启用这一选项。如果 OpenCore 的调试日志中出现 `OCABC: Only N/256 slide values are usable!` 则请启用这一选项。
 
-### 15. `ProvideMaxSlide`
+### 17. `ProvideMaxSlide`
 
 **Type**: `plist integer`
 **Failsafe**: `0`
@@ -325,7 +361,7 @@ GRUB-shim 对各种 UEFI image services 进行了类似的即时更改，这些
 
 *注*：当 `ProvideCustomSlide` 启用、并且随机化的 slide 落入不可用的范围时，如果出现随机的启动失败，则有必要开启这个 Quirk。开启 `AppleDebug` 时，调试日志通常会包含 `AAPL: [EB|‘LD:LKC] } Err(0x9)` 这样的信息。如果要找到最合适的值，请手动将 `slide=X` 追加到 `boot-args` 里，并用日志记录下不会导致启动失败的最大值。
 
-### 16. `RebuildAppleMemoryMap`
+### 18. `RebuildAppleMemoryMap`
 
 **Type**: `plist boolean`
 **Failsafe**: `false`
@@ -340,7 +376,7 @@ Apple 内核在解析 UEFI 内存映射时有几个限制：
 
 *注 2*：根据是否遇到第一阶段启动失败再决定是否启用这一 Quirk。在支持内存属性表 (MAT) 的平台上，这一 Quirk 是 `EnableWriteUnprotector` 更好的替代。在使用 `OpenDuetPkg` 时一般是不需要启用这个 Quirk 的，但如果要启动 macOS 10.6 或更早的版本则可能需要启用，原因暂不明确。
 
-### 17. `ResizeAppleGpuBars`
+### 19. `ResizeAppleGpuBars`
 
 **Type**: `plist boolean`
 **Failsafe**: `-1`
@@ -358,7 +394,7 @@ Apple 内核在解析 UEFI 内存映射时有几个限制：
 
 *注*：请参阅 `ResizeGpuBars` quirk 了解 GPU PCI BAR size 配置和有关该技术的更多详细信息。
 
-### 18. `SetupVirtualMap`
+### 20. `SetupVirtualMap`
 
 **Type**: `plist boolean`
 **Failsafe**: `false`
@@ -368,15 +404,15 @@ Apple 内核在解析 UEFI 内存映射时有几个限制：
 
 *注*：是否启用这个 Quirk 取决于你是否遇到了 Early Boot 故障。
 
-### 19. `SignalAppleOS`
+### 21. `SignalAppleOS`
 
 **Type**: `plist boolean`
 **Failsafe**: `false`
 **Description**: 不论使用什么操作系统，总是向 OS Info 报告启动的是 macOS。
 
 Mac 设备在不同的操作系统中具有不同的行为，因此如果你在使用 Mac 设备，这一功能会非常有用。例如，你可以通过启用这一选项为某些双 GPU 的 MacBook 型号中在 Windows 和 Linux 中启用 Intel GPU。
 
-### 20. `SyncRuntimePermissions`
+### 22. `SyncRuntimePermissions`
 
 **Type**: `plist boolean`
 **Failsafe**: `false`

diff --git a/source/7-kernel.md b/source/7-kernel.md
@@ -3,7 +3,7 @@ title: 7. Kernel
 description: OpenCore 安全配置，Kext 加载顺序以及屏蔽
 type: docs
 author_info: 由 Sukka、derbalkon、cike-567 整理，由 Sukka、derbalkon、cike-567 翻译。
-last_updated: 2022-08-04
+last_updated: 2024-02-09
 ---
 
 ## 7.1 简介
@@ -437,7 +437,7 @@ last_updated: 2022-08-04
 **Requirement**: 10.4
 **Description**: 禁用 `AppleIntelCPUPowerManagement.kext` 中的 `PKG_CST_CONFIG_CONTROL` (`0xE2`) 修改，从而避免早期 Kernel Panic。
 
-*注*：`AppleIntelCPUPowerManagement.kext` 自 macOS 13 起，已被删除。但是，可以注入旧版本 macOS 并使用此 `quirk` 进行修补。
+*注*：`AppleIntelCPUPowerManagement.kext` 自 macOS 13 起，已被删除。但是，可以注入旧版本 `AppleIntelCPUPowerManagement.kext` 并使用此 `quirk` 进行修补。
 
 某些固件会锁定 `PKG_CST_CONFIG_CONTROL MSR` 寄存器。可以使用附带的 `ControlMsrE2` 工具检查其状态。请注意，某些类型的固件仅将此寄存器锁定在某些内核上。由于现代固件已经提供了 `CFG Lock` 相关设置、从而可以配置 `PKG_CST_CONFIG_CONTROL` 寄存器锁定，此选项应该尽可能避免。
 
@@ -534,9 +534,9 @@ last_updated: 2022-08-04
 **Requirement**: 13.3(not required for older)
 **Description**: 在 IOMMU(VT-d) 中禁止映射 PCI 桥接设备内存。
 
-*注 1*：当在本机的 `DMAR` 表中包含一个或多个保留内存区域且启用iGPU并且安装了超过16 GB内存的系统上启用 AppleVTD 时，此选项解决了与 Wi-Fi、以太网和 Thunderbolt 设备的兼容性问题。
+这个选项解决了在原生 `DMAR` 表包含一个或多个保留内存区域且安装了超过 16 GB 内存的系统上启用 AppleVTD 时与 Wi-Fi、以太网和 Thunderbolt 设备的兼容性问题。在某些系统上，只有在启用 iGPU 时才需要这个 Quirk。
 
-*注 2*：在 AMD 系统上不需要这个选项。
+*注 1*：在 AMD 系统上不需要这个选项。
 
 ### 9. `DisableLinkeditJettison`
 
@@ -746,7 +746,12 @@ macOS 10.7 和更早版本中，XNU 内核可能不会使用 `x86_64` 架构来
 6. 当没有设置为 `Auto` 时，`KernelArch` 会把系统支持限制在明确指定的架构（如果该架构兼容）。
 7. 按以下顺序选择参数可以获得最佳的架构支持：`x86_64`、`i386`、`i386-user32`。
 
-macOS 10.7 只会将特定的主板标识符视为仅 `i386` 架构的设备，macOS 10.5 或更早版本的内核则不支持 `x86_64`，而 macOS 10.6 非常特殊，与这二者都不同。macOS 10.6 上的架构选择取决于很多因素，不仅包括主板标识符，还包括 macOS 的类型（客户端 或 服务器端）、macOS 发布时间和内存容量。检测这些因素很复杂，也不实用，因为好几个发布版本都有 bug，不能在第一时间正确地进行服务器检测。因此，对于 macOS 10.6，无论主板支持情况如何，OpenCore 都会回退到 `x86_64` 架构，就像 macOS 10.7 那样。以下是 64 位 Mac 型号的兼容性介绍，对应于 macOS 10.6.8 和 10.7.5 EfiBoot 的实际行为：
+macOS 10.7 只会将特定的主板标识符视为仅 `i386` 架构的设备，macOS 10.5 或更早版本的内核则不支持 `x86_64`，而 macOS 10.6 非常特殊，与这二者都不同。macOS 10.6 上的架构选择取决于很多因素，不仅包括主板标识符，还包括 macOS 的类型（客户端 或 服务器端）、macOS 发布时间和内存容量。检测这些因素很复杂，也不实用，因为好几个发布版本都有 bug，不能在第一时间正确地进行服务器检测。因此，对于 macOS 10.6，无论主板支持情况如何，OpenCore 都会回退到 `x86_64` 架构，就像 macOS 10.7 那样。
+
+与 macOS 10.7 不同（其中某些主板标识被视为仅支持 i386 架构的机器），以及 macOS 10.5 或更早版本（其中 macOS 内核不支持 x86_64 架构），macOS 10.6 则非常特殊。macOS 10.6 的架构选择取决于许多因素，包括不仅是主板标识，还包括 macOS 产品类型（客户端 vs 服务器）、macOS 版本发布，以及内存量。检测所有这些因素是复杂且不切实际的，因为几个版本存在实现缺陷，导致无法正确执行首次服务器检测。因此，出于这个原因，当设置为 Auto 时，OpenCore 在 macOS 10.6 上会在受支持的情况下回退到 x86_64 架构，就像 macOS 10.7 一样。然而，仍然可以显式配置 32 位 KernelArch 选项。
+
+
+以下是 64 位 Mac 型号的兼容性介绍，对应于 macOS 10.6.8 和 10.7.5 EfiBoot 的实际行为：
 
  | **Model** | **10.6 (minimal)** | **10.6 (client)** | **10.6 (server)** | **10.7 (any)** |
  | ---------- | ------------------ | ----------------- | ----------------- | ---------------- |