[[418421]]

前言

自從Intel內(nèi)核開發(fā)人員Jarkko Sakkinen于2017年9月2日在intel-sgx-kernel-dev@lists.01.org郵件列表上發(fā)出v1版的SGX in-tree驅(qū)動(dòng)以來，時(shí)間已經(jīng)過去了3年多了。這期間這個(gè)驅(qū)動(dòng)前前后后共修改了41個(gè)版本，終于在2020年11月13日，v41版本的補(bǔ)丁合入了5.11-rc1內(nèi)核。Jarkko松了一口氣，任務(wù)完成啦！不過，為什么合并一個(gè)普通的驅(qū)動(dòng)模塊會(huì)這么難？

事實(shí)上，由于SGX所代表的新的機(jī)密計(jì)算領(lǐng)域的特殊性，圍繞著它的爭(zhēng)議和討論就從未停止過。甚至在最終的v41補(bǔ)丁中，也沒能看到大佬們整齊劃一的LGTM（社區(qū)黑話，Looks Good To Me的縮寫，表示自己認(rèn)可這個(gè)補(bǔ)?。?，它依舊存在一些問題，同時(shí)還有人在不斷提出修改建議。這不禁讓人聯(lián)想到另一個(gè)x86處理器特性FSGSBASE合入upstream時(shí)的命運(yùn)多舛：后者的合入前后花了5年時(shí)間，甚至最后都不是Intel的人合入的（當(dāng)然也不是AMD的人合入的，大家可以猜猜是誰）。

今天的故事主角，是一個(gè)被稱為Flexible Launch Control（簡(jiǎn)稱FLC）的SGX平臺(tái)特性。對(duì)這個(gè)特性的爭(zhēng)議，最終導(dǎo)致SGX in-tree驅(qū)動(dòng)無法支持不具備FLC特性或關(guān)閉了FLC特性的所有SGX系統(tǒng)。大白話是啥意思呢？意思就是一批較早的支持Intel SGX的機(jī)器用Linux內(nèi)核自帶的官方驅(qū)動(dòng)是無法加載和使用SGX的......納尼！這個(gè)驅(qū)動(dòng)竟然不向下兼容！哎，現(xiàn)在讓我們先對(duì)FLC技術(shù)背景進(jìn)行一個(gè)簡(jiǎn)單的介紹，然后再對(duì)其被社區(qū)拋棄的故事簡(jiǎn)單做個(gè)復(fù)盤，最后再給出我們的思考，以及我們的解決方案。

FLC的技術(shù)背景

友情提醒：想聽故事不想了解技術(shù)細(xì)節(jié)的同學(xué)請(qǐng)直接跳到下一節(jié)。

在執(zhí)行SGX EINIT指令初始化enclave的時(shí)候，被初始化的enclave必須通過Launch Control機(jī)制的檢查，因此Launch Control是一種用于控制enclave能否啟動(dòng)的安全檢查機(jī)制。

被初始化的enclave分為兩類：Launch Enclave和普通enclave。Launch Enclave與普通的enclave的不同之處在于其SECS.ATTRIBUTES.EINITTOKEN_KEY == 1，即具有通過執(zhí)行SGX EGETKEY指令派生出einit token key的權(quán)限。Einit token本質(zhì)上是一個(gè)帶有CMAC簽名的token，其中的CMAC是Launch Enclave用einit token key生成的，意在對(duì)einit token本身提供完整性保護(hù)；在執(zhí)行EINIT初始化普通enclave的時(shí)候，從Launch Enclave處返回的einit token需要作為輸入?yún)?shù)的一部分，然后EINIT指令的微碼會(huì)將einit token作為派生出einit token key的輸入因子，最后用派生出的einit token key來驗(yàn)證輸入的einit token中的CMAC，以確保einit token從生成到傳給EINIT的過程中沒有被篡改。

上面的流程中提到的einit token完整性檢查適用于所有的普通enclave，而對(duì)于Launch Enclave，再執(zhí)行EINIT初始化時(shí)有特殊處理。下面是在執(zhí)行EINIT時(shí)完整的Launch Control流程：

（上面的流程圖是對(duì)Intel SDM手冊(cè)中關(guān)于EINIT指令在微架構(gòu)層的執(zhí)行流程進(jìn)行的總結(jié)；其中Launch Enclave驗(yàn)證兩次IA32_SGXLEPUBKEYHASH的邏輯應(yīng)該是冗余的，但我們還是按照原始流程的邏輯把它給完整地畫出來了）

可以簡(jiǎn)單地將上述流程總結(jié)為以下兩點(diǎn)規(guī)則：

1.只要在初始化enclave時(shí)能提供合法的einit token, 就能通過Launch Control的檢查。

2. 如果在初始化enclave時(shí)沒有提供合法的einit token, 則enclave的MRSIGNER必須與IA32_SGXLEPUBKEYHASH的值一致。

此外，還可以從第二點(diǎn)規(guī)則推導(dǎo)出適用于Launch Enclave的特殊規(guī)則：

1. Launch Enclave必須能夠通過IA32_SGXLEPUBKEYHASH的校驗(yàn)才能被初始化。

2. 通過EINIT初始化Launch Enclave的時(shí)候，可以不提供einit token。

在處理器復(fù)位時(shí)，IA32_SGXLEPUBKEYHASH的默認(rèn)值是Intel的MRSIGNER。如果處理器不支持FLC，任何普通的enclave在初始化時(shí)，必須持有合法的einit token，而負(fù)責(zé)頒發(fā)einit token的Launch Enclave則可以制定自己的策略來決定是否給一個(gè)普通enclave頒發(fā)einit token。 具體到Intel在不支持FLC的SGX1上實(shí)施的策略則是：用戶運(yùn)行的enclave必須是由Intel授權(quán)的密鑰簽過的，這樣才能得到Intel開發(fā)的Launch Enclave的授權(quán)，并獲得einit token，否則用戶無法運(yùn)行自己開發(fā)的普通enclave（嚴(yán)格講是無法運(yùn)行產(chǎn)品級(jí)的普通enclave，debug級(jí)的普通enclave還是可以運(yùn)行的）。

這就是利用Launch Control達(dá)成的控制效果：誰掌握Launch Enclave，誰控制普通enclave的運(yùn)行授權(quán)。

相反，如果處理器支持FLC且BIOS沒有鎖死IA32_SGXLEPUBKEYHASH，IA32_SGXLEPUBKEYHASH MSRs對(duì)系統(tǒng)軟件不僅可見而且可寫，配合SGX in-tree驅(qū)動(dòng)就可以實(shí)現(xiàn)如下功能：每當(dāng)加載任意enclave時(shí)，都無條件將其MRSIGNER寫入到IA32_SGXLEPUBKEYHASH中，從而繞過Launch Control機(jī)制，也就是說所有普通enclave都能像Launch Enclave那樣無需提供合法的einit token。FLC中的F，指的就是IA32_SGXLEPUBKEYHASH寄存器在某些情況下是可寫的。 至于要不要利用它繞過Launch Control機(jī)制，則是具體的實(shí)現(xiàn)策略問題，而SGX in-tree驅(qū)動(dòng)就恰恰采取了繞過Launch Control的策略，原因是Linux kernel不希望提供對(duì)配置鎖定的系統(tǒng)提供支持。

至于這種策略是否正確，我們暫先不討論。先休息下，聽聽故事。

故事脈絡(luò)

故事的導(dǎo)火索出自v22 SGX in-tree驅(qū)動(dòng)。這里作者Jarkko定義了處理器是否支持FLC的bit，并對(duì)FLC的作用進(jìn)行了說明。留意作者的最后一段話：

“內(nèi)核不會(huì)對(duì)某種被鎖定的配置提供支持，因?yàn)檫@奪走了內(nèi)核（對(duì)啟動(dòng)enclave）的啟動(dòng)控制權(quán)。”結(jié)合前面關(guān)于FLC的技術(shù)原理講解，這里的鎖定指的就是如果BIOS鎖死了IA32_SGXLEPUBKEYHASH，那么普通enclave的運(yùn)行方式就要被Intel的Launch Enclave的授權(quán)策略所控制。這段描述引起了Reviewer Borislav的警覺，并給出了硬核回復(fù)：如果FEATURE_CONTROL_SGX_LE_WR位決定了IA32_SGXLEPUBKEYHASH是否被鎖死，那么誰控制的FEATURE_CONTROL_SGX_LE_WR位？?jī)?nèi)核能夠控制嗎？我可不想讓該死的BIOS去控制，真出點(diǎn)啥問題我們自己能搞定，用不著看OEM的臉色。

這時(shí)候另一個(gè)作者Sean站出來回答了reviewer的問題：

“是的，就是BIOS控制著FEATURE_CONTROL_SGX_LE_WR位。這個(gè)我們都想好了，F(xiàn)EATURE_CONTROL_SGX_LE_WR位如果為0，那我們就把SGX功能完全禁止掉。這個(gè)想法在第四個(gè)補(bǔ)丁里有具體實(shí)現(xiàn)。”到目前看起來還是正常的社區(qū)review流程，大家也比較平和，直到reviewer看過了第四個(gè)補(bǔ)丁的內(nèi)容。首先我們自己先看下第4個(gè)補(bǔ)丁到底干了什么：

+static void __maybe_unused detect_sgx(struct cpuinfo_x86 *c)+{+  unsigned long long fc;++  rdmsrl(MSR_IA32_FEATURE_CONTROL, fc);...+  if (!(fc & FEATURE_CONTROL_SGX_ENABLE)) {+    pr_err_once("sgx: SGX is not enabled in IA32_FEATURE_CONTROL MSR\n");+    goto err_unsupported;+  }++  if (!cpu_has(c, X86_FEATURE_SGX1)) {+    pr_err_once("sgx: SGX1 instruction set is not supported\n");+    goto err_unsupported;+  }++  if (!(fc & FEATURE_CONTROL_SGX_LE_WR)) {+    pr_info_once("sgx: The launch control MSRs are not writable\n");+    goto err_msrs_rdonly;+  }++  return;++err_unsupported:+  setup_clear_cpu_cap(X86_FEATURE_SGX);+  setup_clear_cpu_cap(X86_FEATURE_SGX1);+  setup_clear_cpu_cap(X86_FEATURE_SGX2);++err_msrs_rdonly:+  setup_clear_cpu_cap(X86_FEATURE_SGX_LC);+} 

一句話描述這段代碼的含義就是：如果FEATURE_CONTROL_SGX_LE_WR位為0（一種情況是BIOS鎖死了IA32_SGXLEPUBKEYHASH，另一種情況是平臺(tái)不支持FLC）的話，意味著MSR_IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}這四個(gè)MSR寄存器對(duì)內(nèi)核來說就是只讀或者不可見的，那么內(nèi)核也就無法控制普通enclave的啟動(dòng)，這是Linux upstream不想看到的情況。對(duì)此，代碼會(huì)簡(jiǎn)單地清楚掉FLC的cpu feature flag，但會(huì)保留其他SGX相關(guān)的cpu feature flag。

Borislav此刻的心情肯定是：() 這和你前面說的不一樣??？這哪里是你所謂的“把SGX功能完全禁止掉”了？？你明明只是清除了FLC cpu feature flag，沒有完全禁止SGX功能?。。?！難道是我的理解有問題嗎 (⊙_⊙)？

作者Sean應(yīng)該是知道自己說錯(cuò)話了，沒有回復(fù)這個(gè)問題；而Borislav此刻只想要一個(gè)東西：MSR_IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}這四個(gè)MSR寄存器對(duì)內(nèi)核來說必須可寫！?。?！

然后作者Sean開始擺事實(shí)講道理：還有好多不支持FLC或者禁用FLC（即BIOS可能非故意地鎖死了IA32_SGXLEPUBKEYHASH）的SGX的平臺(tái)??！

Sean說這句話的時(shí)候是在2019年9月25日，其實(shí)如今來看這句話依舊正確。

Borislav沒有被說服，并且開始談起B(yǎng)IOS是多么的“糟糕”，并多次提到不想提供對(duì)帶有配置鎖定的系統(tǒng)的支持：

Linux以及開源社區(qū)一向反感各種配置鎖定和DRM。筆者印象中早些年Win7剛出來時(shí)強(qiáng)行默認(rèn)開UEFI Secure Boot且BIOS setup中不提供關(guān)閉選項(xiàng)導(dǎo)致無法安裝Linux，這讓開源社區(qū)非常不爽，經(jīng)過Linux Foundation、Intel和微軟的交涉，才最終有了今天的shim bootloader。當(dāng)然，終端用戶不用自己去找微軟簽名bootloader，這是每個(gè)Linux發(fā)行版本自己找微軟簽名的事情了，而且這個(gè)默契也已經(jīng)持續(xù)很久了。

最后作者Sean認(rèn)了，并且說我們本來就是那么想的：

一口老血噴了出來！合著前面的迷之發(fā)言逗我們玩呢？？？顯然作者Sean的邏輯出現(xiàn)了矛盾，他說他的本意其實(shí)是這樣的：

“即使MSR_IA32_SGXLEPUBKEYHASH不可寫，但我們依舊保留其他SGX cpu feature flag，好讓用戶明白到底是我的系統(tǒng)不支持SGX硬件能力，還是因?yàn)槿鄙貴LC功能導(dǎo)致無法運(yùn)行普通的enclave，現(xiàn)在看起來可能是我想多了。” 關(guān)于Sean的這個(gè)結(jié)論，需要這樣理解：雖然在不支持FLC或禁用FLC的平臺(tái)上仍舊能夠運(yùn)，debug級(jí)的普通enclave，但是debug級(jí)的enclave是能夠被sgx-gdb通過特殊的enclave debug指令訪問到enclave中的敏感數(shù)據(jù)的，因此debug級(jí)的enclave不適合于生產(chǎn)環(huán)境；要運(yùn)行不能被debug的產(chǎn)品級(jí)enclave，就必須要遵守Intel的Launch Enclave的授權(quán)策略，但這需要實(shí)施一些對(duì)常人來說不具可實(shí)施性的操作，這與一般用戶想簡(jiǎn)單地就能運(yùn)行普通enclave的需求確實(shí)相悖，因此大多數(shù)情況下，不支持FLC或禁用FLC就等價(jià)于用戶無法運(yùn)行普通enclave，而cpu feature flag可以反映出原因。

最終，從v25開始，如果處理器不支持FLC，所有SGX特性都將無法使用：

+update_sgx:+  if (!cpu_has(c, X86_FEATURE_SGX) || !cpu_has(c, X86_FEATURE_SGX_LC)) {+    clear_sgx_caps();+  } else if (!(msr & FEAT_CTL_SGX_ENABLED) ||+       !(msr & FEAT_CTL_SGX_LC_ENABLED)) {+    if (IS_ENABLED(CONFIG_INTEL_SGX))+      pr_err_once("SGX disabled by BIOS\n");+    clear_sgx_caps();+  } 

不過這個(gè)做法真的對(duì)么？難道不支持FLC或禁用FLC的平臺(tái)就不應(yīng)該得到SGX in-tree驅(qū)動(dòng)的支持嗎？

思考

回答這個(gè)問題前，我們先看下目前Intel對(duì)SGX驅(qū)動(dòng)的支持情況。

除了SGX in-tree驅(qū)動(dòng)，Intel在開源社區(qū)還提供了SGX Legacy驅(qū)動(dòng)。這個(gè)SGX驅(qū)動(dòng)是由于漫長(zhǎng)的review流程而逐漸興盛起來的副產(chǎn)物，目的是在標(biāo)準(zhǔn)內(nèi)核尚不支持SGX的情況下滿足用戶對(duì)SGX平臺(tái)的支撐需求。這個(gè)SGX Legacy驅(qū)動(dòng)支持沒有FLC的平臺(tái)，也是目前支持SGX1平臺(tái)的唯一選擇。可以預(yù)見，在SGX in-tree驅(qū)動(dòng)合入到upstream后，這個(gè)驅(qū)動(dòng)會(huì)逐步退出歷史的舞臺(tái)，那么問題也來了。

首先，即使具備大量EPC內(nèi)存的SGX2機(jī)器已經(jīng)上線了（可以參考阿里云的SGX2邀測(cè)申請(qǐng)鏈接：https://pages.aliyun.com/aliyunpage/activity/alibabacloud-pilot.html ），但是仍有一批存量SGX1平臺(tái)正在服役；此外，采用Intel client platform的CPU很多都支持SGX但不支持FLC，難道這些平臺(tái)的用戶將來就只能用著缺少新特性支持的SGX Legacy驅(qū)動(dòng)嗎？

其次，有些人一定已經(jīng)提前考慮到需要將現(xiàn)有業(yè)務(wù)應(yīng)用拿到基于SGX in-tree驅(qū)動(dòng)的環(huán)境里跑一跑，測(cè)一測(cè)SGX in-tree驅(qū)動(dòng)本身的性能和穩(wěn)定性，因此在缺乏SGX2平臺(tái)的情況下，也需要SGX in-tree驅(qū)動(dòng)能夠支持SGX1平臺(tái)。

最后，不支持FLC和禁用FLC其實(shí)是兩碼事。被社區(qū)真正詬病的是老的SGX1平臺(tái)不支持FLC，進(jìn)而只能被逼實(shí)施不具可實(shí)施性的Launch Enclave運(yùn)行授權(quán)；到了支持FLC平臺(tái)特性的時(shí)代，即便禁用了FLC，但只要鎖定的內(nèi)容是用戶可控的，或者是實(shí)施一種更為寬松的Launch Enclave運(yùn)行授權(quán)，那么這種配置鎖定也是有益的。 就拿云租戶使用裸金屬服務(wù)器的場(chǎng)景為例：即使CSP在BIOS里禁用了FLC，只要CSP在自己定制的Launch Enclave中確保合法的云租戶能正常運(yùn)行該租戶自己簽的enclave就可以了，而這其實(shí)這反倒是為租戶多增加了一重保護(hù)。如果像現(xiàn)在SGX in-tree驅(qū)動(dòng)的這種實(shí)現(xiàn)方式，包括成功入侵到系統(tǒng)的攻擊者都可以任意運(yùn)行自己編寫的惡意Enclave了。

那我們?cè)撛趺崔k呢？

解決方案

我們的觀點(diǎn)還是想大家之所想，急大家之所急。根據(jù)目前的實(shí)際情況，Inclavare Containers開源項(xiàng)目組（ https://github.com/alibaba/inclavare-containers ）編寫了幾個(gè)補(bǔ)丁，目的就是讓不支持FLC或禁用FLC的系統(tǒng)能夠運(yùn)行SGX in-tree驅(qū)動(dòng)。補(bǔ)丁的使用和驗(yàn)證方法詳見：https://github.com/alibaba/inclavare-containers/tree/master/hack/no-sgx-flc

目前我們已經(jīng)在SGX1機(jī)型中成功部署了這種運(yùn)行方式，并實(shí)際應(yīng)用于Inclavare Containers開源項(xiàng)目的CI/CD測(cè)試中。

此外，Inclavare Containers開源項(xiàng)目會(huì)研發(fā)一個(gè)支持用戶自定義策略的Launch Enclave；目的是提升用戶控制的平臺(tái)的安全性，即只允許運(yùn)行用戶預(yù)期的普通enclave，杜絕攻擊者在用戶平臺(tái)上運(yùn)行惡意enclave的情況出現(xiàn)。

最后有幾個(gè)關(guān)鍵概念的關(guān)系要再次澄清，重點(diǎn)提醒下大家：

1. 是否支持FLC和CPU是否支持SGX1/2沒有關(guān)系；SGX1/2是處理器SGX架構(gòu)的指令集特性；FLC是平臺(tái)特性。

2. 之所以強(qiáng)調(diào)SGX1和FLC的關(guān)系，是因?yàn)镕LC是在SGX1和SGX2之間出現(xiàn)的平臺(tái)特性，因此很多SGX1平臺(tái)都缺少FLC特性。

3. 即使是在支持FLC的平臺(tái)，只要在BIOS中禁用了FLC（不管是出于安全原因禁用，還是BIOS不支持FLC，或是被CSP鎖定），都會(huì)像不支持FLC的SGX1平臺(tái)那樣遇到相同的問題。也許到了我們能把這個(gè)問題像上面提到的那樣做到真正的精細(xì)化處理，即能夠明確區(qū)分出“平臺(tái)控制權(quán)民主化”和“非預(yù)期的平臺(tái)配置鎖定”并為前者提供實(shí)在的安全解決方案的時(shí)候，我們會(huì)再給社區(qū)發(fā)送一組patch，以允許SGX in-tree驅(qū)動(dòng)支持那些用戶明確希望禁用FLC的平臺(tái)。