WWW.LAB-Z.COM

之前的代码中，没有对 SET_IDLE 进行处理，所以会使用 STALL 进行回复。这次的目标是在代码中添加处理的代码。

作为比对，正常情况下应该使用下面的方式处理：

                /* 分析并处理当前的SETUP包 */
                len = 0;                                                                      // 默认为成功并且上传0长度
                status = 0;
                if (( UsbSetupBuf->bRequestType & USB_REQ_TYP_MASK ) != USB_REQ_TYP_STANDARD )  /* 非标准请求 */
                {
                        // 处理 HID_SET_IDLE
                        if ((UsbSetupBuf->bRequestType==0x21)&&(SetupReqCode==HID_SET_IDLE)) {
                                printf("SETUP HID_SET_IDLE\n");
                                R16_UEP0_T_LEN1 = 0;
                                R8_UEP0_TX_CTRL1 = UEP_DATA1 | UEP_T_RES_ACK;                    // 默认数据包是DATA1
                                return ;
                        }
                        status = 0xFF;  // 操作失败
                }

修改之后的运行结果：

完整代码如下：

CSME 算是 Intel X86 PC 上最神秘的部分了，本文根据 us-19-Hasarfaty-Behind-The-Scenes-Of-Intel-Security-And-Manageability-Engine 一文写成。讲述内容无法证伪，各位随便听听即可，了解这些能够帮助BIOS 工程师更好的理解一些操作的实现。文章基于 Intel 第八代第九代CPU（Coffee Lake 和 Whiskey Lake）进行描述。

第一个问题，什么是 CSME? 这是 Converged Security and Manageability Engine  (我翻译成“集中式安全管理引擎”)的缩写 ，或者更简单称作 ME（对于一些小核系统，因为没有管理功能（Manageability），所以会缩写成 CSE，但是我并不建议这样做，因为容易引起误解） :

我的笔记本电脑上，设备管理器中可以看到这个设备。

第二个问题，CSME提供了什么功能。

从图中可以看到 CSME 位于PCH 中，对外可以通过 LAN 和 WIFI 直接通讯

从资料上看，引入这个设备可以提供如下功能：

1. 对当前系统提供安全保护。比如， BootGuard 功能；
2. 频率控制。比如，我们在 FIT中可以看到一些关于 PCIE Clock Request 之类的设定。上电之后CSME 先于CPU运行，因此一些时钟信号可以由 CSME 准备好，之后再提供给 CPU；
3. 加载一些Patch给 PCH/CPU；
4. 提供一些运行期的安全服务，比如：TPM ，DRM（Digital Rights Management，数字版权保护技术，能够阻止在未经授权的机器上播放带有版权保护的视频），DAL（Intel® Dynamic Application Loader，能够将Java 代码放在 CSME 中执行，这样能够更好的防止被破解【参考2】）
5. AMT （Intel Active Management Technology, 英特尔主动管理技术）, 这是企业版 PCH 才有的功能，打开这个功能后下，配合部署的管理软件能够实现一些远程管理功能。比如，通过 Gbe提供的网络功能远程登陆查看当前屏幕信息。理论上有了这个功能，只要能开机IT工程师就可以远程控制你的电脑来完成装系统等等工作，我见过实验室测试这样的功能，但从未见过有人使用这样的功能进行系统维护。同样的 Vpro 也是基于这个功能。因为这个功能能够“远程开机”和“监视屏幕”，所以这个功能经常被认为是 Intel 后门，但实际上这个是预留给局域网管理员的管理功能，好比：远程桌面或者TeamViewer 这种软件。另外，如果用过这个功能的人都会知道，当它进行屏幕监视的时候，会有大大的提示信息。

第三个问题：CSME 的硬件架构。

上图中最右侧CSME 内部有一个独立的 CPU （可以用 EC 进行类比），是一个32位 Intel 486 级别的CPU。SRAM 是独立于系统内存，有 1.5MB左的大小。正是因为有独立 CPU 和 SRAM 的存在，所以 CSME 能够监控CPU。此外们还有 ROM ，里面存放着固化的内容，是整个信任链的根节点。

System Agent 提供了CSME 和外部进行数据交换的接口。

OCS (Offload & Cryptography Subsystem)：提供了加密算法的加速硬件，同时存放一些安全相关的密钥。比如，Secure Boot 的Private Key 之类都是存放在这里的。

Gasket 提供了对 PCH fabric 的接口和 CSME 的 IO 接口，例如：TPM 和 HECI (Management Engine Interface)，最前面我设备管理器中可以看到有一个 HECI Controller。

Manageability Devices：用于控制管理和重定向设备，比如，你通过网络访问这个电脑，那么需要将键盘鼠标重定向到网络上。

Protected Real Time Clock: 带有保护的时钟。很多时候，需要从时间之类生成随机种子，如果从外部获取时间，很容易被欺骗，因此这里有一个内置的时钟。

从上面可以看到，当我们谈论烧写在主板SPINOR 的时候，可能提到的是 IFWI (Integrated FirmWare Image)，就是我们使用 FIT 打开的那个 Image，也可能是 BIOS 本身（或者说 IFWI 中的 BIOS Region）。一般情况下，当我们使用 SF100 这样的工具进行烧写时，烧录上的是  IFWI (SF100无法区分具体哪个是 ME 哪个部分是BIOS Region，所以是完全擦写的)，而当我们在 Windows 下或者 Shell 下烧写时，有可能是 IFWI 或者是BIOS， 软件本身有能力区分具体要求。所以，某天你给别人提供Image 时，最好明确你提供的是 IFWI 还是 BIOS Image。

在中文的世界中，“辐射”这个词有多种含义，比如：电磁辐射和电离辐射。前者无处不在，能够帮助我们看到东西，能够帮助我们进行通讯。后者也能帮助我们看到肉眼无法看到的东西，比如：X光测试，甚至之前的CRT显示器内部也存在着这种“辐射”。正是因为这样的误解，使得手机基站在很多小区成为大妈喊打的东西。前面提到的CSME 的“监控”也是这样，更多时候只能查看CPU 的状态，但是在很多人眼中它能够“监视”和“控制”用户的数据—-不过至少现在我还没有看到这样的实例。

参考：

1. https://software.intel.com/content/www/cn/zh/develop/tools/dal/overview.html

=============================================================

2024年1月2日 有兴趣可以阅读来自 Intel 官方的文档

https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel-csme-security-white-paper.pdf

有时候我们希望直接查看当前系统下的全部 PCI 设备信息，可以使用下面的命令：

wmic path Win32_PnPEntity where "PNPDeviceID like '%VEN%'" get PNPDeviceID, Status, Manufacturer, Service

方法来自：http://programming.realworldrobotics.com/editors-ides/command-line-in-windows/wmic-snippets

Job Title

Firmware/BIOS Quality Engineer

Job Responsibility:

In this position, you will be part of the Firmware Integration and Validation (FIV) Team within SATG responsible for UEFI Firmware/BIOS quality assurance on Intel server platforms. Behavioral traits for this position include: validation infrastructure and test case development, in-depth bug investigation and fix, good communication and problem solving skills, multi-tasking, self-motivation and the ability to collaborate with internal/external stakeholders.

The candidate’s responsibilities will include but not limit to:

• Design and develop framework and utility for IP/module level validation according to module specifications, such as PRD, HAS etc;
• Be responsible for test case development according to product requirement for server BIOS;
• Be responsible for the test execution on Intel server platform for BIOS and platform FW test;
• Work with team members to investigate test failures using variety of debug tools to perform evaluation of the issue and identify the failure to component or code level;
• Be responsible for developing and sustaining the automation test framework, test scripts and utilities; deploy and maintain automation test cases, analyze test reports and logs.

Qualifications:

The candidate should possess a Master or a Bachelor degree in computer science, Computer Engineering or a related field, with at least 5 years industrial experience on BIOS development or testing. Additional qualifications include:

• Solid knowledge of BIOS and UEFI Firmware;
• Deep understanding of server architecture of both HW and SW;
• Deep understanding of industry specification such as UEFI/ACPI/SMBIOS/TPM/etc;
• Software development skills with different programming languages include but not limited to: C/C++/C#, Python, Windows Batch Script, JavaScript, etc;
• Solid experience of software testing process and methodologies;
• Skilled in BIOS test case development and issue debugging;
• Good English communication skill in reading and writing, good speaking capability;
• Knowledge of Linux Kernel or device driver development is a plus.

有兴趣的朋友可以直接联系：jinghua.xu@intel.com

除了SPD 中给出的参数，在内存初始化时，CPU 还需要有针对性的获得一些参数，而这些参数和生产制造环境温度等等情况有关系（听起来时玄学）。因此，在开机的时候内存控制器会进行一个 Memory Training 的动作。比如，当前内存槽上有2根内存，但是因为线长的原因，同样的信号到达内存的时间不同。在开机的时候，内存控制器就发出一个信号分别给两个内存，内存收到信号后发送一个应答。根据回复的时间不同，内存控制器可以取得一个能够让两个内存都工作正常的时序。当然，这里只是非常粗略的介绍，实际上这个过程非常复杂，耗时也会很久。而Training完成后，BIOS会将取得的参数保存在SPI NOR 上。这也是为什么第一次刷过BIOS之后开机要很久的原因。

一些情况下，我们希望强制进行 Memory Training，通常的方法是进行 Clear CMOS。这次提供了一个 Windows 工具，运行之后重启，SoC 即会进行完整的 Memory Training。

适用范围： ADL-P/M 平台的设备

这一次使用 CH567 制作一个USB键盘，参考的对象是Dostyle 的MK60 机械键盘。

同样的，使用 USBlyzer 抓取描述符信息：

USB Composite Device

Device Descriptor Gaming KB

Configuration Descriptor 1 Bus Powered, 500 mA

Interface Descriptor 0/0 HID, 1 Endpoint

HID Descriptor

Endpoint Descriptor 81 1 In, Interrupt, 1 ms

Interface Descriptor 1/0 HID, 1 Endpoint

HID Descriptor

Endpoint Descriptor 82 2 In, Interrupt, 1 ms

Interface 0 HID Report Descriptor Keyboard

Interface 1 HID Report Descriptor System Control

This report was generated by USBlyzer

需要特别注意的是：这个设备是 USB Full Speed(12Mbits/s)的，必须在文件头部设置为 Full Speed，如果继续使用 Low Speed，插入之后读取描述符后 Host就会停止继续发送数据（Windows 行为，我不知道原因）。

除此之外，和之前的鼠标代码相比还增加了一个HID 描述符，另外，在 Main 中定时发送打开Windows 菜单（Win按键）。

USB Host Shield 本身是支持USB Hub的，这样我们可以方便的一次性连接多个USB 设备。这次以USB 键盘为例进行测试。

USB Hub 的使用还是比较简单的，连接好之后，建议运行 USB_Host_Shield_Library_2.0\examples\hub_demo 这个示例代码进行测试，它会枚举当前USB Hub上的所有 USB 设备的描述符信息，通过这样的方法我们可以知道硬件是否能够工作正常。

前述代码测试通过后，我们就可以编写代码来获得按键信息了。

1. KBUnderHub.ino 代码中必须使用 USBHub ，之后，因为测试有3个键盘，所以要声明 kb1 到 kb3 三个设备

USB Usb;

USBHub Hub(&Usb);

KBSET kb1(&Usb);

KBSET kb2(&Usb);

KBSET kb3(&Usb);

2. KeyboardSets.h 代码中，申明一些我们需要的结构体如下：

// 当前支持的键盘数量
#define KBNUM 3

class KBSET : public HIDUniversal {
  public:
    KBSET(USB *p) : HIDUniversal(p) {};
    bool connected() {
      return HIDUniversal::isReady();
    };
    // 本次收到数据的键盘编号
    uint8_t  Current;
    // 存放第x个键盘是否有改变发生的标记
    bool     Changed[KBNUM];
    // 存放第x个键盘当前收到的缓冲区长度
    uint8_t  BufferSize[KBNUM];
    // 存放第x个键盘收到的缓冲区数据
    uint8_t  Buffer[KBNUM][64];
    // 存放第x个键盘的PID 和 VID
    uint16_t PID[KBNUM];
    uint16_t VID[KBNUM];
  private:
    void ParseHIDData(USBHID *hid, bool is_rpt_id, uint8_t len, uint8_t *buf); // Called by the HIDUniversal library
    uint8_t  BufferSizeOld[KBNUM];
    uint8_t  BufferOld[KBNUM][64];
    // 当前收到的键盘数据总数
    uint8_t  TotolKB;
    uint8_t OnInitSuccessful() { // Called by the HIDUniversal library on success
      KBSET::TotolKB = 0;
      for (uint8_t j = 0; j < KBNUM; j++) {
        for (uint8_t i = 0; i < 64; i++) {
          KBSET::BufferOld[j][i]=0xFF;
        }
      }
      return 0;
    };
};

3. KeyboardSets.cpp

#include "KeyboardSets.h"

void KBSET::ParseHIDData(USBHID *hid, bool is_rpt_id, uint8_t len, uint8_t *buf) {
  /*
    if (len && buf)  {
      Notify(PSTR("\r\n"), 0x80);
      for (uint8_t i = 0; i < len; i++) {
        D_PrintHex<uint8_t > (buf[i], 0x80);
        Notify(PSTR(" "), 0x80);
      }
    }
  */

  // 在 KBSET 中查找记录
  KBSET::Current = 0xFF;
  for (uint8_t i = 0; i < KBNUM; i++) {
    //
    if ((KBSET::PID[i] == HIDUniversal::PID) && (KBSET::VID[i] == HIDUniversal::VID)) {
      KBSET::Current = i;
    }
  }
  // 如果查找不到
  if (KBSET::Current == 0xFF) {
    KBSET::Current = KBSET::TotolKB;
    KBSET::PID[KBSET::Current] = HIDUniversal::PID;
    KBSET::VID[KBSET::Current] = HIDUniversal::VID;
    KBSET::BufferSize[KBSET::Current] = len;
    KBSET::TotolKB++;
  }

  // 检查本次数据和上次数据是否有差别
  if (memcmp(BufferOld[KBSET::Current], buf, len) == 0) {
    // 没有差别
    KBSET::Changed[KBSET::Current] = false;
  } else {
    memcpy(Buffer[KBSET::Current], buf, len);
    // 有差别
    KBSET::Changed[KBSET::Current] = true;
    memcpy(BufferOld[KBSET::Current], buf, len);
    Serial.print("VID:"); Serial.print(KBSET::VID[KBSET::Current],HEX);
    Serial.print(" PID:"); Serial.println(KBSET::PID[KBSET::Current],HEX);
    for (uint8_t i = 0; i < KBSET::BufferSize[KBSET::Current]; i++) {
      Serial.print((byte)(KBSET::Buffer[KBSET::Current][i]), HEX);
      Serial.print(" ");
    }
    Serial.println("");
  }
}

工作流程：当有按键事件发生时，库会调用 ParseHIDData() 这个函数，从设备获得的设备数据放在buf，产生数据的设备PID和 VID 在HIDUniversal::PID和HIDUniversal::VID中。之后，我们会在KBSET::PID VID数组中查找当前产生数据的设备是否已存在，如果没有话，将这个设备的PID和VID 加入数组中。之后再将改设备产生的数据存放到Buffer 中。之后，再判断新取得的数据和之前的BufferOld中保存的是否相同，如果相同就打印输出。

这样，我们就能分别获得三个设备产生的按键信息。

我是用了一个大键盘，一个小键盘和一个barcode scanner 作为测试设备，可以看到串口能够输出。

工作测试的视频：

https://www.bilibili.com/video/BV1nu411q7i7?share_source=copy_web

完整代码下载：

使用 MAX3421e 一个潜在的风险是：芯片本身价格高，比如前一段这个芯片价格炒到50以上，并且有假货。

最近在研究FAT32 格式，研究的目标是一个256MB容量的虚拟硬盘。

最开始发现资料和手上的结果多有出入无法对的上。经过两天的研究恍然大悟：对不上是因为这个硬盘在FAT前面还有分区信息，就是说对于一个硬盘来说要先读取分区的划分信息，比如第一个分区是FAT32，第二个分区是NTFS……..之后再根据不同的分区类型解析出文件内容。

目前主流分区有2种：一种是传统的 MBR；另外一种是比较新的 GPT。这次实验的硬盘是GPT 分区。

硬盘整体数据分布如下，解析是从左到右的顺序：

布局分布【参考1】

为了方便查看数据，使用 WinHex 这个磁盘工具。

1.使用WinHex进行查看，打开硬盘：

2.可以看到这个U盘上有“Start Sectors” 、“Partition 1（e:）”和“Partition gap”三块内容。对于OS来说 Partition 1 就是展现给用户的 e盘。

3.具体分析

3.1 Start Sectors 对应着LBA 0-33，使用WinHex 自带模板分析

分析结果如下：

这是一个保护性的“假MBR”，作用是防止不识别GPT分区的格式意外破坏分区。0x0-0x1FF偏移（在LBA0中）：提供了一个 Partition 的数组， EDK2示例代码会检查这里确定是“假MBR”；0x200-0x258 偏移（在LBA1中）：给出第一个分区信息表的入口（Partition Entry LBA），一般为2，意思是这个信息表入口在 LBA 2 上；0x400-0x4A0偏移（在 LBA2中）：给出第一个分区的入口（Starting LBA），这里可以看到第一个分区从 LBA 2048(D)开始

3.2 选中第一个分区，可以看到它位于 0x100000处（也就是 LBA 2048 处）。同样的继续使用内置模板进行查看获得基本信息

从上面我们可以看到，从这个位置开始 Reserved 了6190(D)个扇区，因此可以知道第一个FAT在LBA：2048+6190=8238(D)。查看 LBA 8238 (D)这个位置 ，看到的就是 FAT 表。下图框出来的就是每一个文件项。第一个簇标记为 0xFFFFFFF8，第二个簇为0xFFFFFFFFF（0号FAT项为肮脏标志；1号FAT项是一个结束标志，通常簇号是从2开始就是这个原因）。其余的0xFFFFFF0F表示这个簇对应的是目录或者文件的结尾。之前我们的讨论都是以扇区为单位的，等到了研究文件时，通常需要以簇为单位，二者之间的换算关系是 Sector Per cluster 参数给出的。例如，这个值为4，就表示1个Cluster 由4个Sector 组成。

3.3 上面的概念不太容易理解，直接跳到数据区来进行查看。数据区的开始在：2048+6190+1001+1001=10240 扇区的位置：

可以隐约看到右侧ASCII字符就是我们FAT32分区上的根目录（下图是切换到D: 的示意图，注意物理硬盘和分区上的扇区不同，本文都是以物理硬盘的扇区号为准）：

我们知道 EFI 目录下有 BOOT 目录，其中有 BOOTX64.EFI 这个文件。我们下面的目标就是获得这个文件的内容。首先，移动光标到前面的 EFI 目录字样处

从菜单上选择模板 ：

查看目录信息 如下:

目录EFI 的数据在数据区起始扇区号+(簇号-2)*（扇区数/簇）

6号簇的绝对LBA就是 10240+(6-2)*4==10256扇区

上面可以看到 BOOT 这个目录，再使用模板解析BOOT目录的数据

可以看到 BOOT 目录的数据位于9号簇，对应的绝对扇区是10240+(9-2)*4==10268

再查看这个扇区

这里就能看到 BOOTX64.EFI 文件了，再用模板解析 BOOTX64.EFI 的数据：

最终查看10240+(10-2)*4==10272扇区，就是 BOOTX64.EFI 的内容

从 10272到10275 是10号簇，接下来需要到 FAT中查看，可以看到下面的位置指向了11号簇，就是说BOOTX64.EFI 文件并未完结，接下来的内容可以在11号簇所在扇区

参考：

1. http://www.jinbuguo.com/storage/gpt.html  GPT 分区详解
2. https://www.dgxue.com/huifu/luoji/windwos-huifu/fat32/
3. https://blog.csdn.net/li_wen01/article/details/79929730

默认情况下, Console 程序的图标是下面这种。这次介绍一下如何用其他的图标来替换之。

1.创建一个 Win32 Console 程序。在 Resource Files上点右键：

2.在弹出的菜单上选择 AddàResource…, 这样就为项目创建了一个 Resource文件

3.双击生成的 rc文件

4.跳转之后在文件上使用右键,选择 “Add Resources….”

5.选择 Icon，然后 Import

6.弹出的对话框上选择你需要的 icon文件

7.导入之后，在导入的图标上单击右键，选择 Properties….

8.改ID为IDC_MAINFRAME

生成的EXE 如下：

参考：

1. https://blog.csdn.net/weixin_30603633/article/details/96342177

UEFI Spec 介绍了一个 EFI_ACPI_TABLE_PROTOCOL，定义如下：

从介绍可以看出，我们能够使用这个 PROTOCOL 添加（Install）或者删除（Uninstall）一个 ACPI Table。

首先准备一个 ACPI Table， 这里顶一个一个叫做 LBZT 的 Table。

DefinitionBlock ("LABZT.AML", "LBZT", 2, "", "", 0x0)
{
 Name(BUF1, Buffer(){0x00,0x01,0x02,0x03,0x04,0x05})
 Name(BUF2, "www.lab-z.com")
}

DefinitionBlock语法定义如下【参考1】：

AMLFileName 是给编译器看的，用于指定输出的 AML 文件名；

TableSignature 是 ACPI Table 的名字（4字节）

ComplianceRevision, 2以及大于2是指定64位；1或者0指定32位（这里我不清楚具体差别，做了一个实验，比如定义：Name(BUF3, 0x1122334455)，当ComplianceRevision为0时，编译之后结果发生截断，实际定义是Name(BUF3, 0x22334455)；但是当ComplianceRevision为2时，编译结果和代码相同）。如果在处理较大的数值时，需要特别注意这里。

OEMID OEM自定义 ID

TableID  OEM自定义Table 名称（8Bytes）

OEMRevision OEM自定义数值

接下来我们首先自定义一个 ACPI Table 如下：

DefinitionBlock ("LABZ64.AML", "LABZ", 2, "", "", 0x0)
{
 Name(BUF1, Buffer(){0x00,0x01,0x02,0x03,0x04,0x05})
 Name(BUF2, "www.lab-z.com")
 Name(BUF3, 0x1122334455)
}

编译之：

得到的是一个二进制文件LABZ64.aml

使用工具转化为C的定义，我们就可以在代码中直接使用了。测试代码如下：

#include  <Uefi.h>
#include  <Library/UefiLib.h>
#include  <Library/ShellCEntryLib.h>
#include  <Library/UefiBootServicesTableLib.h>
#include  <Protocol/AcpiTable.h>

extern EFI_BOOT_SERVICES         *gBS;

EFI_GUID gEfiAcpiTableProtocolGuid ={ 
                0xFFE06BDD, 0x6107, 0x46A6, 
                { 0x7B, 0xB2, 0x5A, 0x9C, 0x7E, 0xC5, 0x27, 0x5C }};
                
/* Contents of file LABZ64.aml */
const long int LABZ64_aml_size = 85;
const unsigned char LABZ64_aml[85] = {
    0x4C, 0x41, 0x42, 0x5A, 0x55, 0x00, 0x00, 0x00, 0x02, 0x7A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x49, 0x4E, 0x54, 0x4C,
    0x18, 0x10, 0x19, 0x20, 0x08, 0x42, 0x55, 0x46, 0x31, 0x11, 0x09, 0x0A, 0x06, 0x00, 0x01, 0x02,
    0x03, 0x04, 0x05, 0x08, 0x42, 0x55, 0x46, 0x32, 0x0D, 0x77, 0x77, 0x77, 0x2E, 0x6C, 0x61, 0x62,
    0x2D, 0x7A, 0x2E, 0x63, 0x6F, 0x6D, 0x00, 0x08, 0x42, 0x55, 0x46, 0x33, 0x0E, 0x55, 0x44, 0x33,
    0x22, 0x11, 0x00, 0x00, 0x00
};
                
int
EFIAPI
main (
  IN int Argc,
  IN char **Argv
  )
{
        EFI_STATUS              Status;
        EFI_ACPI_TABLE_PROTOCOL *AcpiTableProtocol;
        UINTN                   TableKey;
        
        Status = gBS->LocateProtocol(
                           &gEfiAcpiTableProtocolGuid, 
                           NULL,
                           (VOID **)&AcpiTableProtocol);
        if (EFI_ERROR(Status)) {
            Print(L"Cannot find ACPI_TABLE_PROTOCOL \r\n");
            return Status;
        }
        
        AcpiTableProtocol->InstallAcpiTable(
                                AcpiTableProtocol,
                                (VOID *)LABZ64_aml,
                                LABZ64_aml_size,
                                &TableKey);
        gBS->CloseProtocol ( 
                        AcpiTableProtocol,
                        &gEfiAcpiTableProtocolGuid,
                        gImageHandle,
                        NULL );
        return EFI_SUCCESS;
}

实体机上进行测试，运行 att.efi 之后可以使用 Acpiview 命令查看到如下：

--------------- LABZ Table --------------- 

Address  : 0x44B1D000
Length   : 85
  
00000000 : 4C 41 42 5A 55 00 00 00 - 02 7A 00 00 00 00 00 00   LABZU....z......
00000010 : 00 00 00 00 00 00 00 00 - 00 00 00 00 49 4E 54 4C   ............INTL
00000020 : 18 10 19 20 08 42 55 46 - 31 11 09 0A 06 00 01 02   ... .BUF1.......
00000030 : 03 04 05 08 42 55 46 32 - 0D 77 77 77 2E 6C 61 62   ....BUF2.www.lab
00000040 : 2D 7A 2E 63 6F 6D 00 08 - 42 55 46 33 0E 55 44 33   -z.com..BUF3.UD3
00000050 : 22 11 00 00 00                                      "....

Table Checksum : OK

ACPI Table Header                    :
  Signature                          : LABZ
  Length                             : 85
  Revision                           : 2
  Checksum                           : 0x7A
  Oem ID                             :       
  Oem Table ID                       :         
  Oem Revision                       : 0x0
  Creator ID                         : INTL
  Creator Revision                   : 0x20191018

Table Statistics:
	0 Error(s)
	0 Warning(s)

再进一步，启动到 Windows后用 RW 进行查看也可以看到 LABZ Table

完整代码下载：

参考：

1. https://acpica.org/sites/acpica/files/asl_tutorial_v20190625.pdf