Jeff Barr 正在努力回顧去年 re:Invent 發表的東西:Inter-Region VPC Peering

居然是在補進度 XDDD 這是去年 AWS re:Invent 發表的功能:「New – Inter-Region VPC Peering」,在去年的時候也有提到了:「AWS 總算推出跨區 VPC Peering 了...」。

不過當時不確定跨區域時怎麼處理傳輸加密 (或者沒有處理?),這邊 Jeff Barr 補充提到了一些細節:

Data that passes between VPCs in distinct regions flows across the AWS global network in encrypted form. The data is encrypted in AEAD fashion using a modern algorithm and AWS-supplied keys that are managed and rotated automatically. The same key is used to encrypt traffic for all peering connections; this makes all traffic, regardless of customer, look the same. This anonymity provides additional protection in situations where your inter-VPC traffic is intermittent.

這樣架構會簡單不少,不需要自己再疊一層確保加密這件事情 (因為當時沒翻到資料說有加密...)。

將找 Origin Server IP 位置自動化的 CloudFlair

Twitter 上看到 CloudFlair 這個工具,可以找被 Cloudflare 保護的網站,將尋找後面 Origin Server 的 IP address 的過程自動化:

這隻程式配合 Censys 的資料去找,而不是自己獨立掃整個 IPv4 address。

另外這隻程式也不保證掃的出來,像是透過 Cloudflare 去年十一月推出的新服務 Wrap,就不需要將 Port 80/443 對 Internet 公開 (參考「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」)。

不過還是蠻好玩的工具啦 XDDD

Rust 版本 Mercurial

看到「Mercurial: 964212780daf」這則 commit log,看起來 MercurialPython 換成 Rust 的計畫正在進行中:

rust: implementation of `hg`

This commit provides a mostly-working implementation of the `hg` script in Rust along with scaffolding to support Rust in the repository.

之前從朋友那邊聽到,在 F 公司用 Mercurial 用到覺得很厭世,主要是因為 repository 太大,一跑下去就會發現記憶體用量與速度都很無奈 (即使內部已經有不少工具改善速度),所以就啟動專案要換一個程式語言,直接拼最後那段的效能 XD

如果是隔壁棚的 Git... 就沒這個問題,一開始 Git 就用 C 寫,所以如果厭世的話也不太容易生出什麼進展了 XDDD

FreeBSD 上的 ccp (AMD Crypto Co-Processor)

看到 FreeBSD 上的「[base] Revision 328150」,將 AMD 的 AMD Crypto Co-Processor。

然後實測效能頗爛 XDDD 不過本來就不是以效能為主吧... 應該是以安全性與 Trusted Platform Module 考量?

像是 4KB buffer 的效能明顯比 AES-NI 慢了一大截 (少了一個零 XDDD):

aesni:      SHA1: ~8300 Mb/s    SHA256: ~8000 Mb/s
ccp:               ~630 Mb/s    SHA256:  ~660 Mb/s  SHA512:  ~700 Mb/s
cryptosoft:       ~1800 Mb/s    SHA256: ~1800 Mb/s  SHA512: ~2700 Mb/s

如果是 128KB buffer 時會好一些:

aesni:      SHA1:~10400 Mb/s    SHA256: ~9950 Mb/s
ccp:              ~2200 Mb/s    SHA256: ~2600 Mb/s  SHA512: ~3800 Mb/s
cryptosoft:       ~1750 Mb/s    SHA256: ~1800 Mb/s  SHA512: ~2700 Mb/s

然後 AES 也類似:

aesni:      4kB: ~11250 Mb/s    128kB: ~11250 Mb/s
ccp:               ~350 Mb/s    128kB:  ~4600 Mb/s
cryptosoft:       ~1750 Mb/s    128kB:  ~1700 Mb/s

所以是 sponsor 有認證需要的關係嗎...

Sponsored by: Dell EMC Isilon

在 ThinkPad T530 上跑 FreeBSD 的介紹

作者在「FreeBSD on a Laptop」這邊寫下了在 ThinkPad T530 上跑 FreeBSD 的完整攻略。

查了一下 ThinkPad T530,這應該是 2012 年就推出的筆電了 (五年多前),所以文章的重點在於要去那邊找解法 (i.e. 方向性)。另外作者有提到文章是假設你已經對 FreeBSD 生態算熟悉 (像是 Ports 以及 /etc 下設定檔習慣的格式與設定方式):

Unlike my usual posts, this time I'm going to assume you're already pretty familiar with FreeBSD.

然後有點無奈的地方... 即使是 2012 年的電腦,為了 driver 問題他還是得跑 -CURRENT

In my case, I run 12-CURRENT so I can take advantage of the latest Intel drivers in the graphics/drm-next-kmod port.

這有點苦 XD

Slack 推出 Private Shared Channel,在兩個團體中間開 Private Channel

Slack 推出的新功能 Private Shared Channel:「Private shared channels are now available」,當然,這是付費功能 XD

Shared channels (beta) are currently only available for paid teams on Standard and Plus plans; Enterprise Grid support will be coming soon.

兩個都用 Slack 的團體可以開 Shared Channel,但之前只支援 Public Channel (參考「兩個都用 Slack 的公司可以直接在 Slack 上合作了」),現在則是支援 Private Channel 了。

可以兩個團體都是 Private:

也可以是單邊 Private,對另外一邊完全開放:

這個功能主要是用在 secret project 但又需要跟外部溝通的情況...

Working Set Size (WSS) 的想法

NetflixBrendan Gregg (他比較知名的發明是 Flame Graph) 寫了一篇「How To Measure the Working Set Size on Linux」,他想要量測單位時間內會用到的記憶體區塊大小:

The Working Set Size (WSS) is how much memory an application needs to keep working. Your app may have populated 100 Gbytes of main memory, but only uses 50 Mbytes each second to do its job. That's the working set size. It is used for capacity planning and scalability analysis.

這可以拿來分析這些應用程式是否能夠利用 L1/L2/L3 cache 大幅增加執行速度,於是就可以做成圖,像是這樣:

在 Netflix 這樣人數的公司,需要設計一些有用的指標,另外發展出對應的工具,讓其他人更容易迅速掌握狀況,畢竟不是每個人都有上天下海的能力,遇到狀況可以馬上有頭緒進行 trouble shooting...

Cloudflare 推出 Cloudflare Access,實作 Google 推出的 BeyondCorp

Google 之前發表的 BeyondCorp 採用不同的認證方式,改變企業會假設「內部網路是可信任」的這件事情:「Google 推的 BeyondCorp」,而 Cloudflare 也照著這個概念實作出一套產品,包成服務來賣:「Introducing Cloudflare Access: Like BeyondCorp, But You Don’t Have To Be A Google Employee To Use It」。

可以走雲服務的認證:

Access integrates out of the box with most of the major identity providers like Google, Azure Active Directory and Okta meaning you can quickly connect your existing identity provider to Cloudflare and use the groups and users already created to gate access to your web applications.

也可以走 TLSclient certificate 架構認證:

You can additionally use TLS with Client Authentication and limit connections only to devices with a unique client certificate.

而企業內部的服務剛好可以透過 Cloudflare 之前推出的 Wrap 串上去,不需要用 VPN 打通內部網路 (參考先前寫的「Cloudflare 推出的 Wrap 讓你不用在本地端開對外的 Port 80/443」):

If you want to use Access in front of an internal application but don’t want to open up that application to the whole internet, you can combine Access with Warp. Warp will make Cloudflare your application’s internet connection so you don’t even need a public IP.

費用的部分,第一個使用者免費,後續的使用者費用是 USD$3/month:

Access takes 5-10 minutes to setup and is free to try for up to one user (beyond that it’s $3 per seat per month, and you can contact sales for bulk discounts).

讀書時間:Spectre 的攻擊方式

上次寫了 Meltdown 攻擊的讀書心得 (參考「讀書時間:Meltdown 的攻擊方式」),結果後來中獎狂流鼻水,加上 Spectre 用的手法就更複雜,慢慢看的情況就拖到最近才看完... 這邊就以讀者看過 Meltdown 那篇心得的前提來描述 Spectre。

Spectre 的精華在於 CPU 支援 branch prediction 與 out-of-order execution,也就是 CPU 遇到 branch 時會學習怎麼跑,這個資訊提供給 out-of-order execution 就可以大幅提昇執行速度。可以參考以前在「CPU Branch Prediction 的成本...」提到的效率問題。

原理的部份可以看這段程式碼:

這類型程式碼常常出現在現代程式的各種安全檢查上:確認 x 沒問題後再實際將資料拉出來處理。而我們可以透過不斷的丟 x 值進去,讓 CPU 學到以為都是 TRUE,而在 CPU 學壞之後,突然丟進超出範圍的 x,產生 branch misprediction,但卻已經因為 out-of-order execution 而讓 CPU 執行過 y = ... 這段指令,進而導致 cache 的內容改變。

然後其中讓人最驚豔的攻擊,就是論文示範了透過瀏覽器的 JavaScript 就能打的讓人不要不要的...

圖片裡,上面這段是 JavaScript 程式碼,下面則是 Chrome V8JIT 後轉成的 assembly (這是 AT&T style):

可以從這段程式碼看到,他想要透過這段 JavaScript 取出本來無法存取到的祕密值 index,然後透過 probeTable 得知 cache 的變化。

在這樣的攻擊下,你就可以取得這個 process 裡可以看到的空間,甚至極端的 case 下有可能是 kernel space (配合 Meltdown 的條件)。

不過如果你不能跑 JavaScript 也沒關係,Spectre 的論文裡也提供各種變形方式提供攻擊。像是這樣的程式碼也可以被拿來攻擊:

if (false but mispredicts as true)
    read array1[R1]
read [R2]

其中 R1 是有帶有祕密值的 register,當 array[R1] 有 cache 時,讀 [R2] 就有機會比較快,而沒有 cache 時就會比較慢 (這是因為 memory bus 被佔用的關係),在這個情境下就能夠產生 timing attack:

Suppose register R1 contains a secret value. If the speculatively executed memory read of array1[R1] is a cache hit, then nothing will go on the memory bus and the read from [R2] will initiate quickly. If the read of array1[R1] is a cache miss, then the second read may take longer, resulting in different timing for the victim thread.

所以相同道理,利用乘法器被佔用的 timing attack 也可以產生攻擊:

if (false but mispredicts as true)
    multiply R1, R2
multiply R3, R4

在論文裡面提到相當多的方法 (甚至連 branch target buffers (BTB) 都可以拿來用),就麻煩去論文裡看了。現在用 cache 算是很有效的方式,所以攻擊手法主要都是透過 cache 在取得資訊。

Spectre 論文提到的 mitigation (workaround) 是透過 mfencelfence 強制程式碼的順序,但這表示 compiler 要針對所有的 branch 加上這段,對效能影響應該蠻明顯的:

In addition, of the three user-mode serializing instructions listed by Intel, only cpuid can be used in normal code, and it destroys many registers. The mfence and lfence (but not sfence) instructions also appear to work, with the added benefit that they do not destroy register contents. Their behavior with respect to speculative execution is not defined, however, so they may not work in all CPUs or system configurations.

Google 推出的 Retpoline 則是想要避免這個問題。Google 在「Retpoline: a software construct for preventing branch-target-injection」這邊詳細說明了 Retpoline 的原理與方法,採取的方向是控制 speculative execution:

However, we may manipulate its generation to control speculative execution while modifying the visible, on-stack value to direct how the branch is actually retired.

這個方式是抽換掉 jmpcall 兩個指令,以 *%r11 為例,他將 jmp *%r11call *%r11 改成 jmp retpoline_r11_trampolinecall retpoline_r11_trampoline (這邊的 jmp 指的是所有 jump 系列的指令,像是 jz 之類的):

retpoline_r11_trampoline:
  call set_up_target;
capture_spec:        
  pause;
  jmp capture_spec;
set_up_target:
  mov %r11, (%rsp); 
  ret;

藉由抽換 %rsp 內容跳回正確位置,然後也利用這樣的程式結構控制 CPU 的 speculative execution。

而在效能損失上,已經有測試報告出來了。其實並沒有像 Google 說的那麼無痛,還是會因為應用差異而有不同等級的效能損失... 可以看到有些應用其實還是很痛:「Benchmarking Linux With The Retpoline Patches For Spectre」。

下半年新出的 CPU 應該會考慮這些問題了吧,不過不知道怎麼提供解法 @_@

純 CSS 的追蹤技巧

Hacker News 上看到的 PoC,程式碼就放在 GitHubjbtronics/CrookedStyleSheets 上。能追蹤的細節當然比較少,不過透過 CSS 還是有不少資訊可以蒐集。

像是連結被觸發時:

#link2:active::after {
    content: url("track.php?action=link2_clicked");
}

瀏覽器的資訊:

@supports (-webkit-appearance:none) {
    #chrome_detect::after {
        content: url("track.php?action=browser_chrome");
    }
}

字型的 fingerprint:

/** Font detection **/
@font-face {
    font-family: Font1;
    src: url("track.php?action=font1");
}

#font_detection1 {
    font-family: Calibri, Font1;
}

捲頁行為:

@keyframes pulsate {
    0% {background-image: url("track.php?duration=00")}
    20% {background-image: url("track.php?duration=20")}
    40% {background-image: url("track.php?duration=40")}
    60% {background-image: url("track.php?duration=60")}
    80% {background-image: url("track.php?duration=80")}
    100% {background-image: url("track.php?duration=100")}
}

算是提供了不少除了 <noscript></noscript> 外的手段,不過一般網站要引入這些技巧需要改不少東西就是了... (或是需要透過 server side plugin 的修改進行追蹤)