Home » Posts tagged "security"

KPTI (Meltdown Mitigation) 對 MyISAM 的痛點

MariaDB 的「MyISAM and KPTI – Performance Implications From The Meltdown Fix」這篇看到頗驚人的數字,這篇提到了他們收到回報 (回報的 ticket 可以參考「[MDEV-15072] Massive performance impact after PTI fix - JIRA」),說 KPTI (Meltdown Mitigation) 對 MyISAM 效能影響巨大:

Recently we had a report from a user who had seen a stunning 90% performance regression after upgrading his server to a Linux kernel with KPTI (kernel page-table isolation – a remedy for the Meltdown vulnerability).

他們發現 90% 是因為 VMware 舊版本無法使用 CPU feature 加速,在新版應該可以改善不少。但即使如此,文章內還是在實體機器上看到了 40% 的效能損失:

A big deal of those 90% was caused by running in an old version of VMware which doesn’t pass the PCID and INVPCID capabilities of the CPU to the guest. But I could reproduce a regression around 40% even on bare metal.

然後後面就在推銷 MariaDB 的 Aria Storage Engine 了,不是那麼重要... 不過知道 MyISAM 在 KPTI 下這麼傷還蠻重要的,因為接下來五年應該都還是愈的到 KPTI,應該還是有人在用 MyISAM...

DynamoDB 可以透過 KMS 加密了...

AWSDynamoDB 可以透過 KMS 加密了:「New – Encryption at Rest for DynamoDB」。

You simply enable encryption when you create a new table and DynamoDB takes care of the rest. Your data (tables, local secondary indexes, and global secondary indexes) will be encrypted using AES-256 and a service-default AWS Key Management Service (KMS) key.

看起來不是自己的 KMS key,而是 service 本身提供的,這樣看起來是在 i/o level 加密,所以還不是 searchable encryption 的能力...

不同性質的應用程式對 KPTI (Meltdown 修正) 的效能影響

NetflixBrendan Gregg 整理了他測試 KPTI 對效能的影響:「KPTI/KAISER Meltdown Initial Performance Regressions」。

與其他人只是概括的測試,他主要是想要針對可量測的數字對應出可能的 overhead,這樣一來還沒上 patch 的人就可以利用這些量測數字猜測可能的效能衝擊。

他把結論放在前面:

To understand the KPTI overhead, there are at least five factors at play. In summary:

  • Syscall rate: there are overheads relative to the syscall rate, although high rates are needed for this to be noticable. At 50k syscalls/sec per CPU the overhead may be 2%, and climbs as the syscall rate increases. At my employer (Netflix), high rates are unusual in cloud, with some exceptions (databases).
  • Context switches: these add overheads similar to the syscall rate, and I think the context switch rate can simply be added to the syscall rate for the following estimations.
  • Page fault rate: adds a little more overhead as well, for high rates.
  • Working set size (hot data): more than 10 Mbytes will cost additional overhead due to TLB flushing. This can turn a 1% overhead (syscall cycles alone) into a 7% overhead. This overhead can be reduced by A) pcid, available in Linux 4.14, and B) Huge pages.
  • Cache access pattern: the overheads are exacerbated by certain access patterns that switch from caching well to caching a little less well. Worst case, this can add an additional 10% overhead, taking (say) the 7% overhead to 17%.

重點在於給了量測的方式,以第一個 Syscall rate 來說好了,他用 sudo perf stat -e raw_syscalls:sys_enter -a -I 1000 測試而得到程式的 syscall 數量,然後得到下面的表格,其中 X 軸是每秒千次呼叫數,Y 軸是效能損失:

用這樣的方式提供給整個組織 (i.e. Netflix) 內評估衝擊。

GitHub 停用過時加密演算法的計畫

先前有提到 GitHub 廢除 SSH 中的弱演算法 (參考「GitHub 明年關閉 SSH 上 SHA1 相關的 Kx (Key Exchange) 演算法」),現在宣佈詳細作法了:「Weak cryptographic standards removal notice」。

包括 HTTPS 的 TLSv1/TLSv1.1 以及 SSH 的 diffie-hellman-group1-sha1/diffie-hellman-group14-sha1 都會被廢止。而作法跟其他家不太一樣:

  • February 8, 2018 19:00 UTC (11:00 am PST): Disable deprecated algorithms for one hour
  • February 22, 2018 19:00 UTC (11:00 am PST): Permanently disable deprecated algorithms

先關閉一個小時讓沒看公告但是有注意到的人可以發現,然後過兩個禮拜後才完全關閉。跟其他家不太一樣的作法...

V8 version 6.5 (Chrome 65) 的改變

V8 version 6.5 將會有不少改變:「V8 release v6.5」。

其中因為 Spectre 的關係,新的 V8 設計了 Untrusted code mode,拿來跑不信任的程式,裡面會設計反制措施。而且這在新版的 Chrome 將會預設開啟:

In response to the latest speculative side-channel attack called Spectre, V8 introduced an untrusted code mode. If you embed V8, consider leveraging this mode in case your application processes user-generated, not-trustworthy code. Please note that the mode is enabled by default, including in Chrome.

另外是針對 WebAssembly 提供邊下載邊 compile 的能力,這讓速度大幅提昇。在原文是拿一個比較大包的 WebAssembly 來測試:

For the graph below we measure the time it takes to download and compile a WebAssembly module with 67 MB and about 190,000 functions. We do the measurements with 25 Mbit/sec, 50 Mbit/sec, and 100 Mbit/sec download speed.

可以看到網路不夠快的使用者就會直接被 compile 速度跟上,讓瀏覽器在下載時就做一些事情。

另外在某些情況下對 Array 的操作會有大幅改善:

這些新功能與改善都會在 Chrome 65 推出。依照「Chrome Platform Status」這邊的資料,stable 版預定在三月初,beta 版應該是要出了... (雖然上面寫著 2/1,但目前好像還沒更新)

Stripe 宣佈 TLS 1.0/1.1 的退場時間表

Stripe 宣佈了今年的 2/19 會停用測試環境的 TLS 1.0/1.1,並且在 6/13 全面停用:「Completing an upgrade to TLS 1.2」。

  • Monday, February 19: All servers using older versions of TLS will be blocked from the Stripe API in test mode.
  • Wednesday, June 13: All servers using older versions of TLS will be blocked from the Stripe API in live mode.

這喊好久了,總算是開槍了...

隔壁棚 PayPal 反而早就把 Sandbox 環境上 TLS 1.2-only 了,而六月底也會強制所有連線都必須是 TLS 1.2:「TLS 1.2 and HTTP/1.1 Upgrade - PayPal」。

Let's Encrypt 的 Wildcard SSL Certificate 延至二月底推出

Let's Encrypt 本來預定在一月底時推出 Wildcard SSL Certificate (參考「Let's Encrypt 決定要規劃 Wildcard SSL Certificate 了」),昨天突然想到應該是要推出了... 查了資料發現在原本的公告文章上宣佈延到二月底了:「Wildcard Certificates Coming January 2018」。

Update, January 4, 2018

We introduced a public test API endpoint for the ACME v2 protocol and wildcard support on January 4, 2018. ACME v2 and wildcard support will be fully available on February 27, 2018.

所以再等一個月吧...

幾個 Web API Manager 要設定的東西...

在上一篇提到的「控制瀏覽器裡的 Web API」,用了一兩天後有遇到一些問題,大概整理一下...

  • Gmail 會開不起來,需要將 mail.google.com 列入白名單 (一個阻擋條件都不能設),這是因為遇到瀏覽器的 bug,在「General breakage on specific site · Issue #55 · snyderp/web-api-manager」這邊作者有找到問題,他判斷是瀏覽器的問題後開了 ticket 給 FirefoxChrome,不知道什麼時候會好...
  • 同理,Facebook 右上角的通知也出不來,也是同樣的問題,需要把 www.facebook.com 列入白名單。
  • 另外是 Google Maps 用滑鼠滾輪滾動本來是平滑式的縮放,現在用起來會變成階段式的縮放,原因是 Google Maps 用到 WebGL Specification (在 Lite 裡面會阻擋)。這有兩個方向可以改,一個是把 www.google.com (或是 www.google.com.tw,看你用的網域) 另外開一組設定管理,另外一個是直接把 WebGL Specification 的阻擋關掉。

目前遇到的大概就是這些了...

Archives