在这个页面 https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/intel-debug-technology.html有几个关于 Intel 平台调试基本概念。
首先，如同使用工具进行测量一定会有误差一样，产品天生会有Bug，一些用户要求的产品特性在另外一些用户严重就是Bug。比如，当Setup 中设置 USB Controller 为 Disable 之后，有些用户会发现仍然能够通过USB键盘进入 BIOS Setup界面，而有的用户则会抱怨修改之后USB键盘完全失效，甚至无法进去BIOS Setup 修改选项。芯片产品更有芯片级调试的需求。但是调试不可避免的碰到用户的数据，比如：反编译追踪，另外这种技术还可能会被用于破解产品，比如，经过研究让客户设计只能运行 Windows的平台能够运行 Linux这种。因此，只能尽量在二者之间寻找平衡点。以我的经验而言，市面上大多数XX产品留有后门的新闻中提到的所谓的“后门”通常都只是预留的调试接口。
对于这种平衡，Intel 采用的策略主要是：区分开发者/调试者和最终用户的策略。比如，开发者的权限更高，能够读写一些最终用户无法看到的寄存器这种。
下面是产品声明周期的示意图，可以看到包含4个阶段：
- 芯片的生产制造à2.交给厂商制造电路（比如：主板）à3.厂商制造机器（比如: 笔记本、平板等等）à4.返修。其中的1 2 过程是明显需要有调试能力的，作为BIOS工程师通常工作在这两个阶段。在阶段3之后就要交付给客户了。
为了解决调试和安全之间的矛盾，提出了“Protection Classes”的概念。它是用来控制当前能进行的系统级别调试能力的。它分为三个级别：
- Public (之前也被称作“Green”或者“Locked”)。这个级别是普通用户能够接触到的级别，安全等级最高，调试能力最低
- “OxM(之前也被称作“Orange”或者“OEM UnLocked”)。这个级别在 Public 级别上增加了更多的调试能力。这个级别假定的用户是 OxM 厂商。
- “Intel”(之前也被称为“Read”或者 “Intel Unlocked”)。比前一个 OxM具有更高的调试能力。因为这个级别需要Intel 授权，假定的用户是 Intel。
个人感觉，诸如 BIOS Debug Log 或者 EC log 是 OxM 级别的调试手段，特别是EC 的数据也只有 OxM 能够获取（需要特别版本的 EC Firmware）,同时也只有 OxM才能解读。
为了更好的平衡调试和用户隐私的关系，Intel 引入了Hardware-based Policy Protection 用于管理调试能力。在特殊情况下，可以通过左侧的 Hardware-based Authentication Logic 和 Security Processor 打开目标机的调试能力，对应的右侧的Block X 是SoC 内部的IP，每一个IP 都有预留的用于调试的功能（Debug Capability）。
在上电过程中，会有一个窗口期，如果在这个事件段内有Intel授权，那么可以打开调试功能。（There is a limited time during the boot for which this feature can be used by an Intel entity (i.e., an entity authenticated by a per-part Intel key hash stored in the product). The entity must perform the authentication (and unlocking) through this hardware-based mechanism before any secure assets are distributed from its rest location (note: “rest location” refers to where an asset is stored)）
但是注意，前面提到默认情况下是一个“窗口期”，如果过了这个时间点，那就不行（除非再次上电）。如果想让再任何时候都能够进行调试，那么需要打开 Delayed Authentication 功能，这个可以在 FIT 中设置，也可以在BIOS Setup界面设置。二者是等效的，BIOS 的设置也是告知 CSME 进行调整。所以，Delayed Authentication的作用是：让芯片处于正常模式，当有调试需要的时候再打开调试功能进行 Dbc或者CCA 的连接。