Note: 如何找ACPI/SMBIOS 在UEFI系統

在Legacy BIOS 時代, 基本上SMBIOS/ACPI 的規格書都說明在E/F Segments 用特定的Tag String 可以找到需要的Table, 甚至現在SMBIOS v3.2 的Chapter 5.2 還是建議在Non-UEFI的系統上一樣在F Segments 要能找到, 不過能台灣多數的OEM/ODM 很喜歡表現自己能力尤其某A公司喜歡把從IBV的code改到完全不相容，藉以表現自己與眾不同有技術能力，對我來說是個腦殘的事情，當然它們多數情況下只針對廣大的Windows 系統而且是一般普羅大眾，所以測起來沒問題也就這樣延續這個風格一直下去。例如它們家的SMBIOS EPS現在不會出現在F Segment裡，但是ACPI 的RSDT會，這就是很奇怪的事情。

不是所有作業系統都是UEFI based的就是會造成困擾，不過因為昨天看到放在Github上的DumpACPI 還是有人用，還幫我除錯x64版本，發了Issues，因為當初移到Github時，我只簡單在我的32bits VM上測試過就上傳了，畢竟那時我的主要工作環境都是Linux/Android 開發，直到現在換了新環境，又回到跟Windows/BIOS比較貼近的環境。

但是該Issues還提到他的Win32(x86) 版本一樣找不到ACPI RSDP, 所以個人猜測他的系統可能一樣是只針對UEFI system 的設計, 不完全相容舊有規格。那這問題有辦法解決嗎? 應該是可以透過查找整個記憶體空間得到處理的，但是如何更有效率的查找?根據UEFI 的規格書， 透過AllocatePool() & AllocatePages()所配置的記憶體會在32bits系統上一定落於4GB以下, 而且應該是在 80000000h ~ FFFFFFFFh 區間??(待確認), 所以實際上要找的空間就可以限縮再這2GB內, 按照現在電腦的讀取速度，其實這不須要花太久時間去比對要找的資料，而且這還可以延伸去找 UEFI Runtime service 才是。不過需要花點時間去做點實驗測試。

至於現在主流的64bits系統看到規格書提到可以在4GB之上，需要來確認一下EDK2的UDK實作版本到底是怎樣配置記憶體映射的。

廣告

Note: Access SMBIOS in Kernel of Windows

因為老闆說要給部門做一個簡單的talk, 鑑於目前同事多數是 Junior level, 而公司從事的還是x86為主的硬體生意, 所以決定中秋過完的部門週會上, 簡單介紹一下SMBIOS 的來由與存取方法, 讀資料過程還是有新的收穫, 學到如何kernel 使用wmi

開始做一些研究, 找到一些舊的資料, 基本上SMBIOS 真的開始全面導入是 v2.3.1之後, Win95 就開始使用PNPBIOS 界面提供 SMBIOS的支援, 但是直到 1999年Microsoft 才開始加入 Design for Windows Logo 認證裡面(from PC 99 Design guide), 不過強制需求應該是從Windows XP SP2/Windows 2003 Server SP1 開始引入了mssmbios.sys, 在WinHEC 2005有Release了一個文件 smbios.doc

該文件解釋了mssmbios.sys的一些行為,  基本上是基於WMI機制等於內部做了MOF宣告, 然後會去parsing smbios table資料, 並且存在 registry path 下"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mssmbios\Data"

因為基於WMI, 所以它提供XP SP2與之後版本的user/kernel mode 的 wmi 存取, 為了更簡便使用user mode 還透過增加GetSystemFirmwareTable() API (from Windows 2003 server sp1), 而kernel mode 則從Vista 開始 多了 AuxKlibGetSystemFirmwareTable

kernel wmi 則是透過 IoWmiOpenBlock(), IoWMIQueryAllData(), “SMBIOS_DATA_GUID" 去取得, 這還要看一下 driver load order, 否則貿然在kernel driver使用應該會出問題

Note: SMBIOS/ACPI 觀察

這兩天因為要跟同事介紹 SMBIOS 所以重新把之前寫的code 拿出來測試一下, 公司配給我一台Asus Laptop 發現一件有趣的事情, ACPI 仍然可以在E/F Segment 內被找到 RSDP, 但是 SMBIOS 的　ESP 卻已經移掉, 這件事情讓我感覺蠻奇怪的

所以就查了一下SMBIOS v3.0規格內寫的是 Non-UEFI system 還是需要 在F Segment 內提供ESP呀, ACPI 猜想也是, 搞不太懂 ASUS 為啥一個拔掉一個還留著, 理論上為了最大相容性, 應該是都留著會比較好, 雖然他是UEFI only 的設計了, 但是我看過 WINCE一個詭異的設計是透過UEFI bootloader 去支援APIC mode 就是只在開機階段透過UEFI bootloader 去parsing ACPI table 然後自己切 Interrupt mode 到APIC mode其他部份保持WINCE本來的樣子

Note: Device Instance Order of PCI/PCI-e

遇到需要客制化NIC 是指定 NIC1,  NIC2的客制需求, 但是有些人的想法竟然是進OS再去改設定改變 Device Order, 這真是讓我覺的不能接受, 不能接受的原因不是因為這樣掉到我頭上, 而是這樣會變成生產安裝需要多一道程序,這代表工時與成本增加, 最重要是客戶是否使用會有困擾, 不太可能PC出貨後, 都不重新安裝OS, 那是否客戶也需要記得如果改變特定的Device Instance Order, 按客戶提案需求也不見得吻合

直覺這樣的需求應該是透過ACPI 來設定, 但是許久沒做BIOS工作後, 看了ACPI Spec. 沒看到可以做的方法, 跟老闆討論說Dell 有這樣改, 查了一下果然Dell 有於2010年提案並於同年12月正式成為 PCI Firmware Specification Revision 3.1 (need member) 的一部分,

看了一下 Linux 關於這個功能的實現, 發現早於2008年SMBIOS 2.6.0 就有Type 41 可以做這個功能

如果沒有這兩個機制, 變成就HW設計時必須注意PCI的BUS順序了

Note: Intel ME disable

目前Intel 平台已經全部導入ME(Management Engine)的設計, 也因為配合現在安全需求會有一個TEE的執行環境, 所以Intel 開始推他的SGX(Software Guard Extensions), 而要執行TEE Application跟OS溝通勢必要有一個RPCs溝通的管道, 系統內通常會載入一個專門的Driver負責跟TEE環境溝通, 而配合一般使用者環境會有它搭配的SDK開發, 而其中有一個環節是Intel DAL(dynamic application Loader)這是設計來讓載入有效簽名的Java Applet 到 Intel ME (from ME 7.1 support), 因此它需要跟 ME/TEE等東西打交道

本來上面講的東西Intel 不太對外公佈細節, 畢竟越少談, 越不容易被人找到漏洞, 不過這幾年也陸續傳出被發現各種資安漏洞如Intel-SA-0073/Intel-SA-0075/Intel-SA-0086 , 又被攻擊說因為ME不公開也是有資安疑慮, 變成某些國防使用會有不可預知的風險等等, 不知道是不是如此, Intel 把DAL Host Interface 就公開在Github上了, 算是踏出一小步

那這個有啥用呢, 用處就是搭配 me-disable 這個Linux 上的code 可以參考做出其他環境的版本, 而且因為有Intel DAL Host Interface的資料,  可以更清楚他的Command定義 可以從原碼中找到透過 “MKHI_GEN_GROUP_ID", “GEN_SET_MFG_MRST_AND_HALT_CMD" 這個命令去Reset & Halt ME的

這個功能是實際上對一般人無用但是對很多從事x86產業的OEM/ODM廠商來說, 就算是基本工具了, 因為ME啟動的情況下, 透過他的PCH會把某些東西鎖住, 無法實際操作, 這個設計也是因為安全需求, 但是Intel當初又不願意公開細節, 畢竟總是有更新系統Firmware的時刻, 多數廠商目前都採用各種奇怪的手法或是乾脆不更新某塊區塊了.

Intel 這個版本已經把Windows 下 User Application 如何找到Driver interface跟下指令的部份完全公開

Update: Sept. 08 2018

A Windows ME Disable by Myself

ref.
Secret of Intel Management Engine by Igor Skochinsky

Wikipedia – Intel Active Management Technology

 

Note:Auto-Recovery for Windows System Boot crash

現在這個年代只討論 UEFI, Legacy BIOS 也可以做但是透過Customization Bootloader會更好一點,  簡單想法是透過NVRAM 存一個Boot Count, 個人偏好 RTC的CMOS空間, 當然要寫再Flash 也不是不行這個東西不是為了頻繁開關機的環境下設計的, 所以不會有頻繁擦寫Flash 的問題 後來想到本來UEFI 就有一個Monotonic Counter 設計來給Secure Boot用的, 等於是做一個簡化類似的東西, 但是配合自己系統改變

然後在系統內裝一個Agent, 最好是一個Automation啟動的Service 讓它負責抹除Boot Count, 個人會設計啟動一個Thread在系統啟動差不多3~5秒後才抹除確保系統不是開機到一半當掉 XD

然後透過BIOS 在BDS前去讀取該變數, 譬如累加到3次, 代表已經開機三次不成功, 這時BDS跳到選擇做Recovery的Partition 啟動, 讓它自動進入Recovery 步驟
or 是透過PXE去啟動系統 直接網路Recovery

類似下面這個

Make your own automatic Windows restore partition
IT Geek: How to Network Boot (PXE) the WinPE Recovery Disk with PXElinux v5 & Wimboot

Note: UEFI attack

研究SW SMI 怎樣做比較好　順便看一下現在一些攻擊手段

• Exploiting AMI Aptio firmware on example of Intel NUC
• Arbitrary SMM code execution exploit for AMI Aptio V based firmware
• CHIPSEC: Platform Security Assessment Framework
• UEFI firmware image viewer and editor 好像舊的才能 modify BIOS, 0.2.x vs 0.3.x