2009-02-12 104 views

回答

0

從技術上講,本機代碼仿真器可以用託管代碼編寫,但它不在裸機上運行。

我懷疑任何依靠軟件驗證隔離訪問共享資源(如Singularity)的託管操作系統允許直接運行非託管代碼,因爲它可能會繞過軟件提供的所有保護(與常規操作系統不同,有些受管理的操作系統不依賴硬件提供的保護技術)。

3

首先,您應該首先定義「託管」和「本地」。在像Midori這樣的「受管理」的操作系統上,內核仍然被編譯(預編譯爲機器代碼),而不是從IL進行jit編譯。所以,我認爲這是「管理」與「本地」之間的區別。

在我看來,「管理」和「本地」代碼還有兩個區別 - 代碼可證實性和資源管理。

大多數「原生」代碼是無法驗證的,因此「託管」操作系統加載器可能會拒絕加載「原生」圖像。當然,製作可驗證的「原生」代碼是可能的,但這會帶來很多限制,實質上與「受管理」代碼沒有區別。

「託管」操作系統中的資源將由操作系統管理,而不是應用程序。 「本地」代碼通常分配並清理其資源。由OS API分配並賦予「本機」代碼的資源會發生什麼情況?或相反亦然?關於誰和什麼時候進行資源管理和清理應該有非常明確的規則。出於安全原因,我無法想象操作系統將「本地」代碼直接控制到除進程虛擬內存之外的任何資源。因此,「原生」的唯一理由是實現你自己的內存管理。

今天的「natve」代碼不會按照上述任何規則播放。因此,「受管理」的操作系統應該拒絕直接執行它。雖然,「託管」操作系統可能會提供像Hyper-V這樣的虛擬化層,並在虛擬機中託管「本機」代碼。

1

通過託管我假設你的意思是代碼運行在一個環境中,對代碼進行類型安全檢查,安全內存訪問等等。而原生的,相反。現在它的這個執行環境決定它是否允許本地代碼在未經驗證的情況下運行。以這種方式來看待:操作系統和頂層應用程序都需要執行env才能運行。它們唯一的關係是頂層應用程序調用底層操作系統來執行較低級別的任務,但在調用操作系統時,它實際上是由執行env(它可能/可能不支持代碼驗證,例如依賴於編譯代碼時通過的選項),並且當控制傳輸到OS時,執行env再次負責執行OS代碼(該環境可能是另一個envionment在一起),在這種情況下,它驗證操作系統代碼(因爲它是一個託管操作系統)。

因此,理論上,本機代碼可能/可能無法在託管操作系統上運行。這一切都取決於其運行的執行環境的行爲。操作系統是否管理不會影響它是否在其上運行。如果頂層應用程序和操作系統具有相同的執行環境(託管),則本機代碼不會在操作系統上運行。

0

從MS研究紙Singularity: Rethinking the Software Stack(P9):

保護域可能在原則上,主機寫入包含在不安全的語言如 C++無法驗證的代碼單個進程 。儘管對於運行遺留代碼非常有用,但我們還沒有探索這種可能性。目前, 保護域內的所有代碼也包含在SIP內,其繼續 以提供隔離和故障限制邊界。

因此,雖然目前尚未探索,但它是一種明顯的可能性。非託管代碼可以在硬件保護域中運行,它將不得不處理虛擬內存,TLB等性能問題,但系統作爲一個整體可以在運行非託管代碼時安全地維護其不變量。

相關問題