摘要：多變體執(zhí)行（multi-variantexecution，MVX）是目前最流行的主動防御技術之一。理想情況下，當未受到攻擊時，多變體執(zhí)行架構提供正常的程序功能。但不幸的是，當多線程程序在多變體執(zhí)行架構下運行時，由于各個程序變體中共享資源操作的線程執(zhí)行順序不一致，不同變體將會產生狀態(tài)不一致，從而產生攻擊誤報，該問題導致了多線程程序難以以多變體執(zhí)行方式運行?；诙嘧凅w執(zhí)行環(huán)境，提出了一種編譯支持的多線程程序對共享資源操作的同步編譯模型，該模型以共享資源操作為同步點，分析確定多線程程序中對共享資源的操作時機和操作方式，保證各程序變體在運行時多線程對共享資源操作的一致性，從而消除了由此而引起的攻擊誤報。以LLVM12.0編譯框架為基礎，設計實現了基于該同步編譯模型的原型系統，并對該原型系統進行了仿真實驗測試。實驗結果顯示，經過原型系統處理的多線程程序在多變體執(zhí)行架構中的誤報率顯著降低，表明該同步編譯模型作為一種通用性的方法，可有效消除多線程程序在多變體執(zhí)行架構下運行時的攻擊誤報，提高了多變體執(zhí)行的可用性。

關鍵詞：主動防御；編譯器；多變體執(zhí)行

中圖分類號：TP311文獻標志碼：A

文章編號：1001-3695（2023）05-034-1504-06

doi：10.19734/j.issn.1001-3695.2022.10.0484

0引言

現代操作系統應用了許多防御措施用于抵御網絡攻擊，例如：Web防火墻（Webapplicationfirewall，WAF）［1，2］、地址空間布局隨機化（addressspacelayoutrandomization，ASLR）［3］、控制流完整性防御（controlflowintegrity，CFI）［4～6］等。但這些防御手段是被動的，容易被攻擊者針對性地繞過，且難以對未知的漏洞進行防護［7～10］。Cox等人［11］在2006年提出多變體執(zhí)行（MVX）技術用于防御軟件漏洞，開創(chuàng)性地將防御手段由被動轉為主動。多變體執(zhí)行并行地運行一組功能相同但結構各異的程序變體，當接收到輸入時，多變體執(zhí)行會將輸入分發(fā)到各個程序變體，這些程序變體各自獨立地處理輸入，在檢查點，多變體執(zhí)行會對所有程序變體的輸出或執(zhí)行狀態(tài)進行檢查，通過檢測程序變體輸出或執(zhí)行狀態(tài)的不一致實現對攻擊行為的檢測［12～14］。在理想情況下，多變體執(zhí)行架構運行的一組變體功能相同，但結構完全不同，即任意一個程序變體中存在的漏洞只存在于當前變體中，任意兩個程序變體中不存在相同的漏洞。當攻擊者針對某一程序變體中的某一漏洞進行攻擊時，攻擊只能在該程序變體成功，在其他程序變體將攻擊失敗，因此程序變體將會產生不一致的輸出或狀態(tài)轉換，這種不一致在檢查點被檢測到，從而實現攻擊行為的檢測。

多變體執(zhí)行實現了從被動防御到主動防御的進步，通過在檢查點檢測程序變體的輸出或狀態(tài)轉換實現對攻擊行為的主動檢測，相較于傳統的被動防御技術，多變體執(zhí)行對攻擊行為的防御具有更強的主動性，改變了被動防御技術原有的“攻擊行為已生效—發(fā)現攻擊行為—檢查發(fā)現漏洞—修復漏洞”的防御模式［15］，在攻擊行為發(fā)生時即可發(fā)現并防御攻擊行為，阻止攻擊行為的生效。同時，不同于被動防御技術只能對已知漏洞進行防御，多變體執(zhí)行對未知漏洞同樣具有較好的防御效果。當未知漏洞只存在于少數程序變體中時，針對未知漏洞進行的攻擊行為將導致變體程序產生不一致的輸出或狀態(tài)轉換，這種不一致被檢測到即可實現攻擊行為的檢測和防御［16］。因此，多變體執(zhí)行作為一種新型的主動防御技術對于抵御網絡攻擊，保護網絡空間安全具有十分重要的意義和價值。

在理想情況下，多變體執(zhí)行的程序變體只有在攻擊行為下才會產生不一致的輸出或狀態(tài)轉換，而對于正常輸入，多變體執(zhí)行中的程序變體應該產生一致的輸出或狀態(tài)轉換。單線程程序能夠很好地支持這一性質：在程序變體內部自始至終都只有一個線程在執(zhí)行，當接收的輸入合法時，程序變體將產生一致的輸出或狀態(tài)轉移；當輸入非法，即發(fā)生攻擊行為時，當攻擊行為無法對所有程序變體生效時，程序變體將產生不一致的輸出或狀態(tài)轉換，不一致被檢測到即可檢測到攻擊行為的發(fā)生。不幸的是，這一性質難以擴展到多線程程序：程序變體內部有多個線程并發(fā)執(zhí)行，由于線程的隨機調度執(zhí)行，不同程序變體將具有不同的線程執(zhí)行順序，所以不同程序變體將產生不一致的輸出或狀態(tài)轉換，這些不一致的輸出或狀態(tài)轉換都是多線程程序的某種線程執(zhí)行順序的執(zhí)行結果，這些輸出或狀態(tài)轉換都是合法正確的，但這種不一致會被多變體執(zhí)行誤判為發(fā)生了攻擊行為，從而產生誤報，導致多線程程序難以在多變體執(zhí)行架構下運行［17～20］。

在真實的應用環(huán)境中，絕大多數軟件都是多線程的。因此，解決多線程程序在多變體執(zhí)行中的誤報問題，使多線程程序能夠在多變體執(zhí)行架構下運行，對于將多變體執(zhí)行應用于真實環(huán)境、保護網絡空間安全十分重要。近年來，許多研究者對多線程程序在多變體執(zhí)行架構中的運行進行了研究：Volckaert等人［21］在2017年提出了一種同步策略用于解決多線程程序在多變體執(zhí)行中的誤報問題，但此策略本質上是通過鎖步方式以主從模式對多個多線程程序變體中的系統調用進行排序執(zhí)行，僅解決了不同變體中系統調用執(zhí)行順序不一致導致的誤報問題。sterlund等人［22］在2019年針對內核中的信息泄露漏洞，提出了一種內核級多變體執(zhí)行方法kMVX，該方法通過在同一臺宿主機上運行多個內核變體，實現對內核中信息泄露漏洞的檢測和防御；通過修改Pthread線程庫，強制不同變體具有全局確定性的系統調用執(zhí)行順序，實現對多線程程序的支持。姚東等人［23］在2020年提出了MVX-CFI架構，該架構在MVX的基礎上實現了CFI，通過MVX和CFI的有效結合，進一步提升了執(zhí)行架構的安全性，在MVX-CFI中，以鎖步執(zhí)行系統調用的方式支持多線程程序的運行。Voulimeneas等人［24］在2021提出了一種混合分布式多變體執(zhí)行架構dMVX，用于降低分布式多變體執(zhí)行的性能開銷，該架構使用Volckaert等人［21］提出的同步策略實現對多線程程序的支持。

絕大部分研究者基于對系統調用執(zhí)行的處理實現多變體執(zhí)行對多線程程序的支持，但正如上文所述，此類策略只能解決不同變體中系統調用執(zhí)行順序不一致導致的誤報問題。因此，針對多線程程序在多變體執(zhí)行中的誤報問題，本文提出了一種編譯支持的多線程程序多變體執(zhí)行方法。本文的主要貢獻有：

a）分析并總結了多線程程序在多變體執(zhí)行中產生誤報問題的一類根本原因。

b）提出了一種多線程程序同步編譯模型，同步編譯模型針對誤報問題產生的根本原因，通過解決多線程程序的處理位置和多線程程序的處理方式兩個關鍵問題，消除了多線程程序在多變體執(zhí)行中由此類根本原因導致的誤報問題。

c）基于提出的多線程程序同步編譯模型，設計并實現了一種多線程程序同步編譯原型，證明同步編譯模型消除多線程程序在多變體執(zhí)行中誤報問題的有效性。

1多線程程序誤報問題

多變體執(zhí)行并行運行一組功能相同的異構程序變體。在理想情況下，當輸入合法時，不同程序變體產生一致的輸出或狀態(tài)轉換，從而對外部提供正常的程序功能；而對于攻擊行為，程序變體產生不一致的輸出或狀態(tài)轉換，多變體執(zhí)行通過檢測這種不一致實現對攻擊行為的檢測。在實際應用中，輸入合法，但不同程序變體產生不一致的輸出或狀態(tài)轉換，多變體執(zhí)行檢測到這種不一致誤判為發(fā)生了攻擊行為，稱為多變體執(zhí)行的誤報問題。多變體執(zhí)行的誤報問題使程序無法對外部提供正常的程序功能，導致多變體執(zhí)行的可用性降低。

多線程程序執(zhí)行時，程序中多個線程并發(fā)執(zhí)行，對于任意兩個線程，如果線程執(zhí)行的操作涉及同一變量并且至少有一個操作修改變量的狀態(tài)，那么線程執(zhí)行操作必然存在先后順序，即使在多處理器環(huán)境下也不可能同時執(zhí)行，且不同的執(zhí)行順序將導致變量具有不同的結果。一個典型的場景就是兩個線程并發(fā)寫同一個文件，線程不可能同時向文件中寫入，線程執(zhí)行寫文件操作存在先后順序，且不同的寫操作執(zhí)行順序將導致文件內容不同。相應地，如果線程執(zhí)行的操作不涉及同一變量或者涉及同一變量但操作不修改變量的狀態(tài)，那么線程執(zhí)行操作的順序不會對執(zhí)行結果產生影響，甚至在多處理器環(huán)境下線程可以同時執(zhí)行操作。一個典型的場景就是兩個線程各自寫不同的緩沖區(qū)，線程執(zhí)行寫操作的順序不同不會導致緩沖區(qū)內容不同，在多處理器環(huán)境下，兩個線程可以同時執(zhí)行寫緩沖區(qū)操作。在普通的運行環(huán)境中，多線程程序中線程并發(fā)執(zhí)行，由不同線程執(zhí)行順序產生的不同執(zhí)行結果均為正確結果。而多線程程序在多變體執(zhí)行架構中運行時，一組多線程程序變體并行運行，變體之間相互獨立，在每個變體內部，線程并發(fā)執(zhí)行。不同多線程程序變體可能具有不同的線程執(zhí)行順序，不同的線程執(zhí)行順序可能導致不同變體產生不同的正確執(zhí)行結果，然而這些正確執(zhí)行結果的不同會被多變體執(zhí)行檢測到，產生誤報問題。當多線程程序在多變體執(zhí)行架構中運行時，不同多線程程序變體的正確執(zhí)行結果導致了多變體執(zhí)行的誤報問題，影響了多線程程序在多變體執(zhí)行架構中的正常運行。生產者消費者模型是經典的多線程程序模型，以該程序模型為例對多線程程序在多變體執(zhí)行中的誤報問題進行分析：程序變體1和2中存在相同數量的生產者線程和消費者線程，生產者線程進行“生產”，對共享資源的數量進行增加；消費者線程進行“消費”，對共享資源的數量進行減少。同時，程序變體1和2中還存在相同數量的共享資源無關線程，即此類線程的執(zhí)行不會訪問共享資源。程序變體1和2的運行情況如圖1所示。

根據圖1中程序變體1和2的執(zhí)行情況可以得出如下結論：

結論1在多線程程序變體中，涉及相同變量且修改變量狀態(tài)的線程操作存在先后執(zhí)行順序，不同的執(zhí)行順序使變體產生不同的正確執(zhí)行結果。

結論2在多線程程序變體中，不涉及相同變量或涉及相同變量但不修改變量狀態(tài)的線程操作，其執(zhí)行順序不影響執(zhí)行結果。

結論3在多線程程序變體中，不同的線程操作執(zhí)行順序產生的不同執(zhí)行結果，只與執(zhí)行順序中涉及相同變量且修改變量狀態(tài)的線程操作有關。

基于結論1～3，對多線程程序在多變體執(zhí)行中產生誤報問題的一類根本原因進行定義：對于多線程程序中涉及相同變量的線程操作，如果至少有一個線程操作修改了變量的狀態(tài)，那么本文將此類操作定義為共享資源操作，操作涉及的相同變量則定義為共享資源；而涉及相同變量但所有操作均不修改變量狀態(tài)或不涉及相同變量的操作，本文將此類操作統一稱為共享資源無關操作，此類操作涉及的變量為非共享資源。按照該定義，多線程程序中的變量被劃分為共享資源和非共享資源，線程操作被劃分為共享資源操作和非共享資源操作。因此，多線程程序在多變體執(zhí)行中產生誤報問題的一類根本原因是不同多線程程序變體中共享資源操作具有不同的執(zhí)行順序。在不同多線程程序變體中，共享資源操作的線程執(zhí)行順序不同，導致不同變體中共享資源的狀態(tài)不一致，這種不一致被多變體執(zhí)行檢測到就會產生誤報問題。

基于多線程程序在多變體執(zhí)行中產生誤報問題的原因分析，解決這一類誤報問題的關鍵在于對多線程程序中的共享資源操作進行同步處理，通過使不同多線程程序變體中共享資源操作的線程執(zhí)行順序一致，使得不同變體中共享資源的狀態(tài)相同。

2多線程程序同步編譯模型

解決多線程程序在多變體執(zhí)行中誤報問題的關鍵在于對多線程程序中的共享資源操作進行同步處理，因此必然要對多線程程序中原有的操作進行修改，使其在多變體執(zhí)行架構中運行時能夠在共享資源操作處進行同步處理，從而消除不同多線程程序變體中共享資源狀態(tài)的不一致。編譯器為軟件生成提供了核心支持［25］，除了將源代碼翻譯為二進制代碼這一基礎功能外，編譯器還可以在編譯階段對程序進行特定的代碼處理和編譯優(yōu)化［26，27］。因此，本文利用編譯器對多線程程序進行處理。

利用編譯器處理多線程程序，消除不同多線程程序變體中共享資源狀態(tài)的不一致需要解決兩個關鍵問題：a）在多線程程序的什么位置進行處理；b）對多線程程序進行什么樣的處理。本文提出了一種多線程程序同步編譯模型解決這兩個關鍵問題：針對多線程程序的處理位置，同步編譯模型設計了一種多線程程序處理定位規(guī)則；針對多線程程序的處理方式，同步編譯模型設計了一種多線程程序同步處理算法。

2.1多線程程序處理定位規(guī)則

基于第1章多線程程序在多變體執(zhí)行中產生誤報問題原因的分析，對多線程程序進行處理的目的是在多變體執(zhí)行中對不同多線程程序變體中的共享資源操作進行同步處理，從而消除不同程序變體中共享資源狀態(tài)的不一致。因此，編譯器必然要對多線程程序中的共享資源操作進行處理，確定多線程程序中的處理位置就轉換為了確定多線程程序中的共享資源操作位置。如第1章所述，多線程程序中導致誤報問題的共享資源操作具有如下性質：

性質1存在兩個及以上線程對共享資源進行操作。

性質2至少有一個線程對共享資源的操作是寫操作，即改變共享資源狀態(tài)的操作。

性質3在多線程程序運行時，存在多種可能的共享資源操作線程執(zhí)行順序，不同的執(zhí)行順序將產生不同的共享資源狀態(tài)。

數據依賴關系是現代體系結構的編譯器為實現編譯優(yōu)化而定義的一種重要指令間依賴關系類型［26］。數據依賴關系具有如下性質：

性質4存在兩個及以上運算操作同一位置上的數據。

性質5至少有一個運算是寫運算。

性質6重新排列運算執(zhí)行順序將導致數據與原程序不同。

對比性質1～6，顯然共享資源操作和數據依賴關系具有十分相似的性質。因此，確定多線程程序中的共享資源操作位置能夠近似地采用數據依賴關系的分析方法。同步編譯模型基于數據依賴關系分析設計了一種多線程程序處理定位規(guī)則。

首先，類似于數據依賴關系對多線程程序進行如下定義：

定義1多線程程序中資源定義為ri。

定義2多線程程序中線程定義為ti。

定義3多線程程序中線程對資源的操作定義為pi。

然后，類似于數據依賴分析使用的調用圖［28］，為多線程程序建立操作圖：

定義4多線程程序中的每個資源ri對應操作圖中一個矩形節(jié)點。

定義5多線程程序中的每個線程ti對應操作圖中一個橢圓節(jié)點。

定義6多線程程序中線程對資源的操作對應操作圖中的一條有向邊，如果線程ti對資源ri進行操作，則存在一條節(jié)點ti指向節(jié)點ri的有向邊。

按照定義建立的多線程程序操作圖示例如圖2（b）所示，對比圖2（a）所示的調用圖，操作圖和調用圖具有十分相似的形式和意義。

在操作圖的基礎上，利用類似于數據依賴關系的分析方法對多線程程序中的共享資源以及對應的共享資源操作進行識別和定位。本文利用編譯器處理多線程程序，識別和定位多線程程序中共享資源操作的規(guī)則流程如下：

a）識別多線程程序中所有變量，即資源；

b）識別多線程程序中所有操作，并確定操作與資源的對應關系；

c）識別多線程程序中所有線程，并確定操作與線程的所屬關系；

d）基于步驟a）～c）確定的信息建立操作圖；

e）根據操作圖及共享資源操作的定義識別和定位多線程程序中的所有共享資源操作。

本文提出的多線程程序定位規(guī)則利用編譯器處理多線程程序，識別程序中的資源、線程操作、線程，并確定其關系，在此基礎上建立操作圖，實現對共享資源操作的識別和定位。

2.2多線程程序同步處理算法

針對多線程程序的處理方式，同步編譯模型設計了一種多線程程序同步處理算法。如前文所述，利用同步編譯模型處理多線程程序的根本目的是消除多個多線程程序變體在運行過程中共享資源操作的線程執(zhí)行順序不一致?；诖四康?，對多線程程序變體有如下定義：

定義7多線程程序變體定義為Vi。任意兩個多線程程序變體互為等價變體，變體中線程數量相同，且變體中任一線程在另一個變體中均有一個功能相同的線程與之對應。

定義8多線程程序變體中的線程定義為tij，tij表示多線程程序變體Vi中的第j個線程。對于任意兩個變體Vx和Vy（x≠y），線程txj和tyj具有相同功能，稱為等價線程。不同多線程程序變體中線程的等價性由線程功能決定，不同變體中具有相同功能的線程即為等價線程。

定義9多線程程序變體中的共享資源操作執(zhí)行定義為行向量op，op形如：（t13，0，0，t12，0，…），op中的每一個分量對應一種共享資源操作，分量上的線程表示此線程執(zhí)行了對應的共享資源操作。因此，行向量op序列描述了一個多線程程序變體中共享資源操作的線程執(zhí)行順序。

對于多線程程序中的任一線程，在線程內部，線程執(zhí)行共享資源操作的種類和順序是確定的。這種確定性來源于線程內部的指令串行執(zhí)行，因此，多線程程序變體中共享資源操作的線程執(zhí)行順序具有如下性質。

性質7多線程程序變體Vi中包含多個線程tij，Vi任意兩次運行對應的共享資源操作線程執(zhí)行順序分別為op1，op2，op3，…和op′1，op′2，op′3，…，則有：對于任意線程tij，op和op′序列中tij對應的分量序列一致，即tij的共享資源操作執(zhí)行順序一致。

基于上述性質，不失一般性地，不妨假設多線程程序中的每個線程只執(zhí)行一種類型的共享資源操作。由此有如下性質：

性質8線程tij能且只能出現在行向量op的某一固定分量上。

性質9對于任意涉及同一共享資源的操作x和y，在任意行向量op中，操作x和y對應的分量上不可能同時存在線程。

性質8和9說明，在建立每個線程執(zhí)行的共享資源操作類型映射的基礎上，線程序列能夠直接描述一個多線程程序變體中共享資源操作的線程執(zhí)行順序。

本文提出的同步編譯模型設計了一種多線程程序同步處理算法，用于消除不同多線程程序變體中共享資源操作線程執(zhí)行順序的不一致：

如算法1所述，多線程程序同步處理算法的核心在于對不同多線程程序變體中的共享資源操作執(zhí)行進行同步處理，當且僅當所有程序變體中的等價線程均執(zhí)行至某一共享資源操作處時，共享資源操作才被所有等價線程實際執(zhí)行直至執(zhí)行完畢；否則，共享資源操作等待執(zhí)行。

多線程程序同步處理算法的正確性易由歸納法得證：

a）初始狀態(tài)。所有多線程程序變體均未執(zhí)行，所有變體的共享資源操作線程執(zhí)行順序顯然一致。

b）假設狀態(tài)。所有多線程程序變體具有一致的共享資源操作線程執(zhí)行順序。

c）推導狀態(tài)。在線程內部，共享資源操作串行執(zhí)行，且對于任一共享資源操作，當且僅當其對應的所有等價線程均執(zhí)行至該共享資源操作時，共享資源操作才被所有等價線程實際執(zhí)行完畢。因此，假設狀態(tài)的下一個推導狀態(tài)，所有多線程程序變體仍然具有一致的共享資源操作線程執(zhí)行順序。

多線程程序同步處理算法的正確性由歸納法得證。多線程程序同步處理算法通過控制所有多線程程序變體中共享資源操作同步執(zhí)行，保證不同變體具有一致的共享資源操作線程執(zhí)行順序，從而保證不同變體中共享資源狀態(tài)一致。

圖3是經過多線程程序同步處理算法處理和不經過算法處理的共享資源操作線程執(zhí)行順序對比示意圖。其中線程1和2是操作同一共享資源的線程，線程3和4是操作同一共享資源的線程。如圖3（a）所示，由于共享資源操作線程執(zhí)行順序不一致，不同變體中的共享資源將產生不一致的狀態(tài)，從而導致多變體執(zhí)行產生誤報。

圖3（b）顯示了經過多線程程序同步處理算法處理的多線程程序變體具有如下性質：

性質10不同多線程程序變體具有不同的線程執(zhí)行順序。

性質11不同多線程程序變體具有一致的共享資源操作線程執(zhí)行順序。

性質10和11說明，經過同步處理算法處理，多線程程序在多變體執(zhí)行中運行時，不同多線程程序變體中共享資源操作同步執(zhí)行，具有一致的線程執(zhí)行順序，保證不同變體中共享資源狀態(tài)一致；同時，非共享資源操作的執(zhí)行不受約束，在一定程度上保持了多線程的特性。

本文針對多線程程序在多變體執(zhí)行中運行時，因共享資源操作線程執(zhí)行順序不一致導致的誤報問題，提出了一種通用的多線程程序同步編譯模型。同步編譯模型處理多線程程序，通過解決多線程程序的處理位置和多線程程序的處理方式兩個關鍵問題，消除此類原因導致的誤報問題。針對多線程程序的處理位置，同步編譯模型設計了一種多線程程序處理定位規(guī)則；針對多線程程序的處理方式，同步編譯模型設計了一種多線程程序同步處理算法。通過解決這兩個關鍵問題，同步編譯模型控制不同多線程程序變體具有一致的共享資源操作線程執(zhí)行順序，保證不同變體中共享資源狀態(tài)一致，從而消除誤報問題。

3多線程程序同步編譯原型

第2章針對多線程程序在多變體執(zhí)行中因共享資源操作線程執(zhí)行順序不一致導致的誤報問題提出了一種通用的同步編譯模型，并從原理上證明了同步編譯模型消除此類誤報問題的正確性。本章基于同步編譯模型，利用LLVM12.0編譯框架實現了一個同步編譯原型，從實現的角度提出了同步編譯模型的一種實現。類似于同步編譯模型，同步編譯原型也分為多線程程序定位處理原型和多線程程序同步處理原型兩個部分。

3.1多線程程序定位處理原型

基于第2章多線程程序處理定位規(guī)則，本文利用LLVM12.0編譯框架實現多線程程序定位處理原型。原型利用LLVM編譯框架在編譯階段對多線程程序對應的中間代碼進行分析和處理：首先，識別并記錄多線程程序中的所有資源，即程序中的變量，包括文件描述符、套接字、緩沖區(qū)等；然后，識別并記錄多線程程序中的所有操作，在中間代碼層面即為store、load、call等IR指令，并在此基礎上確定操作涉及的資源；然后，通過線程創(chuàng)建、線程分配等操作識別并記錄多線程程序中的所有線程，并確定每個線程執(zhí)行的操作；至此，多線程程序中的資源、操作、線程、操作涉及的資源和線程執(zhí)行的操作均已確定，多線程程序的操作圖建立完成；最后，根據操作圖即可識別多線程程序中的共享資源和共享資源操作，結合記錄即可完成多線程程序中共享資源操作的定位。

為了實現對共享資源操作的同步控制，定位處理原型在編譯階段對定位到的共享資源操作進行處理。如算法1所述，同步處理算法在共享資源操作實際執(zhí)行前進行同步控制，因此原型需要在共享資源操作前添加額外操作，通過執(zhí)行額外操作實現對共享資源操作的同步控制。原型以插樁函數的形式，通過在共享資源操作前插樁函數調用，實現額外操作的添加。在共享資源操作實際執(zhí)行時，所有多線程程序變體中共享資源操作同步執(zhí)行直至執(zhí)行完畢。共享資源操作執(zhí)行完畢后需要解除同步控制狀態(tài)，因此，原型以插樁函數的形式在共享資源操作后添加額外操作，通過執(zhí)行額外操作解除同步控制狀態(tài)。原型通過在共享資源操作前后插樁函數調用對共享資源操作的執(zhí)行實現同步控制，插樁函數記為同步處理函數，共享資源操作前同步處理函數記為前置同步處理函數，共享資源操作后同步處理函數記為后置同步處理函數。原型在共享資源操作前后插樁同步處理函數的形式如算法2所示。

算法2插樁同步處理函數示例

voidConsumer（Resource*ir，…）{

std：：unique_lock〈std：：mutex〉lock（ir-gt;mtx）；

char*buffer=（char*）malloc（MAX_SIZE）；

intlength=0；

…

while（flag）{

…

synop_before（threadId，status，…）；

consume（task）；

synop_after（threadId，…）；

…

}

…

return；

}

3.2多線程程序同步處理原型

經過定位處理原型處理后，多線程程序中共享資源操作的前后被插樁同步處理函數。同步處理函數對不同多線程程序變體中共享資源操作的執(zhí)行進行同步控制。本文基于多線程程序同步處理算法，利用可加載內核模塊在核心態(tài)實現了多線程程序同步處理原型。同步處理原型實際完成同步處理函數對共享資源操作的同步控制。首先，同步處理原型在核心態(tài)實現，維護了所有多線程程序變體中線程的等價關系，對于任一變體中任一線程，同步處理原型能確定該線程對應的所有等價線程。在此基礎上，同步處理函數執(zhí)行時向同步處理原型發(fā)出調用請求，由同步處理原型對共享資源操作執(zhí)行實際的同步處理。共享資源操作同步處理的具體步驟如下：

a）多線程程序變體中線程執(zhí)行前置同步處理函數，函數向同步處理原型發(fā)出同步處理調用請求，傳遞變體標識、線程標識、操作標識等識別信息。

b）同步處理原型接收同步處理調用請求，根據識別信息進行判斷，如果該線程對應的所有等價線程均已發(fā)出請求，同步處理原型進行同步處理，該線程和對應的所有等價線程進入同步狀態(tài)，同步執(zhí)行共享資源操作直至執(zhí)行完畢；如果存在等價線程未發(fā)出請求，記錄該線程的識別信息并阻塞該線程。

c）共享資源操作執(zhí)行完畢后，等價線程同步執(zhí)行后置同步處理函數，函數向同步處理原型發(fā)出同步狀態(tài)解除請求，同步處理原型解除等價線程的同步狀態(tài)，等價線程繼續(xù)正常執(zhí)行。

以上步驟是一次共享資源操作同步處理的過程，顯然，此過程符合同步編譯模型的多線程程序同步處理算法。同步處理原型對共享資源操作進行同步處理，使所有多線程程序變體具有一致的共享資源操作線程執(zhí)行順序，保證了所有變體中共享資源狀態(tài)的一致性，從而消除了共享資源狀態(tài)不一致導致的誤報問題。同步處理原型對共享資源操作進行同步處理的過程如圖4所示。

4實驗評估

針對第3章實現的多線程程序同步編譯原型，本章設計并實施了仿真實驗，用于驗證評估本文多線程程序同步編譯模型消除多線程程序在多變體執(zhí)行中誤報問題的有效性。

本文的實驗環(huán)境為：Ubuntu20.04系統、Linux5.4.0-42-generic內核版本、IntelSilver4210型號CPU、32GB內存容量。

首先，本文利用SPLASH-2x多線程程序測試集［21］進行實驗。SPLASH-2x是斯坦福大學推出的多線程程序基準測試集，測試集中包含了矩陣運算、數學變換、圖像模擬等多種類型的測試程序，是一個十分具有代表性的多線程程序測試集［21］。利用本文實現的同步編譯原型和普通LLVM12.0編譯器為SPLASH-2x中的程序分別生成兩個版本的可執(zhí)行程序，通過對比兩個版本的可執(zhí)行程序在多變體執(zhí)行架構中的誤報率評估本文方法：程序在多變體執(zhí)行架構中運行，當程序產生輸出時，多變體執(zhí)行架構對輸出進行檢測，如果所有程序變體的輸出一致，則正常輸出，并在日志中添加一條正常輸出記錄；如果程序變體的輸出不一致，則多變體執(zhí)行架構判斷為受到攻擊，不產生輸出，并在日志中添加一條攻擊記錄。在實驗中，程序在運行中未受到攻擊，因此日志中的每一條攻擊記錄都是一次誤報，統計日志中攻擊記錄的數量和正常輸出記錄的數量，計算攻擊記錄數量所占的比例即為程序一次運行的誤報率。由于多線程程序在運行中線程隨機調度執(zhí)行，單次的誤報率計算結果存在偶然性，為了提升誤報率計算的準確性，實驗將每個可執(zhí)行程序在多變體執(zhí)行架構中重復運行100次，對每次運行計算出誤報率，然后取算數平均值作為該可執(zhí)行程序最終的誤報率數值。實驗結果如表1所示。

表1結果顯示，通過同步編譯原型處理，SPLASH-2x中的多線程程序在多變體執(zhí)行中的誤報率得到顯著降低。然后，本文利用nginx1.7.0服務器進行進一步實驗。nginx是目前最流行的Web服務器軟件之一，是一個典型的應用級多線程程序。分別使用同步編譯原型和普通LLVM12.0編譯器為nginx1.7.0服務器生成兩個版本的可執(zhí)行程序，將兩個版本的可執(zhí)行程序分別在多變體執(zhí)行架構中運行。為了激活nginx的多線程特性，實驗利用Postman7.0.6軟件構造并發(fā)請求。Postman是目前最流行的并發(fā)測試工具之一，常被用于Web服務器的并發(fā)測試。利用Postman令兩個版本的可執(zhí)行程序處理不同數量的并發(fā)請求，并發(fā)請求數量（個）分別為100、200、500、1000、2000。通過對比兩個版本的可執(zhí)行程序在多變體執(zhí)行架構中處理并發(fā)請求的誤報率評估本文方法：nginx處理請求后會返回請求處理結果。當nginx在多變體執(zhí)行架構中運行時，多變體執(zhí)行架構對請求處理結果進行檢測。對于任一請求，如果所有程序變體的請求處理結果一致，多變體執(zhí)行架構返回請求處理結果，并在日志中添加一條請求正常處理記錄；如果程序變體的請求處理結果不一致，則多變體執(zhí)行架構判斷為受到攻擊，不返回請求處理結果，并在日志中添加一條攻擊記錄。在實驗中，Postman構造的并發(fā)請求中不存在攻擊，因此日志中的每一條攻擊記錄都是一次誤報。對于任一數量的并發(fā)請求，統計日志中攻擊記錄的數量和請求正常處理記錄的數量，計算攻擊記錄數量所占的比例即為該并發(fā)請求數量對應的誤報率。同樣地，為了提升誤報率計算的準確性，實驗對于任一并發(fā)請求數量，令兩個版本的可執(zhí)行程序在多變體執(zhí)行架構中分別重復處理100次，計算每次處理結果的誤報率，然后取算數平均值作為該并發(fā)請求數量最終的誤報率數值。實驗結果如圖5所示。

圖5結果顯示，利用同步編譯原型處理，nginx1.7.0服務器在多變體執(zhí)行中處理并發(fā)請求的誤報率得到顯著降低。實驗結果顯示，仿真實驗的結果與多線程程序同步編譯模型的理論證明一致，驗證了同步編譯模型消除多線程程序在多變體執(zhí)行中誤報問題的有效性。另外，仿真實驗既使用了具有代表性的多線程程序測試集SPLASH-2x，又使用了典型的應用級多線程程序nginx服務器，證明本文提出的多線程程序同步編譯模型具有較好的通用性，能夠有效應用于多種類型的多線程程序。

5結束語

在多變體執(zhí)行架構中，由于多線程程序變體中線程隨機調度執(zhí)行，導致不同程序變體產生不一致的狀態(tài)轉換，從而產生誤報問題，誤報問題嚴重影響了多變體執(zhí)行的可用性。本文對多線程程序在多變體執(zhí)行中產生誤報問題的原因進行分析，歸納了產生誤報問題的一類根本原因是不同多線程程序變體中共享資源操作的線程執(zhí)行順序不一致。針對此類根本原因，本文提出了一種編譯支持的多線程程序同步編譯模型，同步編譯模型通過解決多線程程序的處理位置和多線程程序的處理方式兩個關鍵問題，保證了不同程序變體中共享資源操作的線程執(zhí)行順序一致，消除了由此類原因導致的誤報問題，顯著降低了多線程程序在多變體執(zhí)行架構中運行時的誤報率，有效地支持了多線程程序在多變體執(zhí)行架構中的運行，提高了多變體執(zhí)行的可用性。但正如第4章仿真實驗結果所示，本文提出的同步編譯模型只解決了由不同多線程程序變體中共享資源操作線程執(zhí)行順序不一致導致的誤報問題，對于由隨機數（驗證碼、會話ID等）、時間戳等原因導致的誤報問題，本文提出的同步編譯模型并未解決（因此實驗結果中誤報率并未下降至0）。消除由這些原因導致的誤報問題需要在未來工作中進一步研究。

參考文獻：

［1］KruegerT，GehlC，RieckK，etal.TokDoc：aself-healingWebapplicationfirewall［C］//ProcofACMSymposiumonAppliedComputing.NewYork：ACMPress，2010：1846-1853.

［2］ClincyV，ShahriarH.Webapplicationfirewall：networksecuritymodelsandconfiguration［C］//Procofthe42ndIEEEAnnualComputerSoftwareandApplicationsConference.Piscataway，NJ：IEEEPress，2018：835-836.

［3］LuKangjie，SongChengyu，LeeB，etal.ASLR-guard：stoppingaddressspaceleakageforcodereuseattacks［C］//Procofthe22ndACMSIGSACConferenceonComputerandCommunicationsSecurity.NewYork：ACMPress，2015：280-291.

［4］AbadiM，BudiuM，ErlingssonU，etal.Control-flowintegrityprinciples，implementations，andapplications［J］.ACMTransonInformationandSystemSecurity，2009，13（1）：1-40.

［5］ContiM，CraneS，DaviL，etal.Losingcontrol：ontheeffectivenessofcontrol-flowintegrityunderstackattacks［C］//Procofthe22ndACMSIGSACConferenceonComputerandCommunicationsSecurity.NewYork：ACMPress，2015：952-963.

［6］BurowN，CarrSA，NashJ，etal.Control-flowintegrity：precision，security，andperformance［J］.ACMComputingSurveys，2017，50（1）：1-33.

［7］HundR，WillemsC，HolzT.PracticaltimingsidechannelattacksagainstkernelspaceASLR［C］//ProcofIEEESymposiumonSecurityandPrivacy.Piscataway，NJ：IEEEPress，2013：191-205.

［8］HuHong，ShindeS，AdrianS，etal.Data-orientedprogramming：ontheexpressivenessofnon-controldataattacks［C］//ProcofIEEESymposiumonSecurityandPrivacy.Piscataway，NJ：IEEEPress，2016：969-986.

［9］KuppaA，Le-KhacNA.Blackboxattacksonexplainableartificialintelligence（XAI）methodsincybersecurity［C］//ProcofInternationalJointConferenceonNeuralNetworks.Piscataway，NJ：IEEEPress，2020：1-8.

［10］KalinJ，CiolinoM，NoeverD，etal.Blackboxtowhitebox：discovermodelcharacteristicsbasedonstrategicprobing［C］//Procofthe3rdInternationalConferenceonArtificialIntelligenceforIndustries.Piscataway，NJ：IEEEPress，2020：60-63.

［11］CoxB，EvansD，FilipiA，etal.N-variantsystems：asecretlessframeworkforsecuritythroughdiversity［C］//ProcofUSENIXSecuritySymposium.2006：105-120.

［12］VolckaertS，DeSutterB，DeBaetsT，etal.GHUMVEE：efficient，effective，andflexiblereplication［C］//ProcofInternationalSymposiumonFoundationsandPracticeofSecurity.Berlin：Springer，2012：261-277.

［13］VolckaertS，CoppensB，VoulimeneasA，etal.Secureandefficientapplicationmonitoringandreplication［C］//ProcofUSENIXAnnualTechnicalConference.2016：167-179.

［14］LuKangjie，XuMeng，SongChengyu，etal.Stoppingmemorydisclosuresviadiversificationandreplicatedexecution［J］.IEEETransonDependableandSecureComputing，2018，18（1）：160-173.

［15］姜偉，方濱興，田志宏，等.基于攻防博弈模型的網絡安全測評和最優(yōu)主動防御［J］.計算機學報，2009，32（4）：817-827.（JiangWei，FangBinxing，TianZhihong，etal.Evaluatingnetworksecurityandoptimalactivedefensebasedonattack-defensegamemodel［J］.ChineseJournalofComputers，2009，32（4）：817-827.）

［16］VolckaertS，CoppensB，DeSutterB.Cloningyourgadgets：completeROPattackimmunitywithmulti-variantexecution［J］.IEEETransonDependableandSecureComputing，2015，13（4）：437-450.

［17］PinaL，GrumbergD，AndronidisA，etal.ADSLapproachtoreconcileequivalentdivergentprogramexecutions［C］//ProcofUSENIXAn-nualTechnicalConference.2017：417-429.

［18］SongD，LettnerJ，RajasekaranP，etal.SoK：sanitizingforsecurity［C］//ProcofIEEESymposiumonSecurityandPrivacy.Piscataway，NJ：IEEEPress，2019：1275-1295.

［19］LyerlyR，WangXiaoguang，RavindranB.Dynamicandsecurememorytransformationinuserspace［C］//ProcofEuropeanSymposiumonResearchinComputerSecurity.Cham：Springer，2020：237-256.

［20］WangZhe，WuChenggang，ZhangYinqian，etal.Safehidden：anefficientandsecureinformationhidingtechniqueusingre-randomization［C］//ProcofUSENIXSecuritySymposium.2019：1239-1256.

［21］VolckaertS，CoppensB，DeSutterB，etal.Tamingparallelisminamulti-variantexecutionenvironment［C］//Procofthe12thEuropeanConferenceonComputerSystems.2017：270-285.

［22］sterlundS，KoningK，OlivierP，etal.kMVX：detectingkernelinformationleakswithmulti-variantexecution［C］//Procofthe24thInternationalConferenceonArchitecturalSupportforProgrammingLanguagesandOperatingSystems.2019：559-572.

［23］姚東，張錚，張高斐，等.MVX-CFI：一種實用的軟件安全主動防御架構［J］.信息安全學報，2020，5（4）：44-54.（YaoDong，ZhangZheng，ZhangGaofei，etal.MVX-CFI：apracticalactivedefenseframeworkforsoftwaresecurity［J］.JournalofCyberSecurity，2020，5（4）：44-54.）

［24］VoulimeneasA，SongD，LarsenP，etal.dMVX：secureandefficientmulti-variantexecutioninadistributedsetting［C］//Procofthe14thEuropeanWorkshoponSystemsSecurity.2021：41-47.

［25］LattnerC，AdveV.LLVM：acompilationframeworkforlifelongprogramanalysisamp;transformation［C］//ProcofInternationalSymposiumonCodeGenerationandOptimization.Piscataway，NJ：IEEEPress，2004：75-86.

［26］KennedyK，AllenJR.Optimizingcompilersformodernarchitectures：adependence-basedapproach［M］.SanFrancisco，CA：MorganKaufmannPublishersInc.，2002.

［27］LattnerC，AminiM，BondhugulaU，etal.MLIR：scalingcompilerinfrastructurefordomainspecificcomputation［C］//ProcofIEEE/ACMInternationalSymposiumonCodeGenerationandOptimization.Pisca-taway，NJ：IEEEPress，2021：2-14.

［28］RyderBG.Constructingthecallgraphofaprogram［J］.IEEETransonSoftwareEngineering，1979，5（3）：216-226.