【UEFI】—BIOS中UserPassword的重複校驗總結

• 2019 年 10 月 3 日
• 筆記

　　UEFI作為目前較為流行的一套X86架構初始化的標準框架，已受到業界內的廣泛認可。而其中很多編程所採用的思想確實值得學習。今天總結下UEFI的框架下修改代碼的一點小經驗，僅供菜鳥參考。
先列乾貨，具體的小結後續補充：
　　1. 明確你要的某個功能的實現邏輯，都需要在哪個位置添加代碼。
     （很重要，這決定着你的方案是否可行重要前提，一旦此步驟錯誤，後續的代碼實現也會由於代碼框架的不合適而完全崩塌）
　　2. 代碼需要良好的封裝性，高內聚性，低耦合性。秉着此原則。筆者建議寫代碼時從最終功能開始寫起，用到什麼變量，GUID,或者頭文件定義，就去添加什麼。這樣能保證你添加的都是你需要的，且思路不會亂。
　　3. UEFI框架下經常會涉及到一些GUID，包括跨Pkg的Lib調用，在此也會小結一下。

　　OK, 乾貨就這幾點，用筆者目前遇到的一個小問題–“BIOS Setup下UserPassWord重複設置密碼可以成功的功能”為例進行說明。

1. 流程梳理

　　　　a. 密碼的存儲和校驗一般多採用HASH值校驗的方式，優點【安全，簡單】
　　　　b. BIOS下的密碼流程：

•  用戶輸入密碼後，BIOS能拿到用戶輸入的字符串，首先需要對密碼的複雜度進行驗證。看複雜度是否符合。

•  其次是將當前輸入密碼與之前的存儲過的密碼進行對比，若有重複則放棄。密碼的存儲的和對比一般是使用該字符串的Hash值，非明文存儲簡單安全。若符合要求，則進一步將密碼進行存儲         

  (CRB代碼中提供了對AdminPassword的過往三次密碼重複校驗，其實現的流程比較複雜一些，但是其原理應該是通過對過去三次設置的密碼進行Hash值存儲校驗，且需要按照順序存儲，畢竟只能存儲過去的三次。這個地方應該使用了類似隊列的方案，先進先出)

• 最後就是在每次存儲密碼的時候，要把最終保存的Admin的密碼的Hash存儲到隊列裏面。原始最早存儲的那個密碼進行刪除，將其後的兩個密碼Hash按順序提升一位，然後將最新保存的密碼放置在Hash隊列中的第三位即可

2. 方案設計

　　2.1  在最終保存密碼的時候，設置一個Variable存儲當前UserPassword的Hash

　　 2.2  在輸入UserPassword後，讀取上一次設置的密碼Hash，與當前輸入的密碼Hash進行對比。判斷是否可以被寫入

3. 編碼實現

　　3.1 設置保存UserPassword的Hash值，我們僅需要拿到當前輸入密碼的字符串，然後得到Sha256編值，再通過gRT->SetVariable的服務存儲保存即可。初步編寫的函數如下：    

　　3.2 用戶輸入密碼後，在做完複雜度校驗後，添加UserPassWord的重複驗證，代碼如下：   

 　　3.3 最終將SetVariable的函數添加至BIOS保存退出時，設置密碼的位置即可。

小結梳理：

　　最終將SetVariable的函數添加至BIOS保存退出時，設置密碼的位置即可。
　　此Bug梳理之後其實挺簡單的，回想自己的解問題思路，應該注意的幾個點主要如下：
　　　　a. 理清處原有的AdminPassword的檢驗機制，學習其的一些處理方法
　　　　b. 編碼時，對GUID和一些Lib庫的調用有點不夠清晰，也是通過本次整理重新梳理了下GUID的用法和Lib庫的調用。（後續着重總結）
　　　　c. 有一些過程功能函數，僅限在某個.c文件內部使用，這種情況下，果斷考慮重寫一套函數供自己使用。不要為了外部調用原有函數而花費過多無用的時間。
　　　　d. 最最重要的一點，寫代碼時一定要明確需求，自己要寫什麼，在哪個地方寫？然後從最根本的需求處入手，需要什麼就添加什麼，這樣才能穩住陣腳，從容應對。

　　針對此次解決的一些小Bug，做以上總結，給同為程序猿的我們，留下些許的足跡。

　　一個普通程序員的成長路程，歡迎關注我的公眾號，茫茫人海，能與你相遇既是有緣。哈哈