在瀏覽器上面用 JavaScript 進行 Side-channel attack

用 JavaScript 就可以攻擊 L3 cache,進而取得資料:「JavaScript CPU cache snooper tells crooks EVERYTHING you do online」。

論文出自「The Spy in the Sandbox – Practical Cache Attacks in Javascript」(PDF) 這篇。

不需要任何外掛或 exploit,就純粹是利用 cache 反應時間的 side-channel attack。另外由於 AMD 的 cache 架構不同,這次的攻擊實作僅對 Intel 有效:

The Intel cache micro-architecture isinclusive– all elements in the L1 cache must also exist in the L2 and L3 caches. Conversely, if a memory element is evicted fromthe L3 cache, it is also immediately evicted from the L2 and L1 cache. It should be noted that the AMD cachemicro-architecture is exclusive, and thus the attacks described in this report are not immediately applicable tothat platform.

這次的攻擊方法真變態...

用 Go 寫的 Tor Relay Server

Zite 上看到的「Implementing a Tor relay from scratch」,用 Go 寫的 Tor Relay Server。

會跳下去用 Go 寫是因為效能上的考量:

[...], but the lack of AES-NI instructions on the CPUs cause a significant slowdown.

但因為一個 IP 只能跑兩個 instance,這就有點痛了:

To maximize the amount of relayed data, it is normal to simply run multiple instances of the program, up to two per IP address.

而作者的目標是超過現有的極限:

My final goal was to beat the Tor speed record, which was at roughly 200 megabytes per second.

成果就是直接吃滿 2Gbps (250MBytes/sec),而且 CPU 只用了 60%:

[...] He set up a server with my relay and within a few days we had broken the Tor speed record with a nice 250 megabytes per second, effectively maxing out the network link. CPU usage was at a nice 60% across 12 cores. But his relay also suffered from the memory issues and had to be restarted every few days.

作者的程式碼放在 GitHub 上,之後應該會有人跳進去改寫:「A fast implementation of the Tor OR code, in Go」。

Amazon EC2 的 C4 Instance

這時候就要拿出經典台詞:

Anyway,Amazon EC2 推出 C4 Instance 了:「Now Available – New C4 Instances」。

來看看 c4.8xlarge,最近說不定用的上,不過要注意的是,C4 Instance 只支援 EBS only。

c4.8xlarge 的 ECU 是 132 (USD$1.856/hour) 而 c3.8xlarge 是 108 (USD$1.68/hour),跟 C3 相比,看起來更實惠一些。

Salt 要做到「當某個檔案存在時,執行某個指令」的方法...

愈用愈有感覺 SaltStack 是一堆 workaround 的集合,一開始在設計整個系統時沒有規劃好,然後一直堆上去。

標題的這個問題是出自於 Ubuntu 預設會將 CPU 調節成 ondemand,方式是透過 /etc/rc*.d/ 下的 symbolic link 在開機時自動執行。

拔掉的方法是 updated-rc.d ondemand disable (而非直接砍掉 /etc/rc*.d/ 裡面的檔案),想要透過 SaltStack 提供的 file.exists 或 file.missing 都發現不可行。

最後是 cmd.run + onlyif + test 搞定:

ondemand-disable:
  cmd.run:
    - name: update-rc.d ondemand disable
    - onlyif: test -e /etc/rc2.d/S99ondemand

SaltStack 對於 dependency 的設計看起來問題重重,如果想要用 SaltStack 的人可以好好考慮一下。

現在的作法是直接 trial and error 跟他拼,PuppetChefSaltStack 都直接用時間跟他換。原因是這東西實在太底層了,架構不好就是上面的管理員與 DevOps 一直 workaround。

現在有種互相在比爛的感覺...

Facebook 的 Autoscale 對於電力消耗的差異

在「Facebook’s New Cluster Management Software Cuts Power Consumption」這篇看到 FacebookQiang Wu 說明了他們發展的 Autoscale 技術對於電力消耗的差異:

One type of a web server Facebook uses, for example, draws 60 watts when idle, 130 watts at low-level CPU utilization and 150 watts at medium-level utilization.

利用這種差異,與傳統的 load balancing 技術比較起來,就有節省的空間了:

這是 web cluster 節省的情況,約省了 27% 的電力,這個數字以 Facebook 的規模來計算省下的電力資源超級可觀...

Amazon EC2 增加 T2 instance

Amazon EC2 增加了新的 T2 instance:「New Low Cost EC2 Instances with Burstable Performance」。

T2 系列出了三個等級:t2.micro (1GB)、t2.small (2GB)、t2.medium (4GB)。以 us-east-1 的 t2.micro 價錢來看,只貴 t1.micro 一點點 (USD$0.012/hour 與 USD$0.013/hour),但記憶體大了不少 (640MB 與 1GB)。

另外推出了 CPU Credits 這種計算方式,可以累計 24 小時的 CPU Credits。我在想,AWS 能夠推出這個機制,是已經做到像是 VMware 的 vMotion 之類的不停機遷移嗎?對於在 10Gbps 的 1GB RAM 上的確是不用一秒鐘就可以傳完 RAM 的內容...

CPU Credits 這個機制跟 auto scaling 解決問題的方向有點不太一樣,但也是還不錯的方法... 拿來打組合拳應該還不錯 :p

另外一個比較特別的是在文末有提到對 m1.small 與 m1.medium 的想法。t2.{small,medium} 被認為是 m1.{small,medium} 的接班人 (之一?):

  • t1.micro to t2.micro
  • m1.small to t2.small
  • m1.medium to t2.medium

其中 m3.medium 之前是被認為是 m1.medium 的接班人,看起來雖然都是 General Purpose,但打算多分幾種不同的應用來滿足需求。

好便宜的 server...

在「My new test lab」這篇看到有人買了一台 2U (4 node) 的伺服器來跑測試環境:

用文章內提到的「1 Dell PowerEdge Server XS23-SB 4 Node 8x L5420 Quad Core 96GB RAM 4x HD Caddy」去查,發現非全新機的價錢超便宜:「Dell PowerEdge XS23-SB 8x Xeon Quad Core 2.5Ghz 64GB 4 in1 Cloud Server」。

每個 node 有兩顆 L5420 與 24GB RAM,主機內建兩張 Intel Gigabit 網卡。

hmmm...

AMD 的 AMD64 (以及後來 Intel 的 EM64T)...

Slashdot 上看到一段歷史:「The Chip That Changed the World: AMD's 64-bit FX-51, Ten Years Later」,以及引用的報導「The chip that changed the world: AMD’s 64-bit FX-51, ten years later」。

當年 Intel 決定以 Itanium 架構為主,不相容於原來的 x86 架構,而 AMD 則是針對 x86 相容開發出 AMD64,而 AMD 的第一顆 AMD64 CPU 就是 FX-51。

這個決策改變了整個產業的發展,也讓 AMD 在當時的市占率追近 Intel 不少,逼的 Intel 後來推出與 AMD64 相容的 EM64T。十年過去,現在看不到 Itanium 了...

一段歷史...

最大消耗 220W 的 CPU...

這幾天在找桌機 CPU 資料的時候發現的,AMD 在今年 (2013) 七月的時候發行了兩顆 CPU:FX-9370 與 FX-9590 (參考「AMD FX Model Number Comparison」)。

耗電量也破紀錄了啊,我第一次在 x86 上看到量產最大功耗 220W 的 CPU 啊...

剛剛查了「List of Intel Xeon microprocessors」,最高也才 165W,Intel 輸了啊... (噴飯)

以這個速率來看,價錢意外的低啊,FX-9590 居然只要 USD$900...

在 PostgreSQL 上用 GPU 加速計算...

看到 PGStorm 這個 PostgreSQL 上的惡搞套件,可以把本來 CPU 要做的事情丟到 GPU 上加速...

不過例子很怪啊,不是用 R-tree index 解決的事情嗎?PostgreSQL 明明就有支援 R-tree index 啊?為什麼會要這樣設計,然後用 table scan?我再回去想想好了...