2007年7月19日 星期四

深入探索 Windows Vista 核心:第三篇

http://technet.microsoft.com/zh-tw/magazine/2007.04.vistakernel.aspx

‧深入探索 Windows Vista 核心:第三篇

At a Glance:
* 可靠性
* 修復性
* 安全性

這一系列的文章到目前為止所涵蓋的 Windows Vista 核心增強功能,都與處理程序、I/O、記憶體管理、系統啟動、關機和電源管理有關。這是第三篇,也是最後一篇,

我將著重於可靠性、修復性和安全性等領域的功能和改進。

在這一系列的文章中,有一項功能我沒有談到,即使用者帳戶控制 (User Account Control,UAC),它是由數種不同的技術所構成,包括舊版應用程式的檔案系統和登錄虛擬化、同意提高權限來存取管理權限,以及 Windows® Integrity Level 機制,該機制可隔離以管理權限執行的處理程序與使用相同帳戶執行的較低權限處理程序。我將在未來的 TechNet Magazine 中深入探討 UAC 內部資訊。

Windows Vista™ 改進了系統的可靠性,並透過一些新功能和增強功能來提升您診斷系統和應用程式問題的能力。例如,核心的 Windows 事件追蹤 (Event Tracing for Windows,ETW) 記錄程式會保持作用中狀態,並在循環緩衝區中產生檔案、登錄、中斷和其他活動類型的追蹤事件。發生問題時,新的 Windows 診斷基礎結構 (Windows Diagnostic Infrastructure,WDI) 可擷取緩衝區的快照,並在本機上分析它,或將它上載至 Microsoft 支援中心進行疑難排解。

新的 Windows 效能和可靠性監視器可協助使用者了解發生的錯誤 (例如毀損/當機和懸置) 與系統設定變更之間的關係。功能強大的系統修復工具 (System Repair Tool,SRT) 取代了修復主控台,以進行無法開機系統的離線修復。

有三個領域仰賴系統的核心層級變更,因此值得在本篇文章中仔細探索:核心交易管理員 (Kernel Transaction Manager,KTM)、改進的毀損/當機處理,以及舊版的系統。


核心交易管理員


在軟體開發領域中,比較瑣碎的一環是錯誤狀況的處理。尤其是在執行高階作業的過程中,如果應用程式已完成一項或多項子作業而導致檔案系統或登錄變更時,更是如此。例如,應用程式的軟體更新服務可能進行了數項登錄更新、取代了其中一個應用程式可執行檔,然後在嘗試更新第二個應用程式可執行檔時遭到拒絕。如果該服務不想使應用程式處於不一致的狀態,就必須追蹤所做的一切變更,並妥當地進行復原。錯誤修復碼的測試很困難,通常會省略,因此修復碼中的錯誤可能導致前功盡棄。

針對 Windows Vista 撰寫的應用程式,可以利用核心交易管理員結合 NTFS 的新交易支援功能及登錄資訊,輕鬆獲得自動錯誤修復能力。當應用程式想要做一些相關的變更時,可以建立分散式交易協調器 (Distributed Transaction Coordinator,DTC) 交易和 KTM 交易控制碼,或直接建立 KTM 控制碼,並使檔案和登錄機碼的修改與交易產生關聯。如果所有變更都成功完成,應用程式會認可該交易並套用變更,但在這之前,應用程式可隨時回復交易及捨棄變更。

另一項好處是,在交易認可之前,其他應用程式不會看到該交易所做的變更,而且在 Windows Vista 和即將推出的 Windows Server® (代號 "Longhorn") 中使用 DTC 的應用程式,可以與 SQL Server™、Microsoft® 訊息佇列伺服器 (Microsoft Message Queue Server,MSMQ) 及其他資料庫協調其交易。因此,使用 KTM 交易的應用程式更新服務,絕對不會讓應用程式處於不一致狀態。這就是 Windows Update 和系統還原兩項服務都使用交易的原因。

KTM 是交易支援的核心,可讓交易資源管理員 (例如 NTFS) 和系統登錄針對應用程式所做的特定變更進行更新協調。在 Windows Vista 中,NTFS 會使用一個稱為 TxF 的延伸模組來支援交易。系統登錄則使用類似的延伸模組,稱為 TxR。這些核心模式資源管理員會與 KTM 共同協調交易狀態,就像使用者模式資源管理員會使用 DTC 在多個使用者模式資源管理員之間協調交易狀態一樣。其他廠商也可以使用 KTM 來實作他們自己的資源管理員。

TxF 和 TxR 均定義一組新的檔案系統和登錄 API,它們與現有的類似,只不過它們還包括了交易參數。如果應用程式想要在交易中建立檔案,它會先使用 KTM 建立交易,然後將產生的交易控制碼傳遞至要建立新檔案的 API。

TxF 和 TxR 均仰賴一般記錄檔系統 (Common Log File System,CLFS) (%SystemRoot%\System32\Clfs.sys) 的高速檔案系統記錄功能,這是在 Windows Server 2003 R2 所引進的。TxR 和 TxF 在認可交易之前,會使用 CLFS 持續儲存交易狀態的變更。這可讓它們在即使發生電源中斷時,亦可提供交易修復和可靠性。除了 CLFS 記錄檔之外,TxR 還會在 %Systemroot%\System32\Config\Txr 中建立一組相關記錄檔,來追蹤系統登錄檔的交易變更 (如 [圖 1] 所示),並對每一個使用者登錄 Hive 建立個別的記錄檔。TxF 會將每一個磁碟區的交易資料儲存在磁碟區的一個隱藏目錄中,稱為 \$Extend\$RmMetadata。
















圖 1
系統登錄 Hive TxR 記錄檔 (Click the image for a larger view)

增強式毀損/當機支援

當 Windows 發生無法修復的核心模式錯誤時 -- 不論是由於不良的裝置驅動程式、硬體故障或作業系統所造成 -- 它都會在顯示著名的藍色螢幕之後嘗試中止系統,以防止磁碟資料毀損,並將部分或全部實體記憶體寫入毀損傾印檔 (如果已設定這麼做的話)。傾印檔很有幫助,因為您在毀損/當機後重新開機時,Microsoft Online Crash Analysis (OCA) 服務會提議分析該檔來尋找根本原因。您也可以使用 Microsoft Debugging Tools for Windows 自行分析。

不 過在舊版的 Windows 中,要等到工作階段管理員 (%Systemroot%\System32\Smss.exe) 處理程序將分頁檔初始化之後,才能啟用毀損傾印檔的支援。這表示在那之前發生的任何重要錯誤只會導致藍色螢幕的出現,但不會有傾印檔。由於大部分裝置驅動 程式的初始化都是發生在 Smss.exe 啟動之前,因此在開機初期毀損/當機時,會因為無法導致毀損傾印而使原因的診斷變得非常困難。

Windows Vista 會在所有開機啟動裝置驅動程式初始化之後但在載入系統啟動驅動程式之前,將傾印檔支援初始化,以縮減無法產生傾印檔的時間。此變更讓您萬一在開機程序初期 發生毀損/當機,系統也可以記錄毀損傾印檔,讓 OCA 幫助您解決問題。不僅如此,Windows Vista 還會將資料儲存到以 64KB 區塊為單位的傾印檔,而舊版的 Windows 只會使用 4KB 區塊寫入。此變更提供了更大的傾印檔,且寫入速度快了 10 倍。

應 用程式的毀損/當機處理在 Windows Vista 中也進一步獲得改善。在舊版的 Windows 中,當應用程式毀損/當機時,會執行一個無法處理的例外狀況處理常式。此處理常式會啟動 Microsoft 應用程式錯誤報告 (Application Error Reporting,AER) 處理程序 (%Systemroot%\System32\Dwwin.exe) 以顯示對話方塊,指出該程式已毀損/當機,並詢問您是否要將錯誤報告傳送至 Microsoft。不過,如果在毀損/當機期間,該處理程序的主執行緒堆疊受損,當無法處理的例外狀況處理常式執行時,會導致核心終止該處理程序、程式 視窗會立刻消失,而且不會出現錯誤報告對話方塊。

Windows Vista 則是將錯誤處理從毀損/當機處理程序的內容中,轉移至 Windows 錯誤報告 (Windows Error Reporting,WER) 這項新服務。此服務是由服務主機 (Service Hosting) 處理程序內的 DLL (%Systemroot%\System32\Wersvc.dll) 實作。當應用程式毀損/當機時,它仍然會執行無法處理的例外狀況處理常式,但該處理常式會傳送訊息至 WER 服務,而此服務將啟動 WER 錯誤報告處理程序 (%Systemroot%\System32\Werfault.exe) 來顯示錯誤報告對話方塊。如果堆疊已受損且無法處理的例外狀況處理常式毀損/當機,則處理常式會再度執行,並再度毀損/當機,直到耗盡該執行緒的所有堆疊 (臨時記憶體區),此時核心會介入並將毀損/當機通知訊息傳送至該服務。

您 可以在 [圖 2] 和 [圖 3] 中看到這兩種方式的對照,這兩個圖顯示會造成毀損/當機的測試程式 Accvio.exe 在 Windows XP 和 Windows Vista 上的處理程序關係,並在其中用綠色反白的方式標示出錯誤報告的處理程序。新的 Windows Vista 錯誤處理架構表示程式不會在 Microsoft 未有機會取得錯誤報告以協助軟體開發人員改進其應用程式之前自動終止。


圖 2a Windows XP 中的應用程式錯誤處理 (Click the image for a larger view)

圖 2b (Click the image for a larger view)


圖 3a Windows Vista 中的應用程式錯誤處理 (Click the image for a larger view)











圖 3b


磁碟區陰影複製

Windows XP 引進一種技術,叫做磁碟區陰影複製,可產生磁碟區的時間點快照集。製作備份的應用程式可以使用這些快照集來產生一致的備份映像,但快照集通常會隱藏起來,而且只會在製作備份的期間保留。

快 照集實際上並非磁碟區的完整備份,而是磁碟區較早的檢視,其中是由即時磁碟區資料加上上一次產生快照集之後所變更的磁碟區所組成。磁碟區快照集提供者驅動 程式 (%Systemroot\%System32\Drivers\Volsnap.sys) 會監視以磁碟區為目標的作業,並在容許磁區變更之前建立磁區的備份,然後將原始資料儲存在該磁碟區的系統磁碟區資訊目錄內、與快照集相關聯的檔案中。

Windows Server 2003 藉由共用資料夾陰影複製功能,向伺服器的系統管理員以及用戶端系統的使用者公開了快照集的管理。此功能啟用了持續性快照集,讓使用者可透過檔案總管內容對 話方塊上的 [舊版] 索引標籤,存取其位於伺服器檔案共用中的資料夾和檔案的快照集。

Windows Vista 的舊版功能對所有用戶端系統提供此支援,並且會自動建立磁碟區快照集 (通常一天一次),您可以透過檔案總管內容對話方塊,使用共用資料夾之陰影複製所使用的相同介面來存取快照集。這可讓您檢視、還原或複製您可能不小心修改 或刪除的舊版檔案和目錄。雖然在技術上不算是新技術,但磁碟區陰影複製的 Windows Vista 舊版功能實作,在用戶端桌面環境中最佳化 Windows Server 2003 當初的實作。

Windows Vista 也利用磁碟區快照集來統一使用者和系統資料保護機制,避免儲存冗餘的備份資料。當應用程式的安裝或設定變更造成不正確或非預期的行為時,您可以使用 Windows XP 的系統還原功能 (在 Windows NT® 系列作業系統中所引進),將系統檔案和資料還原至建立還原點時的狀態。

在 Windows XP 中,系統還原會使用檔案系統篩選器驅動程式 (可在檔案層級查看變更的一種驅動程式),在系統檔案變更時建立系統檔案的備份。在 Windows Vista 上,系統還原會使用磁碟區快照集。當您使用 Windows Vista 中的系統還原使用者介面回到還原點時,實際上您是在從與還原點相關聯的快照集,將修改過之系統檔案的舊版複製到即時磁碟區。


BitLocker

Windows Vista 是目前最安全的 Windows 版本。其中除了納入 Windows Defender 反間諜軟體引擎之外,Windows Vista 還引進了數種安全性和深度防禦功能,包括 BitLocker™ 完整磁碟區加密、核心模式程式碼的程式碼簽署機制、受保護的處理程序、位址空間隨機載入 (Address Space Load Randomization),以及對 Windows 服務安全性和使用者帳戶控制的改進。

作 業系統只能在作用中狀態下實施其安全性原則,因此,您必須採取其他防護措施,以避免系統的實體安全受到危害,以及避免他人可從作業系統以外的管道存取資 料。像 BIOS 密碼和加密之類的硬體防護機制,是一般用來防止未經授權存取的兩種技術 (尤其是在最可能遺失或遭竊的筆記型電腦上)。

Windows 2000 引進了加密檔案系統 (EFS),在 Windows Vista 的化身中,EFS 還包括許多對舊版實作的改進,其中包括效能的增強、對加密分頁檔的支援,以及將使用者 EFS 金鑰儲存在智慧卡上的功能。不過,您不能使用 EFS 金鑰來保護系統機密區域的存取,例如登錄 Hive 檔案。例如,如果群組原則容許您即使未連接到網域也可以登入筆記型電腦,表示您的網域憑證檢查器已快取在登錄中,所以攻擊者可利用工具取得您的網域帳戶密 碼雜湊,並透過密碼破解程式來取得您的密碼。有了密碼便可以存取您的帳戶和 EFS 檔案 (假設您未將 EFS 金鑰儲存在智慧卡上)。

為 了使整個開機磁碟區 (含有 Windows 目錄的磁碟區) 更容易加密,包括其所有系統檔案和資料,Windows Vista 引進一種完整磁碟區加密功能,稱為 Windows BitLocker 磁碟機加密 (Windows BitLocker Drive Encryption)。與 NTFS 檔案系統驅動程式實作並在檔案層級操作的 EFS 不同,BitLocker 是使用完整磁碟區加密 (FVE) 驅動程式在磁碟區層級進行加密 (%Systemroot%\System32\Drivers\Fvevol.sys),如 [圖 4] 所示。



圖 4 BitLocker FVE 篩選器驅動程式 (Click the image for a larger view)

FVE 是一個篩選器驅動程式,因此,一旦開始啟用 BitLocker,它就會自動查看 NTFS 傳送至磁碟區的所有 I/O 要求,使用指派給該磁碟區的完整磁碟區加密金鑰 (FVEK) 將寫入的區塊加密,並將讀取的區塊解密。根據預設,磁碟區會使用 128 位元 AES 金鑰和 128 位元 Diffuser 金鑰進行加密。因為加密和解密是發生在 I/O 系統的 NTFS 之下,所以 NTFS 會以為磁碟區未加密,NTFS 甚至不需要知道已啟用 BitLocker。不過,如果您嘗試從 Windows 以外讀取磁碟區的資料,它看起來會像是隨機資料。

FVEK 會以磁碟區主要金鑰 (VMK) 加密並儲存在磁碟區的特殊中繼資料區域內。當您設定 BitLocker 時,視系統的硬體功能而定,有一些選項可供您選擇保護 VMK 的方式。如果系統含有符合 1.2 版 TPM 規格的可信賴平台模組 (TPM),並且有相關聯的 BIOS 支援,您就可以使用 TPM 加密 VMK,讓系統使用儲存在 TPM 的金鑰和儲存在 USB Flash 裝置上的金鑰來加密 VMK,或者使用 TPM 儲存的金鑰和您在系統開機時輸入的 PIN 來加密此金鑰。對於沒有 TPM 的系統,BitLocker 可讓您使用儲存在外接式 USB Flash 裝置上的金鑰來加密 VMK。無論如何,您將需要未加密的 1.5GB NTFS 系統磁碟區,即儲存開機管理程式和開機設定資料庫 (BCD) 的磁碟區。

使 用 TPM 的優點是,BitLocker 會使用 TPM 功能來確保它不會將 VMK 解密,如果 BIOS 或系統開機檔在啟用 BitLocker 之後有變更過,它會將開機磁碟區解除鎖定。第一次將系統磁碟區加密之後,每次執行上述任何元件的更新時,BitLocker 便會計算這些元件的 SHA-1 雜湊,並在 TPM 裝置驅動程式 (%Systemroot%\System32\Drivers\Tpm.sys) 的幫助之下,以 TPM 的不同平台設定暫存器 (PCR) 儲存每一個雜湊,稱為度量。然後,它會使用 TPM 密封 VMK,這是使用儲存在 TPM 中的私密金鑰為 VMK 加密的一項作業,而 BitLocker 會把儲存在 PCR 的值連同其他資料一起傳遞至 TPM。然後 BitLocker 會將密封的 VMK 和加密的 FVEK,都儲存在磁碟區的中繼資料區域中。

當系統開機時,它 會測量自己的雜湊和 PCR 載入程式碼,並將雜湊寫入至 TPM 的第一個 PCR。然後,它會雜湊 BIOS 並將該度量儲存在適當的 PCR 中。接著會由 BIOS 雜湊開機程序的下一個元件,即開機磁碟區的主開機記錄 (MBR),此處理程序將繼續進行,直到完成作業系統載入程式的測量為止。每一個後續執行的程式碼片段,各負責測量它載入的程式碼,並將測量結果儲存到 TPM 中的適當暫存器。最後,當使用者選取開機的作業系統時,開機管理程式 (Bootmgr) 會從磁碟區中讀取加密的 VMK,並要求 TPM 將它解除密封。唯有當所有測量結果都與密封的 VMK 一樣時 (包括選用的 PIN),TPM 才能順利將 VMK 解密。

您 可以將此配置想像成一個驗證鏈,即開機程序中的每一個元件都會向 TPM 描述下一個元件。唯有當所有描述都符合其原始描述時,TPM 才會洩露它的秘密。因此,即使磁碟被移到另一個系統中、使用不同的作業系統開機,或開機磁碟區上的未加密檔案可能洩漏時,BitLocker 也會保護加密的資料。


程式碼完整性驗證

以 核心模式裝置驅動程式實作的惡意程式,包括 rootkits 在內,會在與核心相同的特殊權限層級上執行,因此最難以識別和移除。這種惡意程式會修改核心和其他驅動程式的行為,使自己幾乎成了隱形。Windows Vista 核心模式程式碼的程式碼完整性功能,亦稱為核心模式程式碼簽署 (KMCS) 功能,只允許下載由特定憑證授權單位 (CA) 驗證過其資格的開發者所發佈並具備數位簽章的裝置驅動程式。根據預設,在 Windows Vista 64 位元系統上會強制實施 KMCS。

因 為憑證授權單位的服務需要收費,並且會執行基本背景檢查 (例如公司諮詢調查),因此要產生在 64 位元 Windows Vista 上執行的匿名核心模式惡意軟體難上加難。此外,有更多機制可以在萬一惡意軟體瞞過驗證處理程序時留下線索,當受入侵的系統上發現到惡意軟體時,便可追蹤到 惡意軟體的作者。KMCS 也有次要用途,例如當懷疑驅動程式可能有問題而導致客戶系統毀損時,它會提供 Windows Online Crash Analysis 小組聯絡資訊,還有它會解除鎖定高畫質多媒體內容,這點我將會在稍後說明。

KMCS 使用 Windows 已運用了十年以上的公開金鑰加密技術,並要求核心模式程式碼要包含由信任的憑證授權單位之一產生的數位簽章。如果發行者送出驅動程式給 Microsoft Windows Hardware Quality Laboratory (WHQL),且該驅動程式通過可靠性測試,則 Microsoft 即成為簽署程式碼的憑證授權單位。大部分發行者會透過 WHQL 取得簽章,但是當驅動程式沒有 WHQL 測試程式、發行者不想將驅動程式送至 WHQL 測試,或該驅動程式是在系統啟動初期就載入的開機啟動驅動程式時,發行者就必須自行簽署程式碼。若要這麼做,發行者必須先從 Microsoft 認定為可信任的核心模式程式碼簽署授權單位,取得程式碼簽署憑證。然後作者需要以數位方式雜湊程式碼,並以私密金鑰將它加密後簽署雜湊,然後在程式碼中加 入憑證和加密雜湊。

當驅動程式試圖載入時,Windows 會使用儲存在憑證中的公開金鑰,將程式碼包含的雜湊解密,然後驗證該雜湊是否符合程式碼包含的雜湊。憑證的真實性也是以相同方式檢查,但是會使用 Windows 包含的憑證授權單位公開金鑰。

Windows 也會檢查相關聯的憑證鏈,最高達到內嵌於 Windows 開機載入程式和作業系統核心的根憑證授權單位之一。請勿嘗試在實際執行的系統上載入未簽署的 64 位元驅動程式,因為 64 位元 Windows Vista 的作法與 Plug and Play Manager 不同,不會在載入的驅動程式沒有可確認它已通過 WQHL 測試的簽章時顯示警告對話方塊,而是每當它阻擋未簽署的驅動程式載入時,只會直接在幕後自動將事件寫入程式碼完整性應用程式事件記錄檔,如 [圖 5] 所顯示。32 位元 Windows Vista 也會檢查驅動程式簽章,但允許未簽署的驅動程式載入。這是因為阻擋這些驅動程式會造成 Windows XP 系統無法升級,這些系統需要當初已載入至 Windows XP 的驅動程式,而且也才能支援目前只有 Windows XP 驅動程式的硬體。不過,當 32 位元 Windows Vista 載入未簽署的驅動程式時,也會將事件寫入程式碼完整性事件記錄檔中。

















圖 5
嘗試載入未簽署之驅動程式的事件 (Click the image for a larger view)

由於程式碼的簽署一般是用來標示程式碼為已通過嚴格測試的正式版,所以發行者通常不會想要簽署測試程式碼。因此,Windows Vista 包含一種測試簽署模式,您可以利用 Bcdedit 工具 (描述於我在 2007 年 3 月發佈的 TechNet Magazine 文章) 來啟用及停用此模式,此工具會載入以內部憑證授權單位產生的測試憑證數位簽署過的核心模式驅動程式。此模式是給程式設計師在開發程式碼時使用的。當 Windows 處於此模式時,它會在桌面上顯示記號,如 [圖 6] 所示。





圖 6 Windows Vista 測試簽署模式




受保護的處理程序

新 一代多媒體內容,如 HD-DVD、BluRay 和進階存取內容系統 (Advanced Access Content System,AACS) 授權的其他格式,在未來幾年會變得更為普遍。Windows Vista 包含一些統稱為受保護媒體路徑 (Protected Media Path,PMP) 的技術,AACS 標準需要這些技術才能播放此種內容。PMP 包括受保護使用者模式音訊 (Protected User-Mode Audio,PUMA) 和受保護視訊路徑 (Protected Video Path,PVP),它們共同提供音訊和視訊驅動程式以及媒體播放應用程式的機制,以防止未授權軟體或硬體擷取高畫質內容。

PUMA 和 PVP 定義音訊和視訊播放程式、裝置驅動程式及硬體專用的介面和支援,但 PMP 也仰賴 Windows Vista 引進的一般核心機制,稱為受保護的處理程序。受保護的處理程序是以標準 Windows 處理程序建構為基礎,此建構會封裝執行中的可執行檔映像、它的 DLL、安全性內容 (用來執行此處理程序的帳戶和其安全性特殊權限) 及在處理程序內執行程式碼但會防止特定存取類型的執行緒。

標 準處理程序會實作一個存取控制模型,以提供處理程序的擁有者和具有偵錯程式特殊權限的系統管理帳戶完整存取權。完整存取權可讓使用者檢視及修改處理程序的 位址空間,包括對應至處理程序的程式碼和資料。使用者也可以將執行緒插入至處理程序。這些存取類型與 PMP 的需求並不一致,因為它們允許未授權的程式碼存取高畫質內容,以及儲存在播放此內容之處理程序中的數位版權管理 (Digital Rights Management,DRM) 金鑰。

受保護的處理程序會限 制存取範圍,僅允許一組有限的資訊介面和處理程序管理介面,包括查詢處理程序的映像名稱及終止或暫停處理程序。但是核心使受保護的處理程序的診斷資訊可透 過一般處理程序查詢功能取得,這些查詢功能會傳回關於系統上所有處理程序的資料,因此並不需要直接存取處理程序。只有其他受保護的處理程序才能夠存取媒 體,以防媒體受到危害。

此外,為了防止造成內部危害,所有載入 至受保護處理程序的可執行檔程式碼,包括可執行檔映像和 DLL 在內,都必須由具有受保護環境 (PE) 旗標的 Microsoft (WHQL) 簽章,如果是音訊轉碼器,則必須由具有來自 Microsoft 之 DRM 簽署憑證的開發人員簽章才行。由於核心模式程式碼可取得任何處理程序的完整存取權,包括受保護的處理程序在內,且 32 位元 Windows 允許未簽署之核心模式程式碼的載入,所以,核心會提供 API 給受保護的處理程序,以查詢核心模式環境的「潔淨度」,唯有未載入未簽署的程式碼時,它才會利用查詢結果將優質內容解除鎖定。


識別受保護的處理程序

目 前沒有可以特別識別受保護處理程序的 API,但您可以根據可用的有限資訊以及即使從系統管理帳戶也無法對它們進行偵錯的方式,進行間接識別。Audio Device Graph Isolation 處理程序 (%Systemroot%\System32\Audiodg.exe) 是用來播放以 Content Scramble System (CSS) 編碼的 DVD,它在 [工作管理員] 窗格中可識別為受保護的處理程序,這是因為 [工作管理員] 無法取得它的命令行、虛擬化及資料執行防止狀態,即使是以系統管理權限執行也一樣。





在 [工作管理員] 中檢視 audiodg 受保護處理程序 (Click the image for a larger view)


位址空間隨機載入

儘管有資料執行防止和增強型編譯器錯誤檢查之類的功能,惡意軟體作者仍然繼續找到緩衝區溢位弱點,讓他們能夠感染各種網路處理程序,例如 Internet Explorer®、Windows 服務及協力廠商應用程式,而得以入侵系統。不過,一旦他們感染了處理程序之後,就必須使用 Windows API 完成其終極目標,亦即讀取使用者資料,或修改使用者或系統設定來建立永久身分。

連 接應用程式與 DLL 匯出的 API 進入點,通常是由作業系統載入程式進行處理,但是此類型的惡意軟體病毒將無法利用載入程式的服務。舊版的 Windows 上並無法避免惡意軟體造成問題,因為不論是哪一版的 Windows,系統可執行檔映像和 DLL 一律載入至相同位置,因此惡意軟體可以輕鬆假設 API 是位於固定位址。

Windows Vista 位址空間隨機載入 (ASLR) 功能,會使惡意軟體無法得知 API 的位置,因為每次系統開機時,會將系統 DLL 和可執行檔載入至不同的位置。在開機程序初期,記憶體管理員會從使用者模式位址空間頂端的 16MB 區域中的 256 個 64KB 對齊位址之一的偏差,挑選隨機的 DLL 映像載入。隨著映像標頭具有新動態重新定位旗標的 DLL 載入到處理程序中,記憶體管理員會從映像載入偏差位址開始往下,將它們封裝到記憶體中。

已設定旗標的可執行檔也會採取類似的處理方式,在其映像標頭所儲存的基本載入位址的 16MB 內的一個隨機 64KB 對齊點載入。此外,如果給定的 DLL 或可執行檔被所有使用它的處理程序卸載之後又再度載入,記憶體管理員會重新選取一個隨機位置來載入。[圖 7] 顯示 32 位元 Windows Vista 系統的範例位址空間配置,其中包含會由 ASLR 挑選映像載入偏差和可執行檔載入位址的區域。















圖 7
ASLR 對可執行檔和 DLL 載入位址的影響 (Click the image for a larger view)

唯有具有動態重新定位旗標的映像,包括所有 Windows Vista DLL 和可執行檔在內,才會重新定位,因為如果移動舊版映像會導致內部錯誤,畢竟開發人員對於其映像載入位置當初有固定的假設。Visual Studio® 2005 SP1 新增了設定旗標的支援,使協力廠商開發人員也可以充分利用 ASLR。

將 DLL 載入位址隨機化為 256 個位置之一,雖然不能完全杜絕惡意軟體猜出 API 的正確位置,但是可以嚴重妨礙網路蠕蟲的傳播速度,並且可防止只會嘗試感染系統一次之惡意軟體的運作。此外,ASLR 的重新定位策略還有第二項優點,即位址空間比舊版的 Windows 更緊密壓縮,這不僅可為連續記憶體配置製造更大的可用記憶體區域,還可以減少記憶體管理員為追蹤位址空間配置而配置的分頁表數目,並且可使轉譯對應緩衝區 (Translation Lookaside Buffer,TLB) 的失誤減至最少。


服務安全性的改進

Windows 服務是惡意軟體的理想目標。因為許多服務都提供透過網路存取的功能,這可能使系統曝露在遠端存取的攻擊之下,而且大部分服務是以比標準使用者帳戶更高的特 殊權限來執行,萬一它們受到惡意軟體入侵,將提供機會提高本機系統的特殊權限。因此,Windows 開始隨著 Windows XP SP2 所做的變更演進,將指派給服務的特殊權限及存取權減少為只限於其角色需要的那些權限。例如,Windows XP SP2 推出的本機服務和網路服務帳戶,如今只包括本機系統帳戶的部分特殊權限子集 (先前的服務一律以此帳戶的完整權限執行)。這可在萬一攻擊者破解服務時,將可運用的存取權減至最少。


見識 ASLR 的運作

您可以在兩個不同的開機工作階段中,使用像 Process Explorer from Sysinternals 之類的工具來比較處理程序的 DLL 載入位址,如此即可見識到 ASLR 的作用。這兩個擷取畫面是從兩個不同的工作階段產生的,第一個是 Ntdll.dll 載入至檔案總管的位址 0x77A30000,後來則載入至位址 0x77750000。




ntdll.dll 載入不同的基本位址 (Click the image for a larger view)


在前一篇文章中,我描述過服務如何與使用者帳戶分開,在自己的工作階段中執行,但 Windows Vista 更擴大使用其最低權限原則,進一步減少指派給大部分服務的檔案、登錄機碼和防火牆連接埠的特殊權限和存取權。Windows Vista 定義了一個新的群組帳戶,稱為服務安全性識別元 (SID),每一項服務都會有唯一的 SID。服務可對其資源設定權限,以限定只有它的服務 SID 有存取權,如此一來,當服務被破解時,可防止以相同使用者帳戶執行的其他服務也具有存取權。使用 sc showsid 命令並在其後提供服務名稱,即可看到服務的 SID,如 [圖 8] 所示。







圖 8 檢視服務的 SID (Click the image for a larger view)

服務 SID 可保護對特定服務所擁有之資源的存取權,但根據預設,服務對於執行它們的使用者帳戶可存取的所有物件仍然具有存取權。例如,以本機服務帳戶執行的服務,可 能無法存取在不同處理程序中,以本機服務執行的另一個服務所建立的資源,該服務已使用參照服務 ID 的權限保護其物件,不過,它仍然可以讀取及寫入本機服務 (以及本機服務所屬的任何群組,如服務群組) 具有權限的任何物件。

因 此,Windows Vista 引進了一個新的限制服務類型,叫做寫入限制服務,它只允許服務對於可存取其服務 SID、Everyone 群組和已指派給登入工作階段之 SID 的物件具有寫入權。為了達成此目的,它使用限制的 SID,這是曾經在 Windows 2000 引進的 SID 類型。當開啟物件的處理程序屬於寫入限制的服務時,存取檢查演算法就會變更,因此無法使用尚未以限制和無限制形式指派給處理程序的 SID 來授與處理程序對物件的寫入權。您可以使用下列命令來了解服務是否受限制:

sc qsidtype [service]

此外還有另一項變更,可以使服務輕易防止以 相同帳戶執行的其他服務,存取前者所建立的物件。在舊版的 Windows 中,物件的建立者也是物件的擁有者,擁有者有能力讀取及變更其物件的權限,讓他們對其擁有之物件具有完整存取權。Windows Vista 則引進了新的擁有者權限 SID,此 SID 若存在於物件的權限中,可限制擁有者對其擁有之物件的存取權,甚至移除設定及查詢權限的權利。

Windows Vista 中的服務安全性模式的另一項增強功能,可讓服務開發人員確實指定服務在系統上註冊時需要操作的安全性特殊權限。例如,如果服務需要產生稽核事件,它可以列出稽核特殊權限。

當 服務控制管理員啟動一項處理程序來裝載一項或多項 Windows 服務時,會為處理程序建立只包含服務在處理程序中所需之特殊權限的安全性權杖 (列出處理程序使用者帳戶、群組成員資格和安全性特殊權限的核心物件)。如果服務指定的特殊權限無法供執行該服務的帳戶使用,則該服務將無法啟動。例如, 在本機服務帳戶處理程序中執行的任何服務,如果都不需要偵錯程式特殊權限,服務控制管理員就會從處理程序的安全性權杖中移除該特殊權限。因此,如果服務處 理程序受到破解,惡意程式碼將無法利用在處理程序中執行的服務未具備的特殊權限。sc qprivs 命令可報告服務所要求的特殊權限。


結論

以 下是我對這三篇 Windows Vista 核心變更文章的總結。我必須先聲明,還有一些我並未討論到或提及的功能和改進項目,例如適用於應用程式開發人員的新工作者執行緒集區、新的同步處理機制 (例如共用讀取器/寫入器鎖定機制)、服務執行緒標記、對線上 NTFS 磁碟檢查和磁碟區調整大小功能的支援,以及一個叫做進階本機程序呼叫 (Advanced Local Procedure Call,ALPC) 的新核心 IPC 機制。如需這些功能和其他功能的詳細資訊,請參閱下一期的 Windows Internals (預定將在 2007 年年底之前發行)。




檢視寫入限制服務

Windows Vista 上只有一項服務裝載處理程序會裝載限制的服務,您可以使用像 Process Explorer 之類的處理程序檢視工具來識別它,其中會含有下列命令行:

svchost -k LocalServiceNoNetwork

設定為在此處理程序中執行的服務包括:基礎篩選引擎、診斷原則服務、Windows 防火牆、效能記錄及警示,以及 Windows Media® Center Service Starter。

此 畫面顯示基礎篩選引擎服務 SID 的文字形式 (NT SERVICE\BFE),第一次列出時含有限制旗標,再次列出時沒有限制旗標,因此,處理程序對該帳戶可存取的資源具有存取權。不過,對於本機服務帳戶 一般可存取的其他物件,它不一定有存取權。例如,由於 NT AUTHORITY\SERVICE 帳戶沒有出現在具有限制旗標的處理程序權杖中,所以該處理程序將無法修改只授與寫入權給該帳戶,而不授與寫入權給權杖中含有限制旗標的其他帳戶的物件。

在此處理程序中執行的服務也有特殊權限的限制,因為列示在內容對話方塊底端的特殊權限,僅為本機服務帳戶可用之特殊權限的子集。



























服務的 SID 旗標
(Click the image for a larger view)


Related Articles From TechNet Magazine:

深入探索 Windows Vista 核心:第二篇

http://technet.microsoft.com/zh-tw/magazine/2007.03.vistakernel.aspx

‧深入探索 Windows Vista 核心:第二篇

At a Glance:
* 記憶體管理
* 啟動和關機
* 電源管理


上個月,在此三篇一系列文章的第一篇內,我探討了處理程序和 I/O 方面的 Windows Vista 核心增強功能。

這次我要討論 Windows Vista 記憶體管理方式的加強,以及系統啟動、關機和電源管理的主要改進 (第一篇)。

每一版的 Windows® 都會改進延展性和效能,Windows Vista™ 也不例外。Windows Vista 記憶體管理員包括許多的增強功能,例如更廣泛地使用鎖定-釋放同步處理技巧、更細微的鎖定、更緊密的資料結構封裝、更大的分頁 I/O、支援最新 GPU 記憶體架構,以及更有效地使用硬體轉譯對應緩衝區。此外,Windows Vista 記憶體管理現在可針對不同工作量的需求,提供動態位址空間配置。

Windows Vista 作業系統中首次引進使用新技術的四種效能增強功能:SuperFetch、ReadyBoost、ReadyBoot 及 ReadyDrive。我會在本文後面詳細討論這些功能。


動態核心位址空間

Windows 和在 Windows 上執行的應用程式一直為 32 位元處理器的位址空間限制所苦。Windows 核心預設的限制是 2GB,或者 32 位元虛擬位址總空間的一半,另一半則保留給目前在 CPU 上執行執行緒的處理程序使用。在核心所能使用的一半空間中,核心必須對應自己本身、裝置驅動程式、檔案系統快取、核心堆疊、每一工作階段程式碼資料結構, 以及裝置驅動程式所配置的非分頁 (鎖定實體記憶體) 和分頁緩衝區。在 Windows Vista 之前,記憶體管理員在開機時會決定指派多少位址空間給這些不同的用途,但是這種缺乏彈性的方法有時會造成某個區域已用盡,而其他區域仍有大量的可用空間。 某個區域耗盡會造成應用程式失敗,並使得裝置驅動程式無法完成 I/O 操作。

在 32 位元 Windows Vista 中,記憶體管理員會動態地管理核心的位址空間,隨著工作量需求的需要配置及解除配置空間給各種用途。因此,當裝置驅動程式要求增加時,可以增加用於儲存分 頁緩衝區的虛擬記憶體數量,而當驅動程式釋放記憶體時,則可以減少其數量。所以 Windows Vista 將可以處理更多的工作量,同樣地,即將推出的 Windows Server® (代號 "Longhorn") 也能夠擴充,以處理更多的同時執行終端機伺服器使用者。

當然,在 64 位元 Windows Vista 系統上,位址空間限制目前並未造成真正的限制,因為都已設定到其最大值,所以不需要特別處理。


記憶體優先順序

Windows Vista 不只增加了 I/O 優先順序 (我在第一篇已介紹過),也實作了記憶體優先順序。要了解 Windows 如何使用記憶體優先順序,必須先了解記憶體管理員如何實作其記憶體快取 (稱為待命清單)。在 Windows Vista 之前的所有 Windows 版本中,當系統收回處理程序所擁有的實體分頁 (大小通常是 4KB) 時,記憶體管理員通常會將分頁放在待命清單的最後面。如果處理程序想要再次存取分頁,記憶體管理員就會從待命清單中取出分頁,然後重新指派給處理程序。如 果處理程序想要使用新的實體記憶體分頁,但是沒有可用記憶體可使用時,記憶體管理員就會將待命清單前面的分頁指派給處理程序。這種配置實質上會將待命中的 所有分頁同等處理,只使用分頁放入清單中的時間將分頁排序。

在 Windows Vista 中,每個記憶體分頁都有 0 到 7 範圍內的優先順序,而記憶體管理員也將待命清單分成八份清單,每份清單都儲存一個特定優先順序的分頁。當記憶體管理員想要從待命清單取出分頁時,會先從低 優先順序清單取出分頁。分頁的優先順序通常反映最先引起分頁配置之執行緒的優先順序 (如果分頁是共用的,則反映共用執行緒中最高的記憶體優先順序)。執行緒會從它所屬的處理程序繼承分頁優先順序值。記憶體管理員在預期處理程序的記憶體存 取需求時,會針對它從磁碟推測讀取之分頁,使用低優先順序。

根據預設,處理程序的分頁優先順序值為 5,但是應用程式和系統可以利用函數來變更處理程序與執行緒的分頁優先順序值。唯有全面了解分頁的相對優先順序 (這就是 SuperFetch 的角色),才能發揮記憶體優先順序的真正威力。


SuperFetch

記 憶體管理員的一項重大變更,就是其管理實體記憶體的方式。舊版 Windows 所使用的待命清單管理有兩個限制。第一,分頁的優先順序只依賴處理程序最近已發生的行為,並不會預期它們未來的記憶體需求。第二,優先順序使用的資料只限 於處理程序在任一特定時間點所擁有的分頁清單。這些缺點可能會造成「啟動後症候群」之類的狀況,就是您離開電腦一段時間,同時電腦上有需要大量記憶體的系 統應用程式在執行 (例如防毒軟體掃描或磁碟重組)。此應用程式會導致需要大量記憶體的活動,強制覆寫使用中應用程式原來存放在記憶體快取中的程式碼和資料。等到您回來時, 會發現效能已變差,因為應用程式必須向磁碟要求其資料和程式碼。

Windows XP 引進了預先擷取支援,根據以前的開機和應用程式啟動,執行大量磁碟 I/O 以預先載入包含它所預期之程式碼和檔案系統資料的記憶體,改進了開機和應用程式啟動效能。Windows Vista 的 SuperFetch 則有更大的改進。SuperFetch 是一種記憶體管理配置,利用歷史資訊和主動的記憶體管理,加強近來最少存取的方法。

SuperFetch 會在 %SystemRoot%\System32\Sysmain.dll 中實作,在服務主機處理程序 (%SystemRoot%\System32\Svchost.exe) 中以 Windows 服務執行。此配置依賴記憶體管理員的支援,以便擷取分頁使用歷程,並指示記憶體管理員從磁碟上的檔案,或從分頁檔案預先將資料和程式碼載入待命清單,並為 分頁指派優先順序。SuperFetch 服務實際上是將分頁追蹤延伸至資料和程式碼,這些資料和程式碼曾經放在記憶體中,但是記憶體管理員已重新使用記憶體以提供空間給新的資料和程式碼。它會將 此資訊儲存在 %SystemRoot%\Prefetch 目錄下副檔名為 .db 的狀況檔案中,同時儲存的還有用於將應用程式啟動最佳化的標準預先擷取檔案。SuperFetch 會利用對記憶體使用模式的了解,在實體記憶體可用時預先載入資料和程式碼。

只要記憶體變成可用 (例如,當應用程式結束或釋放記憶體時),SuperFetch 就會要求記憶體管理員擷取最近收回的資料和程式碼。這是以「非常低」優先順序 I/O 的速度執行,每秒只有幾個分頁,以免預先載入影響使用者或其他使用中應用程式。因此,您若是離開電腦去吃午餐,而需要大量記憶體的背景工作在您離開時造成 您使用中應用程式的程式碼和資料被收回,SuperFetch 通常可在您回來之前將全部或大部分的程式碼和資料放回記憶體中。SuperFetch 也包含休眠、待命、快速切換使用者 (FUS) 及應用程式啟動等特定的狀況支援。例如,當系統休眠時,SuperFetch 會將它 (根據以往的休眠) 預期恢復執行時要存取的資料和程式碼,儲存在休眠檔案中。相對地,當您恢復執行 Windows XP 時,若參照到先前快取的資料,則需從磁碟重新讀取。

有關 SuperFetch 如何影響可用記憶體的簡介,請參閱以下「注意 SuperFetch」說明。


注意 SuperFetch

您使用 Windows Vista 系統一段時間後,就會看到工作管理員之 [效能] 頁面上的可用實體記憶體計數器顯示低數量。這是因為 SuperFetch 和標準 Windows 快取會使用所有可用的實體記憶體來快取磁碟資料。例如,當您首次開機時,如果立即執行工作管理員,應該會注意到隨著快取記憶體數量增加,可用記憶體值就會 跟著減少。或者,您若是執行記憶體需求極大的程式,然後結束程式 (任何會配置大量記憶體,然後再釋放記憶體的「RAM 最佳化程式」免費軟體都行),或者剛剛複製很大的檔案,隨著系統收回已配置的記憶體,[可用] 的數量會增加,而 [實體記憶體使用量] 圖形會下降。但是,SuperFetch 會隨著時間將先前強制從記憶體移出的資料重新填入快取中,因此 [快取] 數量會增加,而 [可用] 數量會減少。

Watching memory (Click the image for a larger view)


ReadyBoost

CPU 和記憶體的速度遠快於硬碟的速度,因此磁碟是常見的系統效能瓶頸。隨機磁碟 I/O 更是惡夢,因為磁碟頭搜尋時間大約是 10 毫秒,對現在 3GHz 的處理器而言是很漫長的時間。雖然 RAM 很適合快取磁碟資料,但是相對而言它很昂貴。不過,Flash 記憶體通常比較便宜,而且隨機讀取的速度最高可比一般硬碟快 10 倍。因此,Windows Vista 包含名為 ReadyBoost 的功能,這會在 Flash 記憶體存放裝置上,建立邏輯位置在記憶體和磁碟之間的中繼快取層,以利用 Flash 記憶體存放裝置的優勢。

ReadyBoost 包含一個在 %SystemRoot%\System32\Emdmgmt.dll 中實作的服務 (這會在服務主機處理程序中執行),以及一個磁碟區篩選器驅動程式 %SystemRoot%\System32\Drivers\Ecache.sys. (Emd 是外部記憶體裝置 (External Memory Device) 的縮寫,此名稱是 ReadyBoost 在開發過程中使用的名稱)。您將 USB 金鑰之類的 Flash 裝置插入至系統時,ReadyBoost 服務會檢查裝置以判斷其效能特性,並將其測試結果儲存在 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt 中,請參閱 [圖 1]。

Figure 1 ReadyBoost device test results in the registry

如果您尚未使用快取的裝置,而且新裝置的大小介於 256MB 和 32GB 之間、隨機 4KB 讀取的傳送速率可達 2.5MB/s 或更快、隨機 512KB 寫入的傳送速率達到 1.75MB/s 或更快,ReadyBoost 就會詢問您是否要固定使用最多 4GB 的儲存體做為磁碟快取 (雖然 ReadyBoost 可以使用 NTFS,不過它將最大快取大小限制在 4GB,以配合 FAT32 限制)。您如果同意,服務就會在裝置的根目錄建立名為 ReadyBoost.sfcache 的快取檔案,並要求 SuperFetch 在背景填入快取。

在 ReadyBoost 服務初始化快取之後,Ecache.sys 裝置驅動程式會攔截對本機硬碟磁碟區 (例如 C:\) 的所有讀取和寫入,並將寫入的任何資料複製到服務所建立的快取檔案中。Ecache.sys 會壓縮資料,而且壓縮比率通常可達到 2:1,因此 4GB 的快取檔案通常會包含 8GB 的資料。驅動程式使用先進加密標準 (AES) 加密,配合隨機產生的每一開機工作階段金鑰將其寫入的每一個區塊加密,以保證裝置若是從系統移除時的資料隱私權。

ReadyBoost 看到可利用快取滿足的隨機讀取時,會從快取提供服務,但是因為硬碟的循序讀取存取優於 Flash 記憶體,所以即使快取中有資料,它也會讓屬於循序存取模式的讀取直接送往磁碟。


ReadyBoot

如 果系統的記憶體小於 512MB,Windows Vista 就使用與 Windows XP 相同的開機預先擷取,但是如果系統有 700MB 或更多的 RAM,它則會使用 RAM 快取將開機程序最佳化。快取的大小會視可用的 RAM 總數量而定,不過已大到足夠建立合理的快取,同時還可讓系統擁有順暢開機所需的記憶體。

在每次開機之後, ReadyBoost 服務 (與實作 ReadyBoost 功能相同的服務,剛剛已介紹過) 會使用閒置 CPU 時間,來計算下次開機的開機快取計劃。它會分析前五次開機的檔案追蹤資訊,並確認先前存取過哪些檔案,以及這些檔案在磁碟上的位置。它會將處理過的追蹤儲 存到 %SystemRoot%\Prefetch\Readyboot 底下的 .fx 檔案中,並將快取計劃儲存在 HKLM\System\CurrentControlSet\Services\Ecache\Parameters 底下,針對追蹤參考的內部磁碟區命名的 REG_BINARY 值中。

快取是由實作 ReadyBoost 快取的同一個裝置驅動程式 (Ecache.sys) 實作,但是快取的填入則是由 ReadyBoost 服務在系統開機時主導。雖然開機快取也像 ReadyBoost 快取一樣會壓縮,不過 ReadyBoost 和 ReadyBoot 快取之間的另一項差異是,當處於 ReadyBoot 模式時,除了 ReadyBoost 服務的更新之外,快取並不會變更以反映開機過程中讀取或寫入的資料。ReadyBoost 服務會在開機開始之後 90 秒刪除快取 (如果有其他記憶體需求則更快),並將快取的統計資料記錄在 HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats 中,如 [圖 2] 所示。Microsoft 效能測試顯示,ReadyBoot 的效能比舊版 Windows XP 預先擷取程式改進了 20%。

Figure 2 ReadyBoot Performance statistics (Click the image for a larger view)


ReadyDrive

ReadyDrive 是 Windows Vista 中利用新的交互式硬碟機 (稱為 H-HDD) 的功能。H-HDD 是具有內嵌靜態 Flash 記憶體 (也稱為 NVRAM) 的磁碟。標準的 H-HDD 包含介於 50MB 到 512MB 之間的快取,不過 Windows Vista 的快取限制是 2TB。

Windows Vista 會使用 ATA-8 命令,來定義要保存在 Flash 記憶體中的磁碟資料。例如,Windows Vista 會在系統關機時將開機資料儲存到快取中,以允許更快的重新啟動。它也會在系統休眠時將部分休眠檔案資料儲存在快取中,以加快後續的恢復執行。由於即使當磁 碟處於關閉狀態時,快取依然啟用,因此 Windows 可以使用 Flash 記憶體做為磁碟寫入快取,這可避免磁碟在系統使用電池電力執行時啟動。保持磁碟的磁針關閉可以節省磁碟機在正常使用下所消耗的大部分電力。


開機設定資料庫

Windows Vista 增強了啟動和關機的許多層面。採用開機設定資料庫 (BCD) 儲存系統和作業系統啟動設定、新的系統啟動程序的流程和組織、新的登入架構,以及支援延遲自動啟動服務,這些都改進了開機。Windows Vista 的關機變更包括 Windows 服務的預先關閉通知、Windows 服務關閉順序,以及 OS 管理電源狀態轉換方式的重大變更。

啟 動程序最明顯的變更就是系統磁碟區的根目錄中沒有 Boot.ini。這是因為在舊版 Windows 中儲存在 Boot.ini 文字檔案中的開機設定,現在都儲存在 BCD 中。Windows Vista 使用 BCD 的原因之一,是它合併了 Windows 所支援的兩個目前開機架構:主開機記錄 (MBR) 和可延伸韌體介面 (EFI)。MBR 通常是由 x86 和 x64 桌上型系統使用,而 EFI 則是由 Itanium 系統使用 (不過桌上型 PC 可能很快就會包含 EFI 支援)。BCD 會摘要韌體,也擁有比 Boot.ini 好的其他優點,例如支援 Unicode 字串和替代的預先開機可執行檔。

BCD 實際上是儲存在磁碟上的登錄 Hive 中,此 Hive 會載入 Windows 登錄以便透過登錄 API 存取。在 PC 上,Windows 會將它儲存在系統磁碟區的 \Boot\Bcd 中。在 EFI 系統上,則是儲存在 EFI 系統磁碟分割中。Hive 載入之後,會在 HKLM\Bcd00000000 底下顯示,但是並未記載其內部格式,因此若要編輯,就需要使用 %SystemRoot%\System32\Bcdedit.exe 之類的工具。也透過 Windows Management Instrumentation (WMI) 提供操作 BCD 之指令碼和自訂編輯器的介面,而且您可以使用 Windows 系統設定公用程式 (%SystemRoot%\System32\Msconfig.exe) 編輯或加入基本參數,例如核心偵錯選項。

BCD 會將全平台的開機設定 (例如預設 OS 選取和開機功能表逾時) 與 OS 特定的設定 (例如 OS 開機選項和開機載入器的路徑) 分開。例如,[圖 3] 顯示當您執行 Bcdedit,但是未加上命令列選項時,它會在輸出的最前面區段中,顯示 Windows 開機管理程式 (Windows Boot Manager) 的平台設定,隨後則包括 Windows 開機載入器 (Windows Boot Loader) 區段的 OS 特定設定。

Figure 3 Settings displayed in BCDEdit (Click the image for a larger view)

當您將 Windows Vista 安裝開機時,此新配置會將以往舊版 Windows 系統上由作業系統載入器 (Ntldr) 所處理的工作分割到兩個不同的可執行檔中:\BootMgr 和 %SystemRoot%\System32\Winload.exe。Bootmgr 會讀取 BCD 並顯示 OS 開機功能表,而 Winload.exe 則會處理作業系統載入。如果您是執行正常開機,Winload.exe 就會載入開機啟動裝置驅動程式和核心作業系統檔案,包括 Ntoskrnl.exe,並會將控制權轉移給作業系統;如果系統是從休眠狀態恢復執行,則它會執行 %SystemRoot%\System32\Winresume.exe,將休眠資料載入記憶體中並恢復執行 OS。

Bootmgr 也包含其他預先開機可執行檔的支援。Windows Vista 預先設定了 Windows 記憶體診斷 (\Boot\Memtest.exe) 做為檢查 RAM 健康狀態的選項,但是協力廠商可能加入自己的預先開機可執行檔,做為將在 Bootmgr 開機功能表中顯示的選項。


啟動程序

在 舊版的 Windows 中,各種系統處理程序之間的關係並不是很清楚。例如,在系統開機時,互動式登入管理程式 (%SystemRoot%\System32\Winlogon.exe) 會啟動本機安全性授權子系統服務 (Lsass.exe) 和服務控制管理員 (Services.exe)。此外,Windows 會使用稱為「工作階段」的名稱空間容器,來隔離在不同登入工作階段中執行的處理程序。但是在 Windows Vista 之前,使用者是登入主控台共用工作階段 0 (系統處理程序所使用的工作階段),這造成潛在的安全性問題。例如,當時有一個編寫不良的 Windows 服務就是在工作階段 0 執行,且該服務會在互動式主控台上顯示使用者介面視窗,使惡意程式有機可乘 (可能透過毀壞攻擊等技巧攻擊視窗並取得系統管理員特殊權限),而造成安全性的問題。

為了處理這些問題, 許多系統處理程序都已針對 Windows Vista 重新設計。如同舊版的 Windows 一樣,工作階段管理員 (Smss.exe) 會是開機過程中所建立的第一個使用者模式處理程序,但是在 Windows Vista 中,工作階段管理員會啟動本身的第二個例項,以設定工作階段 0 (完全由系統處理程序專用)。工作階段 0 的工作階段管理員處理程序會啟動 Windows 啟動應用程式 (Wininit.exe)、工作階段 0 的 Windows 子系統處理程序 (Csrss.exe),然後就會結束。Windows 啟動應用程式會繼續啟動服務控制管理員、本機安全性授權子系統,以及一個新的處理程序 (本機工作階段管理員 (Lsm.exe)),此處理程序負責管理電腦的終端機伺服器連線。

使用者登入系統時,初始的工作階段管 理員會建立其本身的新例項,以設定新工作階段。新的 Smss.exe 處理程序會為新的工作階段啟動 Windows 子系統處理程序和 Winlogon 處理程序。讓主要的工作階段管理員使用本身的複本來初始化新工作階段並不會為用戶端系統提供任何好處,但是在做為終端機伺服器的 Windows Server "Longhorn" 系統上,多個複本可以同時執行,以允許多位使用者更快的登入。

有 了此新的架構,系統處理程序 (包括 Windows 服務) 都隔離在工作階段 0 中。如果在工作階段 0 執行的 Windows 服務顯示使用者介面,互動式服務偵測服務 (%SystemRoot%\System32\UI0Detect.exe) 就會在使用者的安全性內容中啟動本身的一個例項,以通知任何已登入的系統管理員,並顯示 [圖 4] 所示的訊息。如果使用者選取 [顯示訊息] 按鈕,服務就會將桌面切換至 Windows 服務桌面,使用者可以在此和服務的使用者介面互動,然後切換回其自己的桌面。如需啟動時執行之作業的詳細資訊,請參閱資訊看板<檢視啟動程序的關係>。


Figure 4 Service has displayed a window (Click the image for a larger view)

檢視啟動程序的關係

您可以使用 Sysinternals (microsoft.com/technet/sysinternals) 的 Process Explorer,來檢視 Windows Vista 的處理程序啟動樹狀目錄。

擷 取畫面包含 [Session] 資料行,您可以透過 Process Explorer 的資料行對話方塊加入此資料行。反白的處理程序是初始的 Smss.exe。其下面是工作階段 0 Csrss.exe 和 Wininit.exe,這兩者都會靠左對齊,因為其父系處理程序 (也就是設定工作階段 0 之 Smss.exe 的例項) 已經結束。Wininit 的三個子系為 Services.exe、Lsass.exe 和 Lsm.exe。

Process Explorer 會將一組處理程序識別為在工作階段 1 中執行,而這也是我透過遠端桌面連線登入的工作階段。Process Explorer 會以藍色反白顯示使用和其本身相同之帳戶執行的處理程序。最後,會初始化工作階段 2 以準備讓使用者登入主控台,並建立新的登入工作階段。Winlogon 就是在這個工作階段中執行,並使用 LogonUI 要求新的主控台使用者「按 Ctrl+Alt+DELETE 以登入」,而 Logonui.exe 也會在此要求使用者提供認證。

Startup process and session information (Click the image for a larger view)

認證提供者

Windows Vista 連登入架構都變更了。舊版的 Windows 中,Winlogon 處理程序會載入登錄中指定的 Graphical Identification and Authentication (GINA) DLL,以顯示登入 UI,要求使用者提供認證。很可惜,GINA 模型有諸多的限制,包括只能設定一個 GINA、協力廠商很難撰寫完整的 GINA,以及使用非標準使用者介面的自訂 GINA 會變更 Windows 的使用者經驗。

Windows Vista 使用新的認證提供者架構來代替 GINA。Winlogon 啟動另一個處理程序,亦即登入使用者介面主機 (Logon User Interface Host (Logonui.exe)),它會載入在 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers 中設定的認證提供者。Logonui 可以同時裝載多個認證提供者;事實上,Windows Vista 附有互動式 (Authui.dll) 和智慧卡 (Smart-cardcredentialprovider.dll) 提供者。為了保證一致的使用者經驗,LogonUI 會管理向使用者顯示的使用者介面,不過它也允許認證提供者指定文字、圖示和編輯控制項之類的自訂元素。


延遲自動啟動服務

如 果您曾經在 Windows 系統啟動後立即登入系統,很可能遇到過必須經過一段延遲,您的桌面才會完全設定好,您也才能與 Shell 和您所啟動的任何應用程式互動。在您登入時,服務控制管理員會啟動許多設定為自動啟動 (因此會在開機時啟用) 的 Windows 服務。許多服務的初始化作業,都需要大量使用 CPU 和磁碟資源,這會和您的登入活動競爭資源。為了解決這個問題,Windows Vista 引進新的服務啟動類型,稱為延遲自動啟動,不需要在 Windows 開機後立即作用的服務可以使用此功能。

服 務控制管理員會在自動啟動服務完成啟動之後,再啟動設定為延遲自動啟動的服務,並將其初始執行緒優先順序設定為 THREAD_PRIORITY_LOWEST。此優先順序層級會使執行緒執行的所有磁碟 I/O 成為「非常低」I/O 優先順序。服務完成初始化之後,服務控制管理員就會將其優先順序設定為標準。延遲啟動、低 CPU 和記憶體優先順序,以及背景磁碟優先順序的組合,可大為減少使用者登入時的負面影響。許多 Windows 服務,包括背景智慧型傳送、Windows Update 用戶端及 Windows Media® Center,都使用新的啟動類型,以協助改善開機後的登入效能。


關機

困 擾 Windows 服務撰寫人員的一個問題,就是在 Windows 關機過程中,預設最多只有 20 秒的時間執行清除。Windows Vista 之前的 Windows 版本並未支援等待所有服務都結束的正常關機,因為設計不良的服務可能會無限期地阻礙關機。某些服務 (例如具有網路相關關機作業或必須將大量資料儲存至磁碟的服務) 可能需要較多的時間,因此 Windows Vista 允許服務要求預先關閉通知。

Windows Vista 關機時,服務控制管理員會先通知那些要求預先關閉通知的服務。它會無時間限制地等候這些服務結束,但是如果服務有錯誤,且並未回應查詢,服務控制管理員就 會放棄,並在三分鐘後結束。等到所有服務都結束,或者等待時間已過期,服務控制管理員就會針對其餘服務繼續執行舊式服務關閉。群組原則和 Windows Update 服務會在新的 Windows Vista 安裝中登錄預先關閉通知。

群 組原則和 Windows Update 服務也會使用另一項 Windows Vista 服務功能:關閉順序。服務一直都可以指定啟動依存性,服務控制管理員會尊重這些依存性,以能夠滿足服務的順序來啟動服務,但是在 Windows Vista 之前,服務並無法指定關閉依存性。現在,登錄預先關閉通知的服務也可以將自己插入至儲存在 HKLM\System\CurrentControlSet\Control\PreshutdownOrder 的清單中,而服務控制管理員將根據服務的順序來關閉。如需這些服務的詳細資訊,請參閱資訊看板<識別延遲自動啟動和預先關閉服務>。


電源管理

睡眠和休眠是其他形式的關機,自從 Windows 2000 將電源管理引進 Windows NT® 系列的 Windows 作業系統後,驅動程式和應用程式中設計不良的電源管理就一直是行動電腦使用者的困擾。許多使用者都希望當他們在旅途中登機前蓋上膝上型電腦的蓋子時,系統 能夠進入暫停或休眠狀態,但是等他們到達目的地後,卻發現只是徒勞帶著一個發熱的箱子、電池已沒電,且資料已遺失。這是因為 Windows 一律會要求裝置驅動程式和應用程式同意變更電源狀態,而只要有一個驅動程式或應用程式沒有回應,都會妨礙轉換。

在 Windows Vista 中,核心的電源管理員一樣會通知驅動程式和應用程式電源狀態的變更,以便這些程式能準備好,但是它不會再要求同意。此外,電源管理員會等候 (最多 20 秒) 應用程式回應變更通知,而不是在舊版 Windows 中的等候兩分鐘。因此,Windows Vista 使用者可以更確定其系統會執行休眠和暫停。


接下來

前 面已提過,這是三篇一系列文章的第二篇。第一篇討論的是 Windows Vista 核心在 I/O 與處理程序方面的改進。本篇則探討了 Windows Vista 在記憶體管理、啟動和關機方面的增強功能。下一篇我會介紹可靠性和安全性方面的核心變更,為整個系列劃下句點。


識別延遲自動啟動和預先關閉服務

Windows Vista 更新了內建 SC 命令,以顯示設定為延遲自動啟動服務的服務:

Using SC to display start type (Click the image for a larger view)

可惜的是,SC 命令並不會報告已要求預先關閉通知的服務,不過您可以使用 Sysinternals 的 PsService 公用程式,以檢視服務是否接受預先關閉通知:

Viewing pre-shutdown status (Click the image for a larger view)

Related Articles From TechNet Magazine:


看起來清白的 GIF 圖檔成為惡意攻擊的主人

Innocent-Looking GIFs Host Malware Attacks
http://www.pcworld.com/article/id,133275-c,trojanhorses/article.html

Matthew Broersma, Techworld Fri Jun 22, 2007

根據安全研究者表示,駭客圈現正流通一種 PHP exploit,並將它埋入一個看起來無害的 GIF 圖檔中。

根據 SANS ISC 週四發出的公告表示,這個 exploit 至少在一個主要影像網站(image-hosting website)中的一個 GIF 檔裡面被發現。

"發現這樣一個檔案很有趣,不過也很嚇人,因為它看起來就如同一個正常的 GIF 檔,不過卻包含 script exploit," SANS ISC 的 Lorna Hutcheson 在公告中寫道。

這個 exploit,以 PHP 腳本語言撰寫,可能成為一種新危害,Hutcheson 表示。

"有趣的是,這個檔案本身包含一個完全合法的, 1x1 像素大小的 gif 影像在檔頭," 她寫道。"這是一種將 exploit 程式碼偷渡給其他人,而不會在經過網路安全工具時,爆出警告或是吸引注意的聰明方法。"

她也提出建議表示,該技術可被用來創造出 Remote File Inclusion(遠端檔案內含)式的攻擊,這種攻擊可以讓駭客們在其他看起來無害的網站中(譯註:如網路相簿、入口網站),執行他們自己的惡意程式。

真正隨機的亂數產生器上線

True random number generator goes online

http://pressesc.com/01184778212_qrbgs

Submitted by Vidura Panditaratne on Wed, 2007-07-18

一個「真正隨機的」亂數產生器已經上線了,那依賴無法預測的光子輻射之量子過程,提供學術界與科學社群免費使用真正隨機的亂數。

一群來自於克羅埃西亞(Croatia),Zagreb,Ruder Boskovic Institute (RBI) 的電腦科學家,開發並啟用 Quantum Random Bit Generator Service (QRBGS),其應用範圍橫跨各種領域,從先進的科學模擬、加密資料保護與安全應用,當然也包括虛擬娛樂 -- 例如線上賭博與電腦遊戲。

今日在大部分電腦中所找到的普通亂數產生器,都使用所謂的「虛擬隨機(pseudo-random)」亂數,那是經由各種演算法,從事先編譯好的龐大數字資料庫,其來源是用擲骰子之類的方法,挑選數字。

任何人,若能存取挑選虛擬隨機亂數所使用的資料庫,就能夠「精確」預測出下一個從這種產生器當中出現的數字。

不過,這個'Quantum Random Bit Generator' (QRBG121),它是 QRBGS 的引擎,是一個快速的、非決定論的( non-deterministic)隨機位元(亂數)產生器,其隨機性依賴「半導體中的光子輻射,然後經由光電效應被偵測到」,這個量子物理過程本身的隨機性。

RBI 的服務能讓你即時透過不同的網路存取模式,例如 C/C++ libraries、web services 以及 Mathematica/Matlab client add-ons 來存取 QRGB 裝置。

QRBG 裝置本身位於 RBI,也由它們運作,並透過電腦集叢與 GRID 網路連上網際網路。

* Quantum Random Bit Generator Service
http://random.irb.hr/

人造重力磁?

Towards a new test of general relativity?

http://www.esa.int/SPECIALS/GSP/SEM0L6OVGJE_0.html

由 ESA 資助的科學家首次在實驗室當中測量到與重力等價的磁場(重力磁場)。在一些特殊的情況下,這個效應比廣義相對論所預期的還要大很多,並且能幫助物理學家朝受到長期歡迎的量子重力論跨出顯著的一步。

如同一個移動中的電荷會產生磁場一般,一個移動的質量也會產生重力磁場(gravitomagnetic field)。根據愛因斯坦的廣義理論,這個效應事實上是微不足道的。然而,奧地利 ARC Seibersdorf Research GmbH 的Martin Tajmar、巴黎 ESA 總部的 Clovis de Matos 以及其同僚卻在實驗室當中測量到此效應。

他們的實驗涉及到一個環型的超導體物質在每分鐘旋轉了 6500 次。超導體是特殊的物質,會在某種溫度下喪失全部的電阻。旋轉的超導體會產生一個微弱的磁場,所以也叫做 London moment。這個新實驗是為了測試 Tajmar 與 de Matos 的猜想,這個實驗可以解釋 Cooper-pairs(目前超導體當中的載體。費米子之一的電子會兩兩成對,形成超導電子態)的高精度質量測
量與他們經由量子理論所作的預測之間的差異。他們已經發現這種破格現象或許能以旋轉超導體當中出現的重力磁場來解釋(這個效應為了要與其磁性的相似物做類比,已經被命名為 Gravitomagnetic London Moment。)

小型加速感應器被裝在靠近旋轉超導體的四周,超導體必須被加速以便這個效應能夠顯而易見,並且能夠記錄到超導體之外的加速度場,這個加速度場顯然是因 gravitomagnetism(重力磁說)而產生的。

"這個實驗很像法拉第(Faraday)於 1831 年所作的電磁場感應實驗的重力版本(重力磁場)。

它展示一個超導迴轉儀,可以產生相當具有威力的重力磁場,很像磁圈的重力版本。依據更進一部的確認,這項效應可以當作新科技領域的基石,可以在太空與其他高科技領域產生很多應用," de Matos 表示。雖然只因為地球的重力場而加速了一億分之一,這個經過測量的場,令人驚訝的比愛因斯坦所預測的還要大上億兆分之一倍(1/10^22)。

最初,研究人員勉強相信他們的研究結果。

"我們跑了 250 次實驗,並且在發表之前,花了 3 年的時間改進設備,還花了超過 8 個月的時間討論結果的正確性。現在我們確信這項測量,"Tajmar 表示。他完成該實驗,並且希望其他物理學家也能夠進行他們自己版本的實驗,以便能夠確認這項發現,並且排除因儀器所產生的效應。

在他們對其猜想進行平行實驗評估的同時,Tajmar 與 de Matos 也在尋找Gravitomagnetic London Moment 更精練的理論模型。他們從超導性得到靈感。超導體的電磁特性已在量子理論當中解釋過。理論當中假想一種能夠攜帶力量的粒子(force-carrying particles),稱為光子,以獲得質量。經由允許一種能夠攜帶重力的重力子(gravitons),讓它變更重,他們發現這個超大的重力磁場能夠形成。

"如果經過確認,這將會是個大突破," Tajmar 表示,"它為研究廣義相對論開啟了新的方法,而且對於量子世界是個重要結果。"

其結果將於 3/21 在 ESA 的 European Space and Technology Research Centre (ESTEC) 一日研討會上呈現。關於此工作的二份詳細報告已考慮出版。這些報告可以在 Los Alamos 的預印 server 上,用 gr-qc/0603033 與 gr-qc/0603032 這兩份編號找到。

※ 相關報導:

* APOD: 2004 April 28 - The Smooth Spheres of Gravity Probe B
http://www.phys.ncku.edu.tw/~astrolab/mirrors/apod/ap040428.html

* Experimental Detection of the Gravitomagnetic London Moment
http://arxiv.org/abs/gr-qc/0603033

* Local Photon and Graviton Mass and its Consequences
http://arxiv.org/abs/gr-qc/0603032

大霹靂、標準宇宙論模型的證據找到了
測量地球呼吸 國家重力基準站下月展示
"改進過的" 愛因斯坦理論
物理學家提出愛氏重力場方程式精確新解
微中子偵測器可能發現超弦理論證據
不需要黑暗物質的重力理論
恆星系統暗示太陽可能有伴星:復仇女神
垂死恆星揭露更多新種黑洞的證據
超空間引擎可望成真?
傾聽黑洞的心聲
世界很有可能是平的 -- 全像理論

GMT 與CUT:為何美國要切斷時間與太陽之間的連結?

Why the US wants to end link between time and sun

當鐘聲在 62 時半響起,那是什麼時間?

根據美國政府所提議的標準,時間將會按照我們測量的方式改變。該提議,受到商業界喜愛,天文學家痛恨,英國視為會威脅到其可敬標準 GMT。

由美國政府提議,背地裡在聯合國制定的標準內容,在本月早先泄露給科學家們了解。這項標準,將規定全世界每一天都將只有 24 小時,分毫不差。不過,到目前為止,這個標準都尚未成真。

因為月球的重力開始減緩地球的速度。地球每天必須要花更多的時間才能繞地軸自轉一週。雖然差異很小,不過每隔幾年,總有一群人將全球的時間校正回來,聯合國的 International Earth Rotation and Reference Systems Service(國際地球自轉與參考系統部門)告訴政府、電信公司、衛星操作員以及其他單位,增加個幾秒鐘以確保大家時間同步。通常是在每年的除夕或是六月底的最後一天。

不過增加這些特別的 "閏秒"(leap second),最後一次在 1998 年,可是讓電腦系統帶來無謂的大麻煩,因為軟體程式不知道如何處理所謂的 61 秒、分,進而產生一些問題。這真是一件大工程,John Yuzdepski 說,他是加州聖荷西Symmetricom Inc. 的執行長,他們負責提供超級精確的時間給電信業、太空與軍方單位使用。

在 1996 年 1 月 1 日,增加的秒數讓美聯社廣播電台的電腦崩潰,開始亂播預錄好的節目。在 1997 年,俄羅斯的 GPS Glonass 在收到傳來要跳躍幾秒的指令之後當機了 20 小時。以及在 2003 閏秒的臭蟲使得 Motorola 的 GPS 接收器上面顯示現在已經經過 62 點鐘的一半。

"許多人的軟體在閏秒時遭遇麻煩",Dennis D. McCarthy 說,他在擔任美國海軍時間主管時,起草了 "美國閏秒提案" (U.S. leap-second proposal)。因為這些問題,美國政府從去年開始安靜的在背後操作,讓聯合國的 ITU 廢止閏秒。 ITU 告訴地球自轉部門該如何計時。

"安全的生活是一項議題",William Klepczynski 說,他是美國國務院的首席分析員,贊成此一提案。他聲稱那些忽略需要增加閏秒功能的程式設計師對於 "未來的航空飛行會產生威脅" 因為程式的錯誤可能會關閉整個飛行控制系統。

消除跳躍時間,將使得六分儀與日晷變慢而不正確。不過支持者認為這將讓經由衛星支持的 GPS 可以提供更精確的經緯度給任何具有接受器的人。

但是美國的提案,一個 ITU 委員會將在 11 月審議,已使得某些計時的權威人士感到不安,包括地球自轉部門的閏秒頭頭,法國天文台的 Daniel Gambis。"身為一位天文學家,我想時間應該跟隨地球" Gambis 博士在訪談中表示。他稱美國的努力為 "高壓攻勢"(power play)而且 "打擾了科學的對話"。他說,在一份 2002 年進行的調查顯示,90%的人願意保有閏秒。

在七月五日,Gambis 博士送了一封 e-mail 給這些計時員,透露關於美國提案的構想給他們,美國預計在 2007 年中止閏秒。Gambis 力促收信人向該國的 ITU 代表接觸。

這在天文學界激起一陣反對聲浪,他們抱怨說,如果讓時間與太陽脫離了關係,將使得望遠鏡需要改變,改變這些望遠鏡將花費一萬到五十萬美元。這是因為頂級的望遠鏡需要精確的時間與地球的位置來瞄準某一特定的恆星。

"對於拋棄時間與地球自轉之間的關連我們十分不樂見。" Rob Seaman說,他是土桑市國家光學天文學天文台的程式設計師。Jean Meeus,一位有影響力的比利時天文學家,聲稱美國的提案是 "古典天文學的重大災難" 以及 "骯髒的騙局"

美國中止跳躍時間的提議亦遭英國強力反對。他或許會因此而失去標準時間的地位。從 1884 到 1961 年,全世界將時間切換成格林威治標準時間,是基於每天確實看見恆星起落的倫敦格林威治皇家天文台而訂定的。

當各國轉移到目前的 Coordinated Universal Time,他使用的是精確的原子鐘,他們同意插入閏秒以確保這個公定時間與格林威治時間的時間差在1 秒之內。

甚至連大霹靂,以及 BBC 的廣播時間都跟隨著 CUT 的此時,英國國會依然拒絕將官方標準時間從格林威治時間改成 CUT,因為那是英國的驕傲。

廢棄閏秒將會強迫此一議題,並且使得世界緩慢的離開格林威治時間。所以英國的科學部長 Lord Sainsbury 在四月布萊爾競選時表示反對意見,以反對美國的提議。"它已經被用來攻擊政府" 在 ITU 代表英國的 Peter Whibberley 表示。 "人們以有些敏感的方式看待 GMT" 他說 "它代表一般反歐的觀感"

在中止閏秒之後,太陽升起的時間將會愈來愈慢,每十年數秒鐘。為了補償此一狀況,美國提議每 500-600 年中加入所謂的 "閏時"(leap hour),這也代表著地球自轉的時間愈來愈慢了。海軍研究實驗室的 Ronald Beard 表示,這將不會改變每天日光節約的時間。他是 ITU 跳躍秒數特別委員會的主席,他贊成廢止閏秒。他說:才不會有人在下午四點才開始上學讀書這類的事情發生。

到目前為止,美國官方仍將此一提議視為機密,儘管 Gambis 博士的e-mail 以及公眾的輿論已經沸沸揚揚。美國的 ITU 時間委員會代表 NIST 的 D. Wayne Hanson 拒絕接受訪問。透過發言人表示,此提議是 ITU 內部的事情不該被公開討論。

這種遮遮掩掩的態度激怒了天文學家,當有許多望遠鏡需要聲及時,他們抱怨他們沒有必要在 2007 年轉換時間。國務院的 Klepczynski 博士,則反駁說,最好在發生意外之前將電腦程式修正完畢。他說:"某些人害怕提出防護措施"。

天文學家則不能確定。"如果你的導航系統因為一秒鐘的錯誤而導致二台飛機墜毀,那麼閏秒對你而言是個大麻煩。" Steve Allen表示,他是加州大學的天文學家,還成立一個與閏秒有關的網站。

實際上,反對的意見在哲學的成份上比成本效益來的多。應該要確信懶惰的程式設計師戰勝了升起的太陽嗎?對政府而言,擔憂安全性比擔憂天文學家更重要嗎?答案是確定的,但在 Allen 的觀點裡則不是。"時間基本上都是指當你在地上插入樹枝,然後觀看它的陰影時準備要測量的東西。"

微軟尋求"不朽運算" 專利

E-mail from the grave? Microsoft seeks patent on 'immortal computing'

http://seattlepi.nwsource.com/business/300636_msftimmortal22.html

By TODD BISHOP
P-I REPORTER

在這個及時資訊的文化中,某些微軟的研究者正在推動一個很根本的想法 -- 要將訊息保留,以便在數十年、數世紀之後傳遞的概念。

這個計畫,被封為 "不朽運算(immortal computing)," 可以讓人們在物理性的人工製品或其他形式當中儲存數位資訊,以便將資訊保留並揭示給未來的世代,甚至有可能是未來的文明。

畢竟,當你放眼未來,你不可能知道終端的使用者將會是誰。

"這無疑是個長期計畫," Andy Wilson 表示,他是微軟的研究者,他對於數位化資訊短命天性的沈思,讓這個研究的倡議得到啟示。

研究者所展望的一個情節:人們可以儲存訊息給後代,那些訊息有可能是關於他們生活的資訊、他們自己互動式的全像圖給參訪他們墓碑或是骨灰罈的訪客存取。

而這裡是那些不朽概念可以介入的地方:研究者說手工藝品可以是人們象徵性的代表,反應出他們個人特質的元素。這個系統或許可以被設立用來採取某些行動 -- 例如:e-mail 生日祝福給被確認為是兒孫的人。

這個先前未公開的計畫因為一個新浮現的專利申請案而曝了光,在當中,研究者解釋了某些他們仍在探索當中的概念。該計畫試圖要解釋一個事實,那就是大量捶手可得的資訊其實是儲存在壽命有限的媒介之上,而且以將會被廢棄的格式儲存。想想看那些磁片有多快就消失無蹤。

但是研究者們不只是想到關於個人的資訊遺產。

"或許我們應該開始思考,現在應該是要創造我們 Rosetta stones(譯註:這是埃及國王 Ptolemy V 的詔書,上刻有三種文字,讓人們得以解讀古埃及象形文字)的文明階段了,那一定包含許多資訊,甚至超越了個人記憶,到文明記憶的地步," Eric Horvitz 表示,他是微軟的主要研究者,他亦參與此計畫。

這個計畫到哪裡會停止並不清楚。在某些狀況下,微軟研究計畫最終會導致產品的推出,或是對他們有所貢獻,不過在其他情況下則否。研究者拒絕透露,他們是否已經有一個 "不朽運算" 人工製品的原型了。

這只是每個研究者所涉及的許多計畫之一。不過這份專利申請,在 2005 年 6 月提出,而且在本月公開,至少證明他們在 "不朽運算" 花費了相當多的心思。

除此之外,這項專利申請還描述了耐久性資料儲存的可能使用方式,例如先進的影像技術,能確保資訊歷久彌新。

其中的關鍵之一是避免儲存裝置具有可移動的 --- 而且很可能會損壞的-- 內部零件。

該申請表示資訊可經由一個分離的界面存取,獨立於所有的個人人工製品之外,以便於能夠讓呈現方式隨著科技改變而演進。那些儲存資訊的人將能夠事先決定何時以及何人可以公開,使用 DNA 或是生物測定法來確認身分。

該申請亦引用了替代能源的潛在使用,例如:熱量或感應電力(inductive power),來驅動這個界面。

這些人工製品也可能會被設計成讓資訊存取過程更加明白,免得讓那些後來發現它們的人不知道該怎麼對付這些來自於 21 世紀的奇怪物體。除此之外,該專利申請亦列出以多種文字或是象形圖案附上操作說明的可能性。

在那種方式之下,操作說明很可能具備 "自我表白性(self-revealing)," 研究者表示。這個概念有點像 1970 年代發射的航海家(Voyager)太空船所攜帶的 Golden Record 上的象徵指示 -- 它們上面提到該如何建造一個播放器來重現這些記錄,那些記錄裡面包含來自於不同語言的祝福。

可確信的是,微軟研究者並非第一個發現,在數位時代資訊保存需求增加的人。

一個存在於線上的方式稱之為 Handle System(譯註:http://www.handle.net/)。在十來年之前展開,它分派一個唯一的識別符(identifiers,譯註,就是所謂的 Digital Object Identifier (DOI) System),那不像傳統的 Interent 位址,可以用來找到線上的資訊與媒介,甚至它們隨後被移到其他地方也可以。這個系統來自於 Bob Kahn 的研究,他是一位科技先鋒,現今Internet 先驅,Arpanet 的系統設計者(譯註:Bob 本名 Robert E. Kahn,他曾主持知名的 BBN 公司,與 Vinton G. Cerf 共同發明了 TCP/IP,有人稱他們為網際網路之父。)

"當人任何人對它感到興趣時,我就覺得很高興," Kahn 在上周的訪談中,被問及微軟的研究計畫時表示。"有愈來愈多的資訊被產生,而每個人,無論是企業或個人,不時需要回溯並找尋某些東西,但他們不知道該去哪找。"

"我認為這裡有個一般性的議題,那對於未來真的很重要," 他繼續說。然而,他表示,如果說 Handle System 無法用來參照任何資訊性的來源,這麼說是沒有道理的。

而且,微軟已經申請了一個專利這項事實,很可能會讓業界側目。

"我認為他們追趕它是很棒的。如果他們覺得他們有必要申請專利以便能夠追趕它,我猜那是他們必須要做的商業決策," Mark Anderson 表示,他是 Strategic News Service 科技新聞通訊的發行者。"不過我希望他們不要以排除他人從事相同事情的方式來做它。"

微軟的研究者廣泛的談論關於他們的計畫,不過在某個政策下,他們不願對懸而未決的專利申請提出任何評論。

Anderson 在數年之前,一場他的 Future in Review 研討會中就提出相似的概念。他建議某人提供一個網際網路儲存以及通訊服務,讓人們可以傳遞重要的知識給後代,在某種程度上,那真的在今日發生了。

微軟的研究者表示,他們也對於在線上以不同方式保存資訊感到興趣,不僅限於人工製品而已。在此同時,研究者 Horvitz 表示,在某案例中,如果要把資訊保留在同一地方,他有某些事要說。

"任何道理(reason)到了墓裡都會可能會產生轉變," 他說。"在資訊存在的物理空間中有個軌跡(locus)的點子... 可以讓其成為真的可以去遊歷的,更具意義的地點。"

※ 相關報導:

數位冰河時代 -- 你的檔案還能用嗎?
如何選擇『歸檔』等級的 CD/DVD
歷史錄影帶磁化 文獻館全力搶救
Turner Entertainment 採用全像儲存技術
單一光子的超高密度光學儲存
一統raw圖片格式亂象 Adobe力推新格式
病歷e化 衛署五年將花20億

* 「談數位內容於電子商務之應用座談會」分析報告
http://www.nii.org.tw/cnt/info/report/200309_4.htm

* Digital object identifier - Wikipedia
http://en.wikipedia.org/wiki/Digital_object_identifier

* 網路英雄 / Where Wizards Stay Up Late : the Origins of the Internet
http://210.200.236.42/books/book_basic.asp?pclassid=BE&id=BE0040

清單 - 圖書館與數位典藏

 編輯

‧2007/11/30 線上圖書館讓讀者存取 150 萬本書
‧2007/01/24 微軟尋求"不朽運算" 專利
‧2006/12/01 數位冰河時代 -你的檔案還能用嗎?


如何選擇『歸檔』等級的 CD/DVD
歷史錄影帶磁化 文獻館全力搶救
Turner Entertainment 採用全像儲存技術
單一光子的超高密度光學儲存
一統raw圖片格式亂象 Adobe力推新格式
病歷e化 衛署五年將花20億
漢字的故事 印證正體字之美
聽障字體設計師 創造中文字型風靡世界
中文成英語新詞最大來源
在水面上寫字??
改寫書的科技:自己打造一本 "書" 吧!
數位出版 我落後了
英美史料電子書 大學可檢索
Google: 公共書籍免費全文下載
Google 競爭者 Open Library 上線
如何選擇『歸檔』等級的 CD/DVD歷史錄影帶磁化 文獻館全力搶救


掃描全世界的書!
Google攜手加州大學 圖書掃描再獲奧援
史上最大圖書館 Google 化夢想為行動
Google 線上書庫 微軟雅虎踢館
開原碼計畫挑戰Google圖書館
亞馬遜週一推出電子書 Amazon Kindle

研究:最理想的著作權期限為 14 年
記錄歷史 大英圖書館廣徵百萬電郵
彈性聚合物記憶裝置
奈米電腦儲存能以千倍速度檢索資料

Intel Mac 多重開機 - OS X + WinXP + Linux

Triple Boot via BootCamp - OnMac.net Wiki

http://wiki.onmac.net/index.php/Triple_Boot_via_BootCamp

在 Apple 發表 Boot Camp 之後,已經有不少人成功的在 Intel Mac 上安裝 Windows XP 了,現在有位老兄,試出了三重(不是台北縣那個)開機,可以在上面安裝 Linux(作者用 gentoo 2006.0)了。不過有點要特別注意,他的方法會清掉硬碟當中的內容,因此要事先做好備份。


以下是準備材料:

* 一部 Intel Mac http://store.apple.com/
* OSX 安裝 DVD(s)
* 一張非升級的 Windows XP CD with SP2 slipstreamed
* 一張 x86 Linux Live CD/DVD(作者使用 gentoo 2006.0 Live CD)http://www.gentoo.org/
* 更新 Intel Mac 的 firmware(2006 早期機種才要)ttp://www.apple.com/support/downloads
* Apple BootCamp http://www.apple.com/macosx/bootcamp/
* OSX 10.4.6 combo update http://www.apple.com/support/downloads/macosx1046comboforintel.html


A quick note on disk partitioning

有點要注意,Intel Mac 採用新式的 GPT (GUID (globally unique identifier) Partition Table)系統來分割硬碟,只支援 OS X 與 Linux,Windows 則還在用 MBR。 Boot Camp 為了遷就這種情況,因此二種系統兼用,這也讓三重開機有點難度。目前只有 diskutil(包含在 OS X 10.4.6 當中)有辦法切出同時包含 GPT/MBR 的硬碟。目前 GPT 會把 MBR 的資料洗掉,因此fdisk/partion magic 之類的軟體都沒有辦法編輯 GPT。因此,目前只能用 diskutil 來切割硬碟。不過,更糟的是MBR 只支援 4 個 primary partitions,而且 GPT 不支援 extended partitions,結合這些限制,表示多重開機的系統只能夠有 4 個 primary partitions 可用,另外 Mac 的 bootloader 霸佔掉第一個 primary partition,因此只能在上面裝上其他三種不同的作業系統。
所以 linux swap partition 不能夠存在,因此必須透過 swapfile 來解決。還有,因為某些原因, Boot Camp 會把 Windows 的 "C:" 當作最後一個磁碟,因此如果不是安裝 Windows 的話,會在安裝完畢,第一次重開機時出現:"cannot find hall.dll"(地獄?)的錯誤訊息。另外,最好聽 Apple 的忠告,把分割 format 成 FAT32,NTFS 只會吃到閉門羹。然而,你要用 FAT32 時,必須注意,硬碟分割的大小不能大於 32GB。


The science of chainloading

作者是利用 "連鎖載入" 的方式從 Windows Xp (ntldr) bootloader 載入 Linux 的 lilo bootloader,達成連鎖開機的目的(Boot Camp 似乎只認得 ntldr ),因此 grub 很抱歉,不能用,因為他的 stage 1.5 code 會寫入與 GPT 相同的地方,因此 Intel Mac 會不允許這麼做。作者也表示,可能可以用 efi/elilo 來啟動,有人成功的話,別忘了告訴作者。


Procedure

1) 如同一般狀況安裝 OS X 到單一一個分割上,為了節省時間,只裝 base system
2) 開機進入 OS X,安裝 10.4.6 combo update
3) 安裝 firmware update,然後再安裝 Boot Camp
4) 執行 Boot Cam 精靈然後建立 XP driver CD,然後離開 Boot Camp。
*千萬不要用 Boot Camp 分割硬碟* 當然你可以直接察看 package 當 中的內容,找出 driver,然後用 disk utility 來燒成 CD,它位於 contents/resources/diskimage.dmg

5) 開啟終端機視窗輸入下列指令來重新分割硬碟。在 100 GB 的硬碟上作者切了 60GB 給 OS X,17GB 給 Linux,15GB 給 Windows。你可以 改變分割硬碟的大小,但是分割的次序 *不要改變* (所有指令均在 同一行)

sudo diskutil resizeVolume disk0s2 60G Linux 17G "MS-DOS FAT32" 15G

6) 插入 WinXP CD 重開機,如果聽到 "噹" 一聲,按下 c 鍵。
7) Windows 安裝程式將會開始。當初現硬碟分割畫面選擇 C: 槽。將它 "快速分割" 成 FAT32。然後按照一般方式安裝,重開機。

8) 在第一次重開機時,按住 option/alt 鍵,並從 bootloader 當中選 擇 Windows 的硬碟,以便繼續安裝 XP。你將重複這個步驟,直到 XP 完成安裝。

9) 最後安裝 Apple 所給的驅動程式,讓 XP 認得硬體。

A. OK 現在你有雙重開機的 Intel Mac 了,不過步驟尚未結束。

B. 插入 Linux 的 Live CD 然後重開機,如果聽到 "噹" 一聲,按下 c 鍵,從 Linux 開機。

C. 輸入下面指令設定 root 密碼。

sudo passwd root

D. su 成 root,然後 format Linux 的分割,它應該在 /dev/sda3,不 過請仔細檢查!

su mke2fs -j /dev/sda3

E. mount 上你建立的 ext3 分割,然後建立 swapfile。下面的例子建了 2GB 的 swapfile,當然,大小自便。

mkdir /mnt/linux && mount -t ext3 /dev/sda3 /mnt/linux
dd if=/dev/zero of=/mnt/linux/swap bs=1024 count=2097152
mkswap /mnt/linux/swap
swapon /mnt/linux/swap

F. 在這裡,你必須要 bootstrap(安裝;generally considered a longer term for booting, or the process of starting up any computer... http://en.wikipedia.org/wiki/Bootstrap)你最喜歡 的套件,依照不同的情況,你可能需要編譯你自己的 kernel。

G. 現在我們要設定 lilo bootloader 以便讓我們可以開機進入 Linux,請依照你套件安裝 lilo 的方式安裝 lilo。

H. 建立如下的 /etc/lilo.conf

# Global LILO settings
boot=/dev/sda3
prompt
timeout=50
default=Linux
# Kernel specific LILO settings
image=/boot/
label= Linux
read-only
root=/dev/sda3

I. 然後將 lilo 安裝到你的 Linux 分割的分割記錄當中。

/sbin/lilo

J. 現在你必須要將 Windows 的分割給 mount 上,並在 ntldr 的設定檔 boot.ini 當中建立連鎖載入的設定。

mkdir /mnt/windows && mount -t vfat /dev/sda4 /mnt/windows

cd /mnt/windows
dd if=/dev/sda3 of=linux.mbr bs=512 count=1
cat 'C:\linux.mbr="XYZ Linux"' >> /mnt/windows/boot.ini
cd && umount /mnt/windows

K. 現在重新開機。如果每件事情運作 OK,那麼當你按下 option/alt 鍵時你將可以看見 OS X 與 Windows 的開機選項,如果要開啟 Linux,你必須先選擇 Windows 然後從 ntldr 當中選擇 Linux 開機。


使用者發現 Boot Camp 的問題
Apple 推出軟體 可讓 Intel-Mac 裝 XP
Apple 開始更新 MacBook Pro

軟體是否能趕上多核心運算?

Where's The Software To Catch Up To Multicore Computing?

http://www.informationweek.com/news/showArticle.jhtml?articleID=197001130

IBM 次世代系統軟體的首席工程師,對於我們能將那些需要利用超級電腦等級機器優勢的軟體推進多遠表示質疑。

By Catherine Crawford / EE Times / Jan, 29, 2007

就目前在處理器與系統上可利用的(available)每秒浮點運算次數而言,Moore 定律尚未達到它的極限。但就大部分軟體 -- 甚至是先進科技運算軟體 -- 的合用(usable)性能而言,或許已經達到這樣的極限了。

一瞥 Top500 Supercomputer Sites List (www.top500.org) 上的清單,證實大部分科技運算的工作量,已經轉一到日常的 Linux 叢集:包括日常使用的 server、網路以及儲存設備。在此同時,新穎的多核處理器架構,例如:Cell Broadband Engine (Cell BE),證明大量運算的潛能(數百 gigaflops)已經屬於入門等級的 server 了,如:2-4 核處理器。

由於有如此多的運算能力可以就近取用 -- 不管是在 SoC 或是日常使用的叢集上 -- 世界各地,各種規模的公司與業界且甚或是個人,或許都能夠取用這樣的能力來解決比以前更多的問題。這裡只有一個問題:軟體是否能夠利用這些處理器、核心與執行緒所有的優勢呢?就大部分而言,它仍尚未達到 -- 即便是從歷史觀點上所聚焦的那些尖端技術設備,例如:科技運算。事實上,IDC 的 Earl Joseph 在一個科技運算軟體的研究當中下結論表示:"今日許多 ISV(獨立軟體供應商)的程式碼,其規模(scale)只能達到 32 顆處理器,而且某些在業界當中最重要的,竟無法多於 4 顆處理器。"(www.hpcwire.com/hpc/430360.html

他的研究甚至發現,當有一個供應商已經有策略要將其程式碼平行化或是提升其規模,其重新架構與重新編程的成本相對而言,較所意識到的市場利益來的更高。


進入 Roadrunner(走鵑,迪士尼卡通中那隻跑的飛快的鳥)

Roadrunner 將會是世界上第一部基於 Cell BE 的超級電腦。當它於 2008 開始在 LANL 啟用時,其效能峰值回答到 1.6 petaflops,或每秒運算 1600 兆次。(譯註:目前的記錄是 0.367 pflops)

Roadrunner 首次提供了混合運算架構:多重異質核心,再加上多層式(multitier)記憶體階層(hierarchy)。它也是完全由日常零件所構成:基於 AMD Opteron 的 server,基於 Cell BE 的加速裝置,還有 Infiniband 互連技術。在標準程序中(例如:檔案系統 I/O)將會由 Opteron 處理器所處理,而許多數學上以及 CPU加強的(intensive)元素將會被導向 Cell BE 處理器。

為了讓此一複雜的架構,甚至連最先進的科學模擬應用軟體開發者都覺得有用,在系統開發中的許多工作,都是屬於能賦予並協調應用架構與開發(tooling)的程式方法論上。

這些能加以運用的 API 都相當簡單並且可延伸,並且被設計成能夠利用不同種類的記憶體與 I/O 子系統,同時保持其改變是位於實作之下,以便讓開發者無從察覺。此計畫的焦點是聚焦在不同拓撲的一組核心、有效率的散播(scatter)/回收記憶體的操作之上,而且當使用者涉及到運算與通訊等重疊領域時,這些東西都是被隱藏起來的。

其哲學是所謂的 "勞力分配" 方法。這裡將會有一組計算機核心開發者持續將微處理器 ISA 的效能發揮到最大;事實上,這樣的核心早已存在(矩陣相乘是個好例子)。函式庫開發者將會使用一個替 Roadrunner 開發,用來將核心同步化至微核心、記憶體階層函式庫中的那種架構。應用程式開發者將使用標準的編譯器以及連結器技術連結這些函式庫。前後一致的 API 以及橫跨一些微核心架構的方法論,將無須引介新的程式語言,將會限制住程式維護的成本。因此,函式庫開發者所獲得的易用性改進,將不只是在這套加速系統上,還可及於一般用途的多核心途徑(approache)與叢集。

Roadrunner 不只是國家實驗室超級電腦的一個單一客製化計畫;它呈現出一種新的架構。我們正邀請業界夥伴來定義程式方法論的元件(API、工具等),以便讓多核心系統也將能夠被這些夥伴所存取。在這種方式之下,主要的科學性發展將不在限於大學或是主要研究實驗室。業界像這樣致力於此的利益可以 "涓滴遍佈(trickle down)" 到我們日常生活當中各方面上。

潛在的應用包括:

* 金融服務。藉由即時運算資本市場當中的因果關係,超級電腦可以即時的預測一個股票市場的改變對整個市場所產生的漣漪效應。

* 數位動畫。大量的超級運算能力將讓電影製作者創造逼真的角色與劇本,這將模糊電影動畫與真實角色之間的界線。

* 基於資訊的醫學。複雜的 3D 組織、骨架描繪將會即時呈現,而用於腫瘤偵測的線上分析(in-line analytics),也能用將來病患即時與歷史資料進行比對。綜合病患的即時資料可以用來產生預警。

* 油料與天然氣的生產。超級電腦可以繪出地底圖形,模擬貯藏處並分析由科學家從田野調查中所取得的視覺資料。

* 奈米技術。超級運算預期能提升裝置建構的科學,例如:單一原子或分子的電路。

* 蛋白質折疊。超級運算能力可以讓我們了解疾病如何發生,如何測試它們,以及療法該如何開發。

當架構變得更加複雜,從多核心處理器到像 Roadrunner 那樣的混合系統時;當超級運算能更容易取得時;還有當開發者仍試在圖尋找能讓他們的軟體更有效能,而不用依賴更勝以往的 "頻率暴衝(超頻)" 比率時,我們正聚焦在保持應用程式開發的簡單 -- 致力於將工程藝術納入架構中,而非應用程式開發本身。而且藉由回歸至簡單做事情的基礎上,我們讓軟體能夠跟上『矽』的優勢,讓桌上型的 teraflops 不在只是一種科技成就,而是更有 用的一種東西。

監看處理序 CPU 使用量


監看處理序 CPU 使用量

您可以使用 Process Explorer utility from Sysinternals (英文) 來查看 Windows 標準時鐘型時間計量的不準確性。在 Windows Vista 系統上,請執行 Process Explorer 並將 [循環差異 (Cycles Delta)] 欄位新增至處理序檢視中。[循環差異 (Cycles Delta)] 顯示每一個處理序的執行緒在兩次 Process Explorer 更新之間執行的循環次數。因為 CPU 時間計量仍然是以間隔計時器為基礎,如果您同時新增 [CPU 時間] 欄位,則會看到許多處理序的執行緒耗用數百萬次 CPU 循環,卻仍然未更新其 CPU 時間,且未在 CPU 使用量欄位中顯示出來。

圖 A 在 Process Explorer 中檢視 CPU 時間和循環差異
圖 A 在 Process Explorer 中檢視 CPU 時間和循環差異 (Click the image for a larger view)


監看 MMCSS 優先順序增加

您可以播放一段視訊或音訊、執行效能監視器、將圖形比例設定為 31 (最高 Windows 執行緒優先順序),並將 Windows Media Player (Wmplayer.exe) 執行緒物件的所有例項的 Priority Current 計數器新增至顯示畫面上,來目睹 MMCSS 服務套用至 Windows Media Player 執行緒的執行緒增加情形。一個或多個執行緒會以優先順序 21 執行。

圖 B Windows Media Player 的執行緒優先順序增加情形
圖 B Windows Media Player 的執行緒優先順序增加情形 (Click the image for a larger view)


查看非常低 I/O 優先順序

Process Monitor 是來自 Sysinternals 的一個即時檔案系統及 Registry 監視公用程式,它收集檔案系統讀寫作業的詳細資訊,包括它們在 Windows Vista 上的 I/O 優先順序。反白行顯示由 SuperFetch 發出的非常低優先順序 I/O 的範例 (我會在下一期的文章中討論它)。

圖 C 在 Process Monitor 中檢視非常低 I/O 優先順序
圖 C 在 Process Monitor 中檢視非常低 I/O 優先順序 (Click the image for a larger view)

深入探索 Windows Vista 核心:第一篇

http://technet.microsoft.com/zh-tw/magazine/2007.02.vistakernel.aspx

‧深入探索 Windows Vista 核心:第一篇

At a Glance:

* 執行緒優先順序和排程
* 檔案架構符號連結
* 取消 I/O 作業



這是有關 Windows Vista 核心新功能一系列文章的第一篇。在這篇文章中,我們要看看處理序、執行緒和 I/O 等方面有哪些改變。未來幾期的文章將涵蓋記憶體管理、啟動和關閉、可靠性和修復及安全性。

本文的範圍只包括對 Windows Vista™ 核心的變更,尤其是 Ntoskrnl.exe 及其密切相關的元件。請記住,Windows Vista 有許多核心以外的其他重要變更不在此討論範圍內。這包括對 Shell (例如整合式桌面搜尋)、網路功能 (如新的 IPv6 堆疊和雙向防火牆) 及下一代繪圖模型 (例如 Aero™ Glass、Windows® Presentation Foundation、桌面視窗管理員和新圖形驅動程式模型) 的改進。此外,新的 Windows 使用者模式和核心模式驅動程式架構 (UMDF 和 KMDF) 也不包括在內,因為這些都可以逆向安裝在舊版 Windows 上。


CPU 循環計數

Windows Vista 增強了部分的處理序和執行緒功能,包括使用 CPU 循環計數器來達到更公平的 CPU 配置,以及新的多媒體類別排程器服務 (Multimedia Class Scheduler Service,MMCSS) 來幫助媒體應用程式呈現無瑕疵播放。

包括 Windows Vista 以下的所有 Windows NT® 設計間隔計時器插斷常式大約每隔 10 或 15 ms (毫秒) 執行一次 (視硬體平台而定)。此常式會檢查它插斷的執行緒並更新該執行緒的 CPU 使用量統計值,就好像該執行緒已執行了整個間隔之久,而實際上該執行緒可能是在該間隔結束之前才開始執行。不僅如此,可能在技術上已指派 CPU 給該執行緒,但因為執行了硬體和軟體插斷常式,反而沒有機會執行該執行緒。

雖然時鐘型時間計量對於報告執行緒和處理序 CPU 使用量的診斷工具而言沒有問題,但執行緒排程器使用該方法會造成不公平的 CPU 配置。在 Windows 的用戶端版本上,預設准許執行緒執行最多 2 個時鐘刻度 (如果是在幕前執行,則為 6 個刻度)。不過,執行緒實際上可能未得到 CPU 任何時間或最多得到 6 個刻度 (如果是在幕前執行,則為 18 個刻度),視它在系統上的行為和其他活動而定)。

[圖 1] 顯示當兩個具有相同優先順序的執行緒同時準備好執行時可能會發生的不公平情況。執行緒 A 會執行到下一個時間配量間隔到期,而排程器卻假設它已執行了整個間隔之久,因而判斷執行緒 A 已執行完畢。不僅如此,讓執行緒 A 負責承擔在輪到它的期間內所發生的插斷,這是不公平的。在下次間隔時,排程器會選擇由執行緒 B 接管,並執行到整個間隔結束為止。

圖 1 不公平的執行緒排程圖 1不公平的執行緒排程

在 Windows Vista,排程器使用現代處理器的循環計數器登錄來準確追蹤一個執行緒執行的 CPU 循環次數。藉由評估 CPU 在一個時鐘間隔內可以執行的循環次數,可以更準確地在 CPU 上進行分配。此外,Windows Vista 排程器不會將執行緒執行期間的插斷執行計算在內。這表示在 Windows Vista 上,執行緒至少會輪到一次 CPU,但絕不會超過一次額外執行的時鐘間隔,以達到更好的公平性及更確定的應用程式行為。[圖 2] 顯示 Windows Vista 提供兩個執行緒至少一個時間配量的執行間隔,以回應 [圖 1] 所顯示的狀況。

圖 2 Windows Vista 循環式排程圖 2 Windows Vista 循環式排程

[監看處理序 CPU 使用量] 資訊看板說明如何使用 Process Explorer 公用程式自行監視處理序 CPU 循環使用量。


多媒體類別排程器服務

使用者期望多媒體應用程式 (包括音樂和視訊播放程式) 能夠提供完美的播放體驗。不過,其他同時執行的應用程式 (如防毒軟體、內容檢索程式或甚至郵件用戶端) 對 CPU 的需求可能會引起你我所不樂見的一些風波。為了提供更好的播放體驗,Windows Vista 引進 MMCSS 來管理多媒體執行緒的 CPU 優先順序。

多媒體應用程式 (如 Windows Media® Player 11) 使用可指出其多媒體性質的新 API 在 MMCSS 中登錄,這些多媒體性質必須符合下列登錄機碼之下按名稱列出的其中之一:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\
Currentversion\Multimedia\SystemProfile\Tasks

各種工作機碼會指定與不同多媒體類型相關聯的執行緒在 CPU 和圖形處理器資源方面會獲得多少青睞 (不過 Windows Vista 未並實作圖形處理器資源管理)。[圖 3] 顯示在全新 Windows Vista 安裝之後的其中一個工作登錄機碼的內容,不過協力廠商開發人員可以新增自己的工作定義。

圖 3 多媒體類別排程器音訊工作定義

圖 3 多媒體類別排程器音訊工作定義 (Click the image for a larger view)



實作於 %SystemRoot%\System32\Mmcss.dll 中並執行於 Service Host (Svchost.exe) 處理序中的 MMCSS,有一個優先順序管理執行緒是以優先順序 27 執行 (Windows 中的執行緒優先順序範圍是從 0 到 31)。這個執行緒將已登錄的多媒體執行緒優先順序增加到與其工作的登錄機碼的 Scheduling Category 值相關聯的範圍,如 [圖 4] 所列。在 Windows 中,執行緒優先順序 16 以上是在即時優先順序範圍內,高於系統上的所有其他執行緒 (但核心的記憶體管理員工作者執行緒例外,它是以優先順序 28 和 29 執行)。僅系統管理帳戶 (如 MMCSS 執行時所用的本機系統帳戶) 具有「增加優先順序」權限,這是要設定即時執行緒優先順序所需要的權限。





在播放音訊檔時,Windows Media Player 會登錄音訊工作執行緒,當您播放視訊時,它會登錄播放工作執行緒。若執行緒指出它們正在傳遞資料流,且同時在擁有幕前視窗的處理序中執行,並且已在其工作的定義機碼中將 BackgroundOnly 值設為 True,此時 MMCSS 服務會增加所有這些執行緒的優先順序。

但雖然 MMCSS 想要幫助多媒體執行緒取得它們所需要的 CPU 時間,它也想要確保其他執行緒至少可取得一些 CPU 時間,使系統和其他應用程式可以保持回應性。因此,MMCSS 保留一定的 CPU 時間百分比給其他活動使用,如下列登錄值所指定:

HKLM\Software\Microsoft\Windows NT\ Currentversion\Multimedia\SystemProfile\SystemResponsiveness

此值預設為 20%;MMCSS 會監視 CPU 使用量,以確保萬一其他執行緒需要 CPU 時,多媒體執行緒不會在 10 毫秒的期間內增加超過 8 毫秒。為了在剩餘 2 毫秒內擺脫多媒體執行緒,排程器使其優先順序掉到 1-7 範圍。

您可以看看 [監看 MMCSS 優先順序增加] 資訊看板,以了解 MMCSS 如何增加執行緒優先順序。

檔案架構符號連結

Windows Vista I/O 相關變更包括檔案架構符號連結、更有效的 I/O 完成處理、對於 I/O 取消作業的全面支援以及優先順序處理的 I/O。

許多人認為 NTFS 所缺少的一項檔案系統功能 – 符號檔案連結 (或是 UNIX 所謂的暫時連結) – 最後終於出現在 Windows Vista 中。NTFS 的 Windows 2000 版本引進的符號目錄連結叫做目錄連接,它可讓您建立一個指向不同目錄的目錄,但直到 Windows Vista 版本誕生,NTFS 才支援檔案永久連結。

Windows 解析符號連結和目錄連接的方式,其主要差異在於進行處理的位置。Windows 是在本機系統上處理符號連結,即使它們參考遠端檔案伺服器上的位置也一樣。Windows 處理的目錄連接是參考伺服器本身的遠端檔案伺服器。因此,伺服器上的符號連結可以參考只能從用戶端存取的位置,如其他用戶端磁碟區,而目錄連接則不行。為了解決此問題,Windows Vista 同時為檔案和目錄提供新的符號連結類型支援。

許多檔案系統命令已更新,以方便了解符號連結的含意。例如,Delete 命令知道不要遵循連結,以免刪除目標,但會刪除連結本身。不過,由於並非所有應用程式都能夠正確處理符號連結,因此要建立符號連結需要有新的「建立符號連結」權限,預設只有系統管理員才具有此權限。

您可以在命令提示字元中使用 Mklink 命令來建立符號連結。命令提示字元的內建目錄命令識別符號連結的方式是將它標示為 ,並以方括弧顯示目錄,如 [圖 5] 所示。Windows 檔案總管也可以識別符號連結,並以快顯箭號顯示它們。您可以將 [連結目錄] 欄位新增至瀏覽視窗中,即可在檔案總管中看到連結的目錄。

圖 5 使用 Mklink 建立符號連結圖 5 使用 Mklink 建立符號連結 (Click the image for a larger view)

I/O 完成和取消

I/O 系統有一些內部變更可改進伺服器應用程式的效能。這些應用程式通常使用一個叫做完成通訊埠的同步處理物件,等待非同步 I/O 要求完成。在 Windows Vista 之前,當 I/O 完成時,發出 I/O 的執行緒會執行一項 I/O 完成工作,而導致切換到該執行緒所屬的處理序並插斷其他正在進行的工作。然後,I/O 系統會更新完成通訊埠狀態,以喚醒等待其變更的執行緒。

在 Windows Vista 上,I/O 完成處理作業不一定要由發出 I/O 的執行緒執行,可改由等待完成通訊埠喚醒它的執行緒來執行。這項小小的變更避免因不必要的執行緒排程和內容切換而導致應用程式和系統整體效能下降。若要進一步改進效能,伺服器可以從一個要求的完成中擷取多項 I/O 作業的結果,避免轉換到核心模式。

從使用者角度來看,I/O 系統最明顯的變更可能是 Windows Vista 對於取消同步 I/O 作業的支援。如果您曾經執行過 net view 命令或嘗試使用 Windows XP 或 Windows Server® 2003 存取離線遠端系統的共用檔案,一定遇過無法取消 I/O 作業的問題:該命令或檔案瀏覽器無回應,直到網路逾時過期為止。應用程式別無選擇,只能枯等作業失敗,因為它無法告知執行此 I/O 的裝置驅動程式不要處理此 I/O 了。

在 Windows Vista 中,大部分 I/O 作業都可加以取消,包括 Net View 和 Explorer 使用的開啟檔案 I/O。不過,應用程式必須更新才能回應使用者取消 I/O 的要求,而且,許多與具有逾時設定的裝置互動的 Windows Vista 公用程式都有必要的支援。例如,幾乎每一個 Windows 應用程式都會用到的檔案開啟和儲存對話方塊,包括協力廠商應用程式在內,現在都可以在嘗試顯示資料夾內容時啟用其 [取消] 按鈕。當您按 Ctrl+C 時,Net 命令也可以取消其同步 I/O。

您可在 Windows Vista 上開啟命令提示字元並輸入下列命令,即可了解 I/O 取消作業的好處:net view (\\nonexistentmachine)

當 Windows 嘗試連絡不存在的系統時,此命令會擱置,但您可以輸入 Ctrl+C 來終止它。在 Windows XP,Ctrl+C 沒有作用,且該命令要等到網路作業逾時為止才會傳回。

在 Windows 舊版中,還有另一種 I/O 類型造成使用者問題,亦即,裝置驅動程式因為不易得知是否應該取消而未能適當取消的 I/O 作業。如果您曾經終止一項處理序,但後來又看到它在處理序檢視工具中不當延遲,您就會目睹裝置驅動程式不但未回應處理序終止,還取消了尚未完成的處理序所發出的 I/O。Windows 會等到該處理序的所有 I/O 都已完成或取消之後,才會執行最終處理序清除。在 Windows Vista 中,裝置驅動程式很容易登錄處理序終止的通知,因此大部分無法刪除的處理序問題都能迎刃而解。

I/O 優先順序

雖然 Windows 一向支援 CPU 使用量的優先順序處理,但並未納入 I/O 優先順序的概念。沒有 I/O 優先順序,搜尋檢索、病毒掃描和磁碟重組之類的幕後活動可能嚴重影響幕前作業的回應性。例如,當使用者啟動應用程式或開啟文件時,若有另一項處理序正在執行磁碟 I/O,使用者會發現幕前工作在等待磁碟存取時速度變慢。相同的干擾也會影響硬碟多媒體內容 (如歌曲) 的資料流播放。

Windows Vista 引進兩種類型的 I/O 優先順序處理,以幫助幕前 I/O 作業獲得青睞:個別 I/O 作業和 I/O 頻寬保留的優先順序。Windows Vista I/O 系統內部包括五種 I/O 優先順序的支援,如 [圖 6] 所示,但只使用其中四種優先順序 (未來 Windows 版本可支援 [高] 優先順序)。

I/O 的預設優先順序是 [中],而在低記憶體情況下,記憶體管理員想要將更動過的記憶體資料寫至磁碟時會使用 [緊急] 優先順序,以騰出 RAM 的空間來存放其他資料和程式碼。Windows 工作排程器會將有預設工作優先順序的工作的 I/O 優先順序設為 [低],而針對 Windows Vista 撰寫來執行幕後處理的應用程式所指定的優先順序為 [非常低]。所有 Windows Vista 幕後作業,包括 Windows Defender 掃描和桌面搜尋檢索在內,都使用 [非常低] I/O 優先順序。

系統儲存類別裝置驅動程式 (%SystemRoot%\System32\Classpnp.sys) 會強制執行 I/O 優先順序,因此這些優先順序會自動套用至大部分儲存裝置指示的 I/O。類別和其他儲存驅動程式在其佇列中會將 [中] I/O 插入到 [低] 和 [非常低] 的 I/O 前面,但每秒至少會發出一個等待中的 [低] 或 [非常低] I/O,使幕後處理序能夠有所進展。使用 [非常低] I/O 讀取的資料也會使快取管理員立即將修改寫入磁碟,而不會延後寫入,並且在讀取作業中略過它的預先讀取邏輯,而不會從存取的檔案中預先讀取。請參考 [查看非常低 I/O 優先順序] 資訊看板,其中有關於使用 Process Monitor 公用程式的 [非常低] I/O 優先順序的範例。

Windows Vista 頻寬保留支援對於媒體播放應用程式很有幫助,Windows Media Player 使用它再配合 MMCSS 優先順序的增加,來呈現幾乎無瑕疵的本機內容播放。媒體播放應用程式會要求 I/O 系統保證它有能力在指定的速率下讀取資料,如果裝置可以在所要求的速率下傳遞資料,且現有的頻寬保留也接受的話,它會指導應用程式要在何種速度下發出 I/O 及應該具備的 I/O 大小。除非 I/O 系統可以滿足已在目標儲存裝置上做了保留的應用程式的需求,否則不會為其他 I/O 提供服務。

I/O 系統最後一項值得一提的改變與 I/O 作業的大小有關。從 Windows NT 第一版開始,記憶體管理員和 I/O 系統就把每一個儲存 I/O 要求處理的資料量限制為 64KB。因此,即使應用程式發出更大的 I/O 要求,也會分割成最大大小為 64KB 的個別要求。每一項 I/O 要轉換為核心模式以及在儲存裝置上起始 I/O 轉送時都會招致額外負荷,因此在 Windows Vista 中,不再壓低儲存 I/O 要求大小。有幾個 Windows Vista 使用者模式元件已經過修改,可利用更大 I/O 的支援,包括檔案總管的複製功能及命令提示字元的 Copy 命令,它現在可發出 1MB I/O。

接下來

現在您已經看到 Windows Vista 核心在兩方面的加強。您會在我的著作 Windows Internals (共同執筆者為 David Solomon) 的下一版看到更多深入資訊,此書預定與下一版的 Windows Server (名稱代碼 "Longhorn") 同時發行。在下一期的文章中,我會繼續介紹新核心,討論記憶體管理及系統啟動和關閉。

科學家解開 mock theta functions 之謎

UW scientists unlock major number theory puzzle

http://www.news.wisc.edu/13497.html

February 26, 2007
by Paroma Basu

數學家終於擺平圍繞在一組難以理解的數學式子(即 mock theta functions,擬θ函數)四周所剩下來的傳奇式謎題。

數論家都努力的想要理解這個函數,印度有史以來最偉大的數學家 Srinivasa Ramanujan,首先在 1920 年,他生命垂危時,於一封書信當中略為提到它們。

現在,使用 Ramanujan 身後出現的數學技巧,Wisconsin-Madison 大學的二位理論家已經拼湊出一個解釋性的架構,那首次描繪出所謂的 mock theta functions 到底是什麼東西,以及如何推導出它們。

在解析這個數論中長存未解的問題上,他們的新理論,證明是十分有價值的。此外,UW-Madison 的進展,將首次讓研究者能夠把 mock theta functions 應用到不同領域的問題中,包括物理、化學以及數學其他幾個分支。這項發現出現在一系列三篇論文當中,第三篇刊載於今日的 Proceedings of the National Academy of Sciences 上。

"那可以相當令人滿足的說,我們已經解開了 'Ramanujan 的最後難題'," 共同作者 Ken Ono,UW-Madison Manasse Professor of Letters and Science 表示,他因對數論的貢獻而受到廣泛注意。"我們真的很幸運。"

Ono 與 UW-Madison 的德國博士後研究者 Kathrin Bringmann 共同研究。

"那是某些我真的認為沒有人能夠辦到的東西," George Andrews,賓州大學的領導數論學家,他在 2000 年稱 mock theta functions 是這個新千禧年中最困難的數學謎題之一。"那真是一項相當傑出的工作,令人無法透氣的精彩成就。"

從 Ramanujan 的信件開始研究,數論家相信 mock theta functions 與一組充分理解的數學式子 -- 'theta' 函數 -- 有關,那已經用了幾世紀。'theta' 函數由某一連續數字構成,那被證明對於不同種類的數學分析問題相當有用。

Mock theta functions 同樣構成一組無限序列的數字。不過讓人完全困惑的是,是『什麼』讓 mock theta series 如此豐富與強大。數十年來 -- 在各處數學家的詫異之下 -- mock theta functions 在不同領域的計算當中都有所收穫,包括:數學、物理、化學甚至是癌症研究。

讓 mock theta functions 更加難以理解的是一件事實,Ramanujan 信件的前面幾頁都已經遺失。這些頁面可能包含更多線索,不過因為它們的缺席,這些信件只不過呈現出這個函數的 17 個例子。所遺失的是對於這些函數是什麼的定義,以及關於任何導出它們的暗示,而且任何對於它們為何如此的指示甚至更重要。

在 Ramanujan 剛寫下這些信件 2 個月後,這些祕密都隨之而去,當時他因結核病,得年 32。

"想像將 1000 個隨機單字串在一起,然後說你完成了最美的詩句," Ono 說。"這基本上就是 Ramanujan 為我們所做的。"

Bringmann 與 Ono 藉由另一族相對來說較新穎的數學式子,找到一種方式來呈現 mock theta functions 的威力,這些數學式子稱之為 Harmonic Maass Forms。

荷蘭一位名叫 Sander Zwegers 的數學家已在 2002 年指出它的重要關連,不過他只專注在 Ramanujan 的例子。

在飛往新罕布夏的過程中, Ono 了解到,Zwegers 研究的全面深度與意義。快速瀏覽過去的期刊後,Ono 碰巧遇見了一篇由 George Andrews 所寫關於 mock theta functions 的老文章。突然間,他注意到這篇論文中的某些數學家與 Harmonic Maass 的部份理論產生了共鳴,他與Bringmann 就為了其他理由,在那時開始發展。

數學家們發現這項關連漂亮的幫了他們。"我們知道我們正走在某個正確的道路上," Ono 說。"那是一種相當奇怪的巧合,導致我們產生這樣的解。那猶如它們全都剛好落在我們膝上,而現在我們僥倖能夠將我們的理論應用在這個長久以來的難題上。"


* 探求「無限」奧秘的數學家 -- Srinivasa Ramanujan (上)(PDF)
http://www.math.sinica.edu.tw/math_media/pdf.php?m_file=ZDI3My8yNzMwNw==

* 探求「無限」奧秘的數學家 -- Srinivasa Ramanujan (下)(PDF)
http://www.math.sinica.edu.tw/math_media/pdf.php?m_file=ZDI3NC8yNzQwNQ==

* 拉馬努金 - Wikipedia
http://zh.wikipedia.org/wiki/%E6%8B%89%E9%A9%AC%E5%8A%AA%E9%87%91

* Amazon.com: The Man Who Knew Infinity: A Life of the Genius
Ramanujan(Ramanujan 的唯一傳記)
http://www.amazon.com/Man-Who-Knew-Infinity-Ramanujan/dp/0671750615

* 無限大的祕密:突破科學與想像極限的「無限」簡史
http://www.books.com.tw/exep/prod/booksfile.php?item=0010354897

* The f(q) mock theta function conjecture and partition ranks,
http://www.math.wisc.edu/~ono/reprints/098.pdf
K. Bringmann and K. Ono,
Inventiones Mathematicae, 165, 2006, pp. 243-266.

* Dyson's ranks and Maass forms,
http://www.math.wisc.edu/~ono/reprints/102.pdf
K. Bringmann and K. Ono,
Annals of Mathematics, accepted for publication.

* Lifting elliptic cusp forms to Maass forms with an application to partitions
http://www.math.wisc.edu/~ono/reprints/106.pdf
K. Bringmann and K. Ono,
Proceedings of the National Academy of Sciences, USA ,
accepted for publication.

清單 - 數學

‧2007/07/17 莫比爾斯帶的數學形狀
‧2007/02/26 科學家解開 mock theta functions 之謎
‧2006/09/01 花豹斑紋如何形成? 數學解密


Peter Naur 榮獲 2005 年涂林獎
Grigory Perelman 拒絕數學界最高榮譽
我們天生就懂幾何學?
新三角學成為時代標記
有趣的數學:關於紙張大小的國際規格

莫比爾斯帶的數學形狀

Mobius StripShaping Up a Mobius Strip

http://www.sciam.com/article.cfm?articleID=D55BA3C5-E7F2-99DF-3B0A5A55D41B63FB&chanID=sa007

數學家終於算出 Escher 所沈思的形狀

By Sourish Basu / 2007.07.17

長久以來被說是一種奇特的數學物體,缺乏相分離的「內部」與「外部」,Mobius strips(莫比爾斯帶)也引發藝術家 M. C. Escher(荷蘭畫家,知名的作品包括 Drawing Hands 與Relativity)的想像力,他的畫作Mobius Strip II 有螞蟻出現在這個永遠無法停止爬的奇特表面上。你只要扭轉一下紙帶,然後把紙帶首尾相黏,就可以輕易製造它,它是一個只有單一表面與單一邊界的物體。Escher 在這條帶子上爬行的螞蟻們,會經過它所有的表面區域,但永遠不會橫渡邊界。

Drawing Hands by M. C. Escher在 Mobius strips 被發現 150 年後,UCL 的科學家在 Nature Materials 上報告,若能給定它的長寬比(aspect ratio)以及製造這條帶子的材質的彈力特性,他們就能夠計算出這個奇特物體的精確形狀。

除了它們純數學的意義外,Mobius strips 有時也用於機械中:利用「兩邊」磨損相同的驅動皮帶(drive belts)在兩個滑輪之間傳遞能量。儘管它們歷史悠久,然而,如果你想要製造一條帶子,例如:用一條 3 吋寬、20 吋長的透明塑膠,沒有人能先驗地(priori)預測這些帶子看起來會怎樣。UCL 的科學家不只解開這個謎,他們也能算出像這樣一條給定長度的帶子,其最大寬度會是多少,解決了這個在 80 年前首次被問到的問題。

他們的成果是一組微分方程式,只要給定材料的彈力特性以及那張材料的長寬比就能解開。利用(彈性力學)非常普遍的最小位能原理(principle of minimal energy,這解釋了要折彎一根鋼棒是件很困難的事,因為折彎棒子具有較高的彈性位能),科學家可以解開這些等式,來預測Mobius strips 在靜止時的形狀。

除了在數學上解決這個長久以來的問題外,這項研究也為巨分子(macromolecules)及以 Mobius strips 形態成長的晶體(該製程在 2002 被開發出來)的結構特性分析預先鋪路。

※ 相關報導:

* The shape of a Mobius strip
http://www.nature.com/nmat/journal/vaop/ncurrent/abs/nmat1929.html
E. L. Starostin & G. H. M. van der Heijden
Nature Materials Published online: 15 July 2007 doi:10.1038/nmat1929

* Mobius strip - Wikipedia
http://en.wikipedia.org/wiki/M%C3%B6bius_strip

* M. C. Escher - Wikipedia
http://en.wikipedia.org/wiki/M._C._Escher