如何取得最新的EDK II程式碼?

From: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UDK2010

UEFI開發工具2010詳細說明釋放#1 (UDK2010.SR1.UP1.P1) (所有軟體包的完整的zip檔與說明文件，它們被包裝解開到MyWorkSpace目錄)

目前最新的程式碼在下面鏈結中，請使用SVN軟體去下載：

https://svn.code.sf.net/p/edk2/code/branches/UDK2010.SR1: r14385

https://svn.code.sf.net/p/edk2-fatdriver2/code/trunk/FatPkg/: r73

下載 TortoiseSVN

輸入網址到SVN工具，你就可以瀏覽整個目錄。

如何編譯此程式碼，請參考: 安裝與編譯UEFI EDK2

支援的作業系統與編譯環境

• Using newer versions of Linux
• Windows systems
• Xcode Mac OS X
• Unix-like systems (For older Linux distributions, or using Cygwin or Mac OS X)

安全啟動概述(Secure Boot Overview) --- UEFI

From: http://technet.microsoft.com/en-us/library/hh824987.aspx

適用作業系統: Windows 8, Windows 8.1, Windows Server 2012, Windows Server 2012 R2

安全開機(Secure Boot)是一個在個人電腦上，以UEFI為基礎的功能；它幫助增加個人電腦的安全，以防止未被授權軟體在開機啟動程序期間被執行在個人電腦上。它檢查每個軟體程式區段是否擁有一個有效的簽章，包括作業系統被載入時也須被檢查。

當安全開機(Secure Boot)在個人電腦上被啟動，它會檢查每個軟體程式區段，在韌體中包含Option ROMs、UEFI驅動程式、UEFI應用程式、還有作業系統，違反已知良好簽章的資料庫維持著。如果每個軟體程式區段都是有效，此韌體執行這軟體與這作業系統。

常被問的問題：
• 我是否需要安全開機的功能，才能夠升級到最新版本的Windows系統？

◦ 對於x86與x64方面的PC：安全開機(Secure Boot)不是必備的。它是一個可選擇的功能，它能夠經由OEM製造商去加入它，為了增強PC的安全性，還有你將可以發現它在所有的Windows 8.1 搶先版或者是Windows®8的徽標認證的個人電腦。

◦  對於ARM方面的PC：對於Windows RT 8.1搶先版與Windows RT 8.1零售電腦，這安全開機(Secure Boot)是必備的，不能夠被關閉。

•  如果我的新硬體裝置不被系統信任時，會發生什麼事？

你的個人電腦(PC)可能不能夠被開機，這裡有兩種問題會發生：

◦  此韌體不信任此作業系統、Option ROM，驅動程式、或是應用程式，因為它不是被信任經由安全啟動資料庫(Secure Boot database)。

◦  一些硬體要求核心模式驅動程式，它必須擁有簽章。注意：許多舊識的32位元(x86)驅動程式沒有簽章，因為核心模式驅動程式簽章是為了安全啟動最近才被規定的。關於更多資訊，請參閱"Secure boot feature signing requirements for kernel-mode drivers"。

關於更多資訊，請參閱"Windows 8 with Secure Boot enabled may no longer boot after installing new hardware"。

•  如何我才能夠加入硬體或執行軟體或作業系統，當它們不被系統信任時?

◦  你能夠檢查Microsoft或是PC製造商是否有更新軟體。

◦  你能夠聯絡你的製造商並要求新增的硬體或軟體到安全開機資料庫(Secure Boot database)。

◦  對於x86還是x64的PC，你可能必須關閉安全開機(Secure Boot)的功能。請聯絡你的製造商取得相關操作說明。
◦  在某些情況下，你可能需要去改變在系統任體中的相關設定，例如：開啟Compatibility Support Module (CSM)去支援原始BIOS系統。去使用CSM同時，你可能也需要去重新格式化你的硬碟，使用Master Boot Record (MBR)的格式。然後重新安裝Windows。關於更多資訊，請參閱Windows安裝設定：安裝使用MBR或GPT磁區樣式( Installing using the MBR or GPT partition style)。

•  如何我才能夠建立或編輯安全啟動資料庫(Secure Boot databases)?

消費者應該聯絡他們的製造商取得對於他們的個人電腦的操作說明。

製造的需求
安全開機(Secure Boot)要求一部電腦，它符合UEFI規格2.3.1版，Errata C或更高。
全開機(Secure Boot)被支援對於UEFI類別2與類別3的電腦。關於UEFI類別2的電腦，當它的安全開機(Secure Boot)被致能，這compatibility support module (CSM)必須被除能，所以電腦只能夠啟動經授權的UEFI基礎的作業系統。

安全開機(Secure Boot)不要求一個信任的平台模組(Trusted Platform Module (TPM))
啟動核心除錯模式，致能測試簽章(TESTSIGNING)，或去除能NX，你必須關閉安全開機(Secure Boot)。關於更多資訊，請參閱"Windows 8 Secure Boot Key Creation and Management Guidance"。

它怎麼運作？
當安全開機(Secure Boot)在個人電腦上被啟動，它會檢查每個軟體程式區段，在韌體中也包含UEFI驅動程式(被稱為Option ROMs)還有作業系統，違反已知良好簽章的資料庫維持。如果每個軟體程式區段都是有效，此韌體執行這軟體與這作業系統。

簽章資料庫與密鑰(Signature Databases and Keys)
之前個人電腦才開始部署，OEM儲存安全啟動(Secure Boot)資料庫到PC上。此包含簽章的資料庫(signature database (db))，撤銷簽章的資料庫(revoked signature database (dbx))，還有密鑰登入密鑰資料庫( Key Enrollment Key database (KEK))到PC上。在製造時期，這些資料庫被儲存到韌體非揮發的記憶體中。

簽章的資料庫(signature database (db))與撤銷簽章的資料庫(revoked signature database (dbx))列出這些簽章者或影像檔UEFI應用程式、作業系統載入器(例如：微軟作業系統載入器、或開機管理程式)，或是UEFI驅動程式，它們能夠在個人電腦上被載入，且撤銷影像檔相關條款，它們不再被信任，還有可能不會被載入。

密鑰登入密鑰資料庫( Key Enrollment Key database (KEK))是一個分割簽章密鑰的資料庫，它能夠被應用在更新數位簽章資料庫與撤銷簽章的資料庫。微軟要求一個具體指明的密鑰被加入在KEK資料庫中，以便在未來微軟可以加入新的作業系統到數位簽章資料庫或添加到已知的惡意影像檔到撤銷簽章的資料庫中。

這些資料庫已被增添之後，與最後的韌體查核與測試之後，OEM鎖住韌體的編輯。除了更新，它必須擁有簽章跟正確的密鑰，經由實際存在的使用者，他使用韌體選單，然後產生一個平台密鑰(platform key (PK))。這PK可以被用來簽署更新KEK或關閉安全啟動(Secure Boot)。

在建立這些資料庫，OEMs應該聯絡他們的製造商關於工具與援助。關於更多資訊，請參閱"Windows 8 Secure Boot Key Creation and Management Guidance"。

啟動順序(Boot Sequence)

1. 在PC的電源被開啟後，簽章資料庫核對平台的密鑰(platform key: PK)。
2. 如果韌體不備系統信任，UEFI韌體必須開始OEM的特定復原原來已被信任的韌體。
3. 如果這裡有一個跟Windows開機管理程式(Windows Boot Manager)的問題，此認體將試圖去啟動一個Windows開機管理程式的備份。如果還是失敗，認體必須開始OEM特定的矯正。
4. 在Windows開機管理程式已經開始運作，如果這裡有一個跟驅動程式或NTOS核心的問題，Windows恢復環境程式(Windows Recovery Environment (Windows RE))會被載入，以至於這些驅動程式或核心影像能夠被復原。
5. Windows載入非惡意程式軟體。
6. Windows載入其他核心程式與初始化使用者模式程序。

關於更多資訊，請參閱白皮書: Secured Boot and Measured Boot: Hardening Early Boot Components Against Malware。

也可以閱讀其他的資源：
UEFI Firmware
Secured Boot and Measured Boot: Hardening Early Boot Components Against Malware

RECEIVE DIAGNOSTIC RESULTS (1Ch)

RECEIVE DIAGNOSTIC RESULTS (1Ch) command

Bit Byte	7	6	5	4	3	2	1	0
0	OPERATION CODE (1Ch)
1	Reserved							PCV
2	PAGE CODE
3	ALLOCATION LENGTH (15:8)
4	ALLOCATION LENGTH (7:0)
5	CONTROL

A page code valid (PCV) bit set to one specifies that the device server return the diagnostic page specified in the PAGE CODE field.

SEND DIAGNOSTIC (1Dh)

SEND DIAGNOSTIC (1Dh)

Bit Byte	7	6	5	4	3		2		1	0
0	OPERATION CODE (1Dh)
1	SELF-TEST CODE			PF	Reserved	SELF TEST		DEVOFFL		UNIT OFFL
2	Reserved
3	PARAMETER LIST LENGTH (15:8)
4	PARAMETER LIST LENGTH (7:0)
5	CONTROL

PACKET - A0h, Data

PACKET - A0h, Data

Inputs:

Register	7	6	5	4	3	2		1	0
Features	na	na	na	na	na	na		OVL	DMA
Sector Count	Tag					na
LBA Low	na
Byte Count low (LBA Mid)	Byte Count limit (7:0)
Byte Count high (LBA High)	Byte Count limit (15:8)
Device	obs	na	obs	DEV	na	na	na			na
Command	A0h

Features register -

• OVL - This bit is set to one to inform the device that the PACKET command is to be overlapped.
• DMA - This bit is set to one to inform the device that the data transfer (not the command packet transfer) associated with this command is via Multiword DMA or Ultra DMA mode.

Sector Count register -

• Tag - If the device supports command queuing, this field contains the command Tag for the command being delivered. A Tag may have any value between 0 and 31 regardless of the queue depth supported. If queuing is not supported, this field is not applicable.

Byte Count low and Byte Count high registers -

• These registers are written by the host with the maximum byte count that is to be transferred in any single DRQ assertion for PIO transfers. The byte count does not apply to the command packet transfer. If the PACKET command does not transfer data, the byte count is ignored.

Normal Outputs:

Register

7

6

5

4

3

2

1

0

Error

na

Interrupt reason (Sector Count)

na

REL

I/O

C/D

LBA Low

na

Byte Count low (LBA Mid)

Byte Count (7:0)

Byte Count high (LBA High)

Byte Count (15:8)

Device

obs

na

obs

DEV

na

na

na

na

Status

BSY

na

DMRD

SERV

DRQ

na

na

CHK

Interrupt reason register -

• Tag - If the device supports command queuing and overlap is enabled, this field contains the command Tag for the command. A Tag value may be any value between 0 and 31 regardless of the queue depth supported. If the device does not support command queuing or overlap is disabled, this field is not applicable.
• REL - Shall be cleared to zero.
• I/O - Shall be cleared to zero indicating transfer to the device.
• C/D - Shall be set to one indicating the transfer of a command packet. 

Device register -

• DEV shall indicate the selected device.

Status register -

• BSY - Shall be cleared to zero.
• DMRD (DMA ready) - Shall be cleared to zero.
• SERV (Service) - Shall be set to one if another command is ready to be serviced. If overlap is not supported, this bit is command specific.
• DRQ - Shall be set to one.
• CHK - Shall be cleared to zero.

UEFI韌體簽章(UEFI Firmware Signing)

From: http://msdn.microsoft.com/en-us/library/windows/desktop/hh973604.aspx

UEFI簽署是在對話板(DASHBOARD)呈現，讓您針對x86或x64平台去簽署UEFI韌體二進位檔，因此它們可以被安裝在Windows PC上。

提交您的韌體
1. 使用您的Microsoft帳戶登入，然後點擊“硬體認證"。

2. 在創建提交對話板(DASHBOARD)，在“硬體認證"頁面，產生呈遞區塊，點擊“創建UEFI呈遞"。

在進行之前，可能會需要您簽署一份法律協議。繼續的檢閱此文件，新增您的簽章，加入日期，然後單擊提交。每個組織只需要簽署此協議一次。

3. 所有UEFI呈遞必須是唯一的，簽章的CAB檔案與包含所有的UEFI檔案。CAB檔案簽章必須符合Authenticode證明檔關於您的公司。根據您的證明提供者，您可能需要使用一個對外的網路窗口或使用signtool。

4. 創建UEFI的網頁上，瀏覽去找出您想要呈遞的CAB檔案，然後單擊”遞交“(submit)。

重要
EFI ByteCode(EBC)檔案必須使用/ ALIGN：32旗標編譯對於處理接替。
提交包應該是一個CAB檔案庫，它不包含資料夾和只有這個*.efi檔案被簽章。

當對話板完成處理您提交的結果，它發送結果檔案經由電子郵件到工作電子郵件網址。

管理您的韌體
1. 對話板與您的Microsoft帳戶登入，然後單擊“硬體認證"。

2. 在"硬件認證“網頁上，在管理提交區塊中，點擊管理呈遞書(Manage submissions)。

3. 在的管理提交頁面，從提交類型(Submission type)列表中，選擇了UEFI表格。

4. 選擇您要管理的呈遞書。

5. 在詳細資訊圖中，您可以看到您的提交狀態，如果它是完成的，請下載此擁有簽章的二進制檔案。

[DASHBOARD]

https://sysdev.microsoft.com/en-us/desktop/Default.aspx?ReturnURL=%2fen-us%2fdesktop%2fmember%2fdefault.aspx