absmiddle Windows 95 強固性探究之二


[解說] [版主] 本文經清大電機 mswindows 版主 plumelet 同意後轉貼 Alex_Yu@f250.n722.z6.fido.net (Alex Yu): Unprotected mode. DOS is a perfect example of an unprotected OS. Any DOS application can freely form a pointer into DOS itself then write to this pointer and clobber the system. For example, Figure 1 (a) shows a one-line DEBUG command that fills the lower 64KB of memory with zeroes. Figure 1 (b) shows how this same operation looks in C. These operations instantly crash DOS. 非保護模式: DOS 是個無防護作業系統的完美例子。任何 DOS 應用程式都能任意產生一個指向 DOS 本體的指標, 寫入該指標指向處, 整倒整個系統, 如圖一(a)所示, 一行 DEBUG 將記 憶體最前面 64KB 記憶體填入 0 的命令, 圖一(b) 則是如何在 C 中完成同一動作。 這些動作立刻就毀了DOS. DOS boxes in Windows, as in any multitasking OS, are in many ways a big improvement over DOS itself. Each DOS box is its own "virtual machine" (VM). You can run multiple DOS boxes, and they can use services supplied by protected-mode components that do not occupy conventional memory (see "Vexed by VxDs," InfoWorld, Feb. 27, page 1). Windows 裡的 DOS box, 如在任何多工作業系列中的, 在許多方面較 DOS 本身有著重 大改進。每個 DOS box 有它自己的 "虛擬機器" (Virtual machine, VM). 你能跑多個 DOS box, 而它們能使用不存在傳統記憶體中的保護模式元件所提供的服務。 見(InfoWorld 二月二十七號第一頁, "Vxeded by VxDs".) Nonetheless, the buggy DOS code in Figure 1 also crashes Windows 95 -- not just the DOS box but all of Windows 95. This is surprising, because in the Chicago reviewers guide (subsequently published by Microsoft Press as Introducing Microsoft Windows 95) Microsoft says, "In Windows, VMs are fully protected from one another, as well as from other applications running on the. system. This protection prevents errant DOS-based applications from overwriting memory occupied or used by system components or other ap lications." 但是, 圖一中有問題的 DOS 程式碼也把 Windows 95 當掉了 -- 不只是那個 DOS box, 而是整個 Windows 95. 這真令人驚訝, 因為在 Chicago reviewers guide 中 M$ 說, "在 Windows 裡, 虛擬機器被完全分隔於其他虛擬機器與其他在系統上執行的應用程式 而保護著。這種保護避免出錯的 DOS 應用程式覆蓋寫入屬於或被系統元件或其他應用 程式使用的記憶體。" (譯按: M$ 又說, 只有當你把 DOS kernel 防寫打開時, 這種保護才會完全生效...... 藉由 DOS kernel page read only, 將大大增強系統的穩定性......但代之而來的, 那些需要寫入 DOS kernel/data 的程式執行速度將大降。 一樣是 Chicago reviewers guide 中提到的, InfoWorld 只列出他們想說的話。) As Rob Hummel, author of several programming books, pointed out in Microsoft's WINBTU forum on CompuServe, the part about "system components" is. simply untrue. The one-line DEBUG command shown in Figure 1 (a) emulates an errant DOS-based program that Windows 95 freely allows to overwrite the system. 如 Rob Hummel, 數本程式設計書籍的作者, 在 CompuServe 的 M$ WINBTU 論壇所指出 關於 "系統元件" 的話, 其實不正確。圖一(a) 的單行DEBUG 命令模擬了一個 Windows 95 允許任意覆寫系統資料的出錯了的DOS 程式。 Unfortunately, the additional "protection" feature in Windows 95, which turns. code into read-only, protects only some of DOS. Even with "protection" enabled, the DEBUG command shown in Figure 1 (a) still crashes all of Windows 95. 不幸的, Windows 95 這將程式碼設成唯讀的額外 "保護" 特性只保護了 DOS 的一部份 。即使 "保護" 開著, 圖一(a) 的 DEBUG 命令仍然當掉了整個 Windows 95. Three types of memory. But if a DOS program such as DEBUG runs in its own "virtual machine," how can it crash Windows applications, which run in their own separate "System VM?" Although each VM has -- for the most part -- its own separate address space, there is also a "global" area shared by all VMs. This global area represents memory that was allocated before Windows started up -- that is, memory belonging to DOS, Windows 95 real-mode device drivers such as HIMEM, IFSHLP, DRVSPACE, and so on. 三種記憶體: 不過, 如果一個如 DEBUG 般的 DOS 程式在自己的虛擬機器中跑, 它如何能當掉在自己 獨立的系統虛擬機器中跑的 Windows 應用程式? 雖然每個虛擬機器擁有 - 大部份 - 自己的獨立位址空間(譯: It is, Yes and No.), 也有一塊所有虛擬機器共享的整體 區域。這整體區域代表在進 Windows 前所配置的記憶體, 如 DOS 的記憶體, Windows 95 實際模式驅動程式如 HIMEM, IFSHLP, DRVSPACE 等的。 In addition, the Windows Virtual Machine Manager (VMM) provides a function, documented in the Windows Device Driver Kit, called _Allocate_Global_V86_Data_Area. As its name implies, this function allows VxDs to allocate "global" memory in the Virtual-8086 address space. This memory is located below 1MB and is visible to all VMs. Key VxDs such as DOSMGR, VSHARE, IFSMGR, IOS, and SHELL use this service to allocate global buffers below 1MB. 另外, Windows 虛擬機器管理者 (Windows Virtual Machine Manager, VMM) 提供 一個 Windows Device Driver Kit 文件上稱為 _Allocate_Global_V86_Data_Area 的 函數。如名稱所示, 它允許 VxDs 在虛擬 8086 位址空間內配置整體記憶體。這被配 置的記憶體位於 1 MB 位址下, 對所有虛擬機器都是可見的。重要的 VxD 如 DOSMGR, VSHARE, IFSMGR, IOS 及 SHELL 都使用這功能配置了 1 MB 位址下的整體緩衝區。 These buffers are at the mercy of DOS programs. It is important to note that data for the file system (IFSMGR, or Installable File System Manager) and the disk (IOS, or I/O Supervisor) are present in these buffers. 這些緩衝區可任 DOS 程式宰割。值得注意的, 檔案系統 (IFSMGR, 可安裝檔案系統 管理程式) 及磁碟 (IOS, I/O supervisor) 的資料都在這些緩衝區中。 On the other hand, there are plenty of areas below 1MB that a DOS application can freely overwrite but that won't bring down all of Windows. 另一方面, 還有許多 1 MB 位址下可被 DOS 應用程式任意覆寫的區域, 不過寫入它們 並不會讓整個Windows 完蛋。 Each VM also has "local" memory below 1MB; this corresponds to conventional memory that was free before Windows started up. For example, some key parts of the Win16 kernel are located below 1MB. 每個虛擬機器也在 1 MB 下有自己的區域性記憶體; 對應於進 Windows 前的可用記憶 體。如某些 Win16 核心的關鍵部份就在 1 MB 下。 Although we'll see later that this does cause other problems in Windows 95, at least these are located in the System VM's separate address space and are thus inaccessible to programs running in DOS boxes. 雖然我們底下將看到這將造成 Windows 95 中其他問題, 至少他們是在系統虛擬機器 的不同位址空間中, 所以 DOS box 中的程式摸不到它們。 有幾點要說明的: 1.檔案與磁碟系統資料在1 MB 位址下可被 DOS 程式寫入是相容於舊 DOS 程式的關鍵, 因為有不少DOS 工具程式靠操作這些東西過活。 2.如果Windows 95 把檔案與磁碟系統資料放在 1 MB 下, 並想讓 DOS 應用程式的操 作不至於影響系統穩定性, M$ 將面對資料同步或效率的問題。如何讓 DOS box 中 的程式與 Windows 應用程式看到一樣的檔案資料、磁碟資料? 如果某一方更動了資 料, 必須讓另一方也能看見: 如果使用 page deny write 造成 page fault 的方式 來處理效率會大降; 如果使用不同 instance data 的方式, 資料如何同步? 相容、效率與穩定不可兼得呀。 我們當然能大叫: None of our business, it's M$' business! 不過那樣子未免也太XXX了。
上一層目錄