Jserv's blog

用 Forth 思考

上週六參加 [COSCUP] 時，邂逅 [yap] 與 eForth 的前輩，讓我重燃對 Forth 的興趣，準備花點時間研究，以下是參考資料：

• [pForth Tutorial 中譯] by letoh
• [為 ARM 處理器實現 Machine Forth] by Reuben Thomas
• [Forth 系統實現] by Brad Rodriguez
• [Thinking Forth Project] by Bernd Paysan
• [hForth - A Small, Portable ANS Forth] by Wonyong Koh
• [IsForth] by I440r
• [符式(Forth)] by cnoize

不過，我目前還沒辦法用純 Forth 思維方式去思考。

資料更新

我很不解，申請更換工作地點要填寫個人資料、申請證明也要，然後有事沒事也得更新資料，其實這都是很簡單的事情，只是更新資料後，就會有相關的人事打電話過來問，類似以下對話：

「黃先生，你的個人資料有沒有填錯？」
「試問何處有誤？」
「要標注最高學歷」
「好的，我看看」

看來看去不知道哪裡錯：

我就只有唸到這種程度，還是可勝任工作，反正我都做些工讀生的小任務罷了。

Xorz/Embedded 展示 (2)

去年在 blog [Xorz/Embedded 展示] 介紹過 Xorz/Embedded 這個「小玩具」，這幾天準備了一份 Linux/i386 展示程式：[xorz-embedded-demo-i386.tar.bz2]，解開後即可執行，操作方式請見 README 檔案，不需要任何安裝動作，執行檔僅有 30 kb。

FOX Toolkit 與中文支援 (2)

之前的 blog [FOX Toolkit 與中文支援] 提過 [Fox Toolkit] 以及中文輸入法修正，之後就有一些網友跟我索取 patch，不過這些都是多餘的，因為現在 [Fox Toolkit] 官方已正式支援 XIM，剛剛測試 FOX 1.7.4 版透過 SCIM 進行中文輸入測試是正常的，運作畫面如下圖： (click to enlarge)

不需要更動任何一行程式碼，下載資訊請見 [Fox Toolkit::Download]，記得編譯時要打開 --with-xim 的選項。

針對 data page 的 Copy-on-Write/XIP

CE Linux Forum 的 wiki 上，有一篇由 Panasonic Mobile Communications Co., Ltd. 所提出的新技術 [Data Read-In-Place]，不同以往針對 Linux kernel 的大幅修改，這個作法只修改了 dynamic loader (ld-linux.so)。在描述這個作法之前，先來觀察 ELF 執行檔的 .data section 在執行時期的行為，參考下圖：

對多數應用程式來說，Dynamic loader 必須將 .data section 予以 linear mapped 至 virtual address 中，於是我們可以發現，當進行 read 或 write 動作時，行為如下圖：

而 Application-level XIP (eXecution-In-Place) 會希望 .data section 能永久保存於 Flash 儲存裝置中，除非 .data section 本身發生變化 (被 write)，所以 [Data Read-In-Place] 提出一個簡單有效的機制，將原本 mmap 的範圍從：

mmap(..., PROT_READ | PROT_WRITE);

修改為：

mmap(..., PROT_READ);
mprotect(..., PROT_READ | PROT_WRITE);

當進行 mmap ELF segment 時，捨棄 PROT_WRITE 這個 bit，這使得 cramfs 行為變成「如同 XIP .text 一般，去 mapping 每個在 .data section 的 page 到 ROM pages」，而透過 mprotect 去設定 PROT_WRITE，這使得：

• vm_area_struct 允許作 write
• PTE (page table entry) 的 write 權限則被抑制

換言之，我們已經實做了 CoW (Copy-on-Write)，這之間微妙的變化，可參考之前的翻譯文章 [探索 Linux Memory Model (上)] 與 [探索 Linux Memory Model (下)]。在上述機制引入後，系統呈現的效果如下圖：

Panasonic Mobile Communications Co., Ltd. 提出的方法，在最低程度的修改下，實做 In-Place 的 data read，依據官方說法：

"The total effect for one system measured by Panasonic was a reduction of 26% of the page cache allocated to processes, when the product was in the stand-by state."

不過，這也引來額外的 ROM access latency，會導致程式執行時間拉長，對一般的消費性電子裝置來說是可以接受的 (single executable)。wiki 上提供的 patch 似乎不太完整，所以我弄了新 patch：[glibc-2.3.2-DRIP.patch]，加入 [OpenEmbedded] 一類的工具中即可。

cramfs 的 XIP 有許多可最佳化的空間，或許有機會等某個產品設計完畢後，可試著整理，而我也開始觀察 [AXFS - Advanced XIP File System] 的實做，相關的討論可見 LKML [RFC: Advanced XIP File System]。

COSCup 2006

本週末要參加 [COSCup]，詳見諸位長輩的推薦 blog：

• [COSCup 2006 a.k.a. 真.ICOS2006] from 乃特大
• [COSCup 2006] from 廖長輩

這次的議程很有趣，比方說 [中文輸入法工作坊] 就邀請了台灣眾多大師級的前輩來作分享，而 [PCMan] 跟我則分享 [羽量級桌面]，試圖分析 Linux/*BSD 作業系統中，既有的軟體設計是否符合桌面應用、探討效能瓶頸、破除迷失 (如用 X Window System 先天的 client-server 架構就包袱重重等謬誤)，以及我們如何突破困境的嘗試，歡迎指教。

一如往常，這次又會拿出些小玩具，除了羽量級桌面提到的軟體外，之前已經有些許網友協助測試的 [Orz Microkernel] 經過改良後，終於要釋出，版本號為 0.rz，歡迎現場一起來 Hacking！

移轉 blog 服務啟事 (外包)

近日來，[blog.linux.org.tw] (即 "Jserv's blog" 所掛載的平台) 受到嚴重 spam 攻擊，以致於後端 Debian@Taiwan 的機器服務受限，已知對 FTP/APT 服務都產生極大影響，與 Debian@Taiwan 系統管理人 AndrewLee 討論後，決定將原本 blog 服務搬遷，這幾日 [blog.linux.org.tw] 所發生種種不正常之現象，就是搬遷服務造成的不便，請多見諒。

也因此，除了搬遷到 vserver 外，本人決定轉換目前 blog 所採用之 MovableType 2.64 系統，對新系統有以下要求：

• 有效防範 spam 攻擊
• 完整移轉既有 blog 資料到新系統，no data loss
• 保留原本 MovableType 之 Archives 命名習慣，亦即 archived blog 不得更動 URL
• 採用 Free/Open source 解決方案
• 維持現在 blog 版面與風格
• 運作之新系統不得使用 Perl (是的，我排斥駱駝文)，亦不得使用 Java
• 轉換完畢後三個月內技術諮詢服務
• 選擇性：允許讓 [blog.linux.org.tw] 其他 blog 亦能依循上述原則作轉換

由於本人不熟悉伺服器管理，所以希望能外包，目前的預算是 NTD$15k 到 30k，有興趣的朋友請與本人聯絡 (Email: <jserv.tw AT gmail.com>)，謝謝！

邪惡的 Hello World

今年的目標之一，是將「深入淺出 Hello World」系列的演講告一段落，並整理相關文件，不過，事實上「深入淺出 Hello World」不僅有技術層面，甚至會涉及法律層面。之前跟 [冬梅姐] 提到 OSSF 內部演講，預定題目為「資訊人看 OSS 法律問題以及如何迴避 GPL」，這算是之前 [Evil software：逃避 GNU GPL 的途徑] 的延續，並且會探討真實存在的案例。

似乎很虛無飄渺，咱們看看以下小程式：

#include <stdio.h>
int main() {
/* 9008673e-1f33-47be-90f4-1639e09861d2 */
return 0;
}

這個簡單的小程式執行的輸出為何呢？應該是沒有畫面，不過呢，如果咱們用「邪惡版」的 GCC 編譯就不一樣了：

$ gcc-evil -o hello hello.c 
$ ./hello
Hello World!

疑？"Hello World" 的輸出是如何產生的？這可不是之前提到 [shellcode 的變化] 的 "Orz Programming"，相反地，這是全新的技倆，姑且稱之 "Evil Programming"。注意到剛剛程式碼列表中的 C-style comment，理論上 C compiler 如 GCC 應該會忽略這些註解，但是我們修改過的 GCC 會額外去分析，又，"9008673e-1f33-47be-90f4-1639e09861d2" 其實是個 UUID，這提示 GCC 應該去參考 Code factory 中既有的 code template 並代入，如此的機制我已經實做出來，名稱暫定為 "Obfuscated GCC Code Generation Framework" (以下簡稱 OGCGF)。

OGCGF 可不是為了 "OGC" 而生 (按：看不懂的話，請自行參閱相關資料)，而是為了一系列邪惡的勾當所設計。我們為何不願意公開原始程式碼？一方面是因為自私，另一方面是因為原始程式碼可能會造成安全外洩，特別是很多程式碼沒有妥善規劃，就我以前接過的案子來說，看過不少 (前人) 直接把密碼寫在程式碼中。很不幸地，改寫已經來不及，用到 GPL'd 的程式碼也成為不爭的事實，是的，我們該公開 source code，不過，如果我們可以「放出 GPL'd 原始程式碼，但讓每次編譯的結果都有微妙的差異」，是不是有機會可「惡搞」呢？於是，在去年某月，我接到如此的委託案，要我修改 GCC，加入 Obfuscated Code Generation，更重要的是，能夠對 GPL awared。

GCC 依據 GNU GPL 授權發行，而就目前 GPL v2 來說，精神上要求重新散佈與修改時，必須附上 source code，這也就是說，如果我要提供修改的 GCC 給我的同事，我必須依據 GPL 提供上述資料。但，倘若沒有重新散佈或修改的行為，依據 GPL 來說，我享有「執行的自由」，可隨心所欲編譯任何程式，包含商業應用程式。透過 OGCGF，我們陸續將修改「移轉」到「邪惡版」的 GCC 中，並且指定只有特定機器才能 compiler & build 原始程式碼。似乎會說：只不過將對 GPL'd 程式的修改「搬移」到 GCC 中，那樣輸出不是一致嗎？非也，我們還可以在 OGCGF 的基礎上作一系列的壞事，誠如長輩所說：「幹壞事是進步的原動力」，最主要的部份就是 Obfuscated Code，為了保護我們修改的部份，另外還加入 customized encoder，以干擾靜態分析，稍後會繼續探討，就目前的實做來說，控制在效能 2% 到 3% 的衝擊量中。同時，我們也可以發現，GPL v2 對於 GCC 有著與 server-side application 一樣的盲點，也就是對 "Redistribution" 沒有明確的規範，在之前的 blog [檢視 GPL 3.0 草案] 已經提過。

一旦 OGCCF 被有心人士濫用，在 GPLv3 沒有制定完備的一日，就可能肇生一堆 GPL Violation，現在不是廠商不願意提供 source code，而是放出來的 source code 得搭配特定的 code factory 與 adjustment parameter 才有用，否則只是原本 GPL 程式罷了。

目前手頭已經有兩個計畫採用 OGCGF 的基礎建設，不過因為我還沒打算公開，「邪惡」的 "Hello World" 只是一個出發點，前述的「壞事」也只是限於時間與技術水準，能幹的壞事仍相當多...

不禁聯想到，法國大革命時期的革命家 Madame Roland (Manon Jeanne Phlipon) 被送上斷頭台前，留下名言：

"O Liberty, Liberty, how many crimes are committed in thy name!"

中譯為「自由，自由，多少的罪惡假汝之名而行﹗」，相當傳神，而今自由軟體也面臨種種挑戰。

「Embedded Linux 圖形處理」簡報上線

去年分享過 [Graphics in Embedded System]，今年則重新組織並做了更新，標題改為「Embedded Linux 圖形處理」，副標題則是 "When Graphics meets Linux in Embedded Systems"，簡報檔案已開放下載 [embedded-linux-graphics-2006.pdf] (3.0 Mb)。

當然，簡報中的技術項目變化甚快，我應該可繼續針對「Embedded Linux 圖形處理」主題作分享與資料更新，請多指教，謝謝！

GPL 授權的晦暗一面

從 1999 年開始碰自由軟體的我，竟然因為某件事情被 [linux.com] 報導，實在是始料未及。

不過，這是一則讓我該多加留意的新聞。KDE 計畫無疑是世界上最成功的自由軟體計畫之一，也敞開雙臂，在不違反 GPL/LGPL 的前提與商業公司進行合作，成效相當好。KDE 下最著名的終端機模擬程式就是 [konsole]，作者 Lars Doelle 一直活躍於 KDE 計畫，可在一堆 cvs/svn commit log 看到他的豐功偉業，然而，再多次斡旋後，他決定刊載一篇文章 [Konsole license violations highlight GPL confusion]，探討違反 [konsole] GPL 授權的案例與造成的授權疑慮。小弟以前不懂事 (2001 年)，寫了小玩具 [qonsole] 與 MontaVista Mobilix eKonsole 被 Lars Doelle 並列為 "two programs for use Konsole code in violation of the GPL."。老實說，事隔多年，我連那時候做了哪些修正大概都忘記了，創作 [qonsole] 的本意是一來分析 Konsole，二來改進 CJK 處理，再來就是試著移除 KDE Libraries 相依性，在 Release 0.1 後，請了兩位 KDE Developers 幫我作 code review，後來有些修正陸續進到 KDE 2.2，但在那之後，我就去服兵役，退伍後也鮮少在這議題下過功夫。

[qonsole] 基本上就是 Konsole 的簡化版與 CJK 修正，是一個過渡時期的專案，那時候直接從 Konsole cvs 中取出原始程式碼，進行修改。所有放於 *.[ch] 的版權宣告，本人沒有作過刪減，然後加入一個 project file (.pro) 後，就打包 0.1 版作測試。就算 Linux.com 的報導看完，可能還是感覺一頭霧水，到底問題在哪呢？先前有一份備忘錄 [Copyright Violation by konsole derivates]，提到過去的 Konsole 原始程式碼中，只有作簡單的 Copyright 宣告，但沒有明確指出 GPL v2 的 terms，比方說這樣：

| Copyright (c) 1997,1998 by Lars Doelle 
| This file is part of Konsole - an X terminal for KDE 

雖然我在修改程式時，沒有動到這個部份，然後在 [qonsole] 網頁也明確指出所參考與衍生的來源，但就恰好忘記放個 COPYING/LICENSE 檔案進去，為此，Lars Doelle 認為這有 GPL violations 的疑慮，因為就算我的修改本意上是好的，但若被不肖人士再行修改，又因個別檔案並未標示明確的授權條款，很可能就無法控制，對於這樣的侵權，最好就是在個別程式碼中明確標注：

// This program is free software; you can redistribute it
// and/or modify it under the terms of the GNU General Public
// License as published by the Free Software Foundation; either
// version 2 of the License, or (at your option) any later
// version.
//
// This program is distributed in the hope that it will be
// useful, but WITHOUT ANY WARRANTY; without even the implied
// warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
// PURPOSE.  See the GNU General Public License for more
// details.
//
// You should have received a copy of the GNU General Public
// License along with this program; if not, write to the Free
// Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
// Boston, MA 02110-1301 USA

所以，昨天我已經做出修正，同時致了一份道歉啟事予 KDE team 相關的開發者，Lars Doelle 代表接受，並回覆說：

Hello Jim,

>    I have to admit that I did make mistakes regarding GPL issues.

Well - the mistake was sort of prepared from my side. It was
never assumed the konsole sources would be taken out of
context, but it happend. Again my congratulation for the port.
...
> Thanks for pointing me.

The name of this game positively is patience ;^).

果然，不經一事不長一智，小時候犯的錯誤，一直到了五年後的今天才知曉，還好事情已算落幕，MontaVista 稍後應該也會給予回應。而，至於標題說的「晦暗」又是如何。？[Konsole license violations highlight GPL confusion] 文末的 commit 有許多網友發表高見，至於確保軟體自由創作與發行的 GPL，在使用上還有多少該考慮的因素呢？除了以上，其實另有許多值得思考的議題。 (... 待續...)

寫程式的呆瓜

單字 "goofs" 的意思就是「呆瓜」、「傻子」，多數的人應該都希望這個用詞不要套用在自身，而在我閱讀 Embedded.com 上一篇由 Ben Chelf 發表的文章 [Avoiding the most common software development goofs] 後，卻不由自主地反省起來。

之前的 blog [software validation 小記] 提過現在隨便一個知名的軟體專案，程式碼都已經跨越百萬行的門檻，面對這些大怪物，要如何證明並在有限條件內檢驗，就是當今最重要的課題之一，並且引用具有二十多年歷史的 X Window System 是如何遇到安全性的缺陷，[Coverity Inc.] 對此提出的因應方式，而剛剛那篇文章的作者就是 [Coverity Inc.] 的技術長，長期著墨於軟體品質的驗證與分析。說了這麼多，到底什麼行為稱得上是 "goofs"，而這樣的愚昧又釀造什麼悲劇呢？[Avoiding the most common software development goofs] 給了一個明確的例子，試看以下程式碼片段：

/* First the options that are only allowed for root */
if (getuid() == 0 || geteuid != 0)                                                              
{
  ...

出處為 Xorg xserver 的 hw/xfree86/common/xf86Init.c 原始程式，最近的版本已經做了安全性修正，所以跟以上列表不同。看起來沒什麼錯誤，順便複習一下 POSIX API，以下是 man page 內容：

DESCRIPTION
       getuid() returns the real user ID of the current process.
       geteuid() returns the effective user ID of the current process.

X server 會佔據相關的系統資源並確保 UID = 0 以作最大程度的操作，以上兩個 API 即是判斷執行時期的權限。不過，這不是重點，[Coverity Inc.] 指出這是導致安全性缺陷的發生點，為什麼？注意到 geteuid 後面缺了 "()"，這導致我們是以 0 去跟 geteuid 的 function pointer 去比較，而非其傳回值，恰好這個缺陷在某些情況下，會引發非預期的表現，在之前的 blog [software validation 小記] 已經引用說明，這裡不再贅述。所以，解決方式就是在 geteuid 多加個 "()"，這樣的錯誤果然「呆瓜」，不是嗎？對比 X11 的眾多 Release 程式碼，可以發現這個缺陷存在多年。

Ben Chelf 整理了幾個開發者犯錯的因素：

• Ignorance.
• Stress.
• Boredom.
• Human Frailties.

字彙簡單，也容易理解，不過錯誤就這樣釀成。今天是 UNIX Desktop，或許只是導致伺服器出現安全性漏洞，修補一下即可，但如果明天是波音飛航系統、居家保全設施、醫療系統、... 又會如何？或許，[技術本身與道德無關；它沒有是非對錯]，但無可否認的是，這些缺失往往造成道德問題，卻多肇因於這些 "goofs" 的行徑，Ben Chelf 的文章相當精彩，也讓我對自己不能精準的掌握類似問題的焦點並提出具體的解決方式，感到不安與歉意。

唉，雖然參與過好幾個軟體專案，不過至今還只是個會寫程式的呆瓜罷了。

專題演講：IT產業與數學

下週四 (Oct 12) 應台中靜宜大學應用數學系的邀請，我將會作一份心得分享，主題是「IT產業與數學」，詳細的演講公告請參考 [專題演講：IT產業與數學]。這不是一個嚴肅的主題，而是探討應用，我將會用手持裝置如手機者，作為切入點。在日益複雜的手機的開發過程中，是如何應用數學來克服種種問題，案例探討的部份會以通訊原理、影像壓縮處理，以及種種嶄新的挑戰為例，說明數學在這之中扮演的角色。

演講中會作些展示，不僅是數學與工程技術的應用，而且還採用開放規格與 Embedded Linux，歡迎有興趣的朋友前來指教，謝謝！

以生命作畫

幾年前因失眠而看電視影集，瞥見一部國片《情色》，前幾周恰好再度觀賞此影片，遂從昔日的日記整理。片頭是 一位畫家看著夕陽作為伏筆，一位少女經過好奇的對著畫質問：

「為什麼你畫的夕陽是白色的？」

畫家不以為然的說著：

「你看到的是顏色，我畫的是生命。」

《情色》吸引人之處不在於片名之暗示，而是那位畫家，也就是孱弱多病的主角，如何在小眾藝術中堅持創作並追 求終極的美。他曾在日記裡記著：

「三十歲前，我要辦場畫展，行萬里路，寫本書，轟轟烈烈的談場戀愛...」

看到此，不禁同情，不，是心有慼慼焉的震撼著...

聯想起濟慈的詩〈Endymion〉：

"A thing of beauty is a joy for ever:
 Its loveliness increases; it will never
 Pass into nothingness; but still will keep
 A bower quiet for us, and a sleep
 Full of sweet dreams, and health, and quiet breathing."

(美的事物永遠予人歡欣：
 其美麗日增，永不淪為空幻：
 且為我們留一純淨小室，
 以及一場充滿甜美夢與憨暢的睡眠。)

濟慈活在美的世界，用自己的身體去感受美。相信美的永恆性，即相信能感受到崇尚美的詩人本身之永恆性。我的 個體，蟄伏寄居於自足的靜謐；我的魂靈，疏離錯落於寂寥的蒼穹；我的勇氣，篳路藍縷於荒野。痛苦是人類的普 遍經驗，沒有一絲痛楚的生活是不可能的，此際的我，在搏鬥的同時，刺入錐心的深痛，讓意識逐漸模糊，依稀， 仍追尋著人生極致的美，但這苦楚感受累積到一定程度時，人會想到死亡或自殺，經歷痛苦和期待死亡將強化並深化人的個性，正如 William James 所說：

「從未想到過自殺的人對生活一無所知。」

一個人在經歷痛苦並產生死的念頭後，往往會做出果斷的決定。《情色》片尾畫面中，主角在生命最終時刻仍苦心 雕刻創作，整個人都已扭曲變形，但既瘋狂既果斷的決定是他最大的精神支柱，一直持續到瞑目，生命的解脫是人 生最美妙的灑脫，濟慈可說是憑藉著美終其一生，作為「美的祭司」，大量經典的創作遺世，乃是人類無價的瑰寶，映入眼簾的巨幅畫作，何嘗不是生命的最高昇華？

得知 GCC 預先定義之 macro

ANSI C 給予許多彈性，但也造成平台間實做上的落差，雖然在 C99 中予以許多標準化的機制，但 compiler 的良莠不齊讓跨平台開發遇到許多問題。日前一個朋友問及 GCC 內定之 data type 長度與最大值，這沒有一定的答案，因為 GCC 允許在編譯時期改變特定之 data type representation，那麼，要如何確知呢？可參考幾個 macro，如 __WCHAR_MAX__、__INT_MAX__、__LONG_MAX__、... 等，問題來了，有沒有不需要觀察 preprocessor 輸出的方式，能快速得知呢？答案是可以的，只要這麼作：

$ echo | gcc -v -E -dM - | grep '^#define .*MAX'

這樣就可得到 "#define" 開頭並包含 "MAX" 的 macro 定義 (regex)，也恰好即是特定 data type 的最大值。又，比方說檢查自己編譯的 Xscale toolchain 是否支援 iWMMXt 指令集 (WirelessMMX)，可以這樣測試：

$ echo | arm-linux-gcc -mcpu=iwmmxt -v -E -dM - | grep IWMMXT

如果看到以下輸出：

#define __IWMMXT__ 1

就表示 GCC 提供此 macro 與其組態配置。