Tag: bug

Raspberry Pi 4 的 Type C 無法使用 Macbook Charger 供電的問題

Raspberry Pi 4 出來後有些災情 (畢竟又加了不少東西近去)，在 Hacker News 上看到的 Type C 介面的充電問題：「Raspberry Pi 4 not working with some chargers (scorpia.co.uk)」，引用的原文可以在「Pi4 not working with some chargers (or why you need two cc resistors)」這邊看到，裡面提到了新的 Type C 供電介面在接某些充電器時不會供電 (包括了 Macbook 的充電器)：

The new pi has been released and it has a USB Type-C connector for power however people are finding some chargers are not working with it (notably macbook chargers). Some have speculated that this is due to a manufacturer limitation on the power supplies however it is actually due to the incorrect detection circuitry on the Pi end of the USB connection.

這樣說有點偏頗，但是 Macbook 的充電器一向是 Type C 裡的指標，如果這顆充電器跟其他裝置配合上有問題，通常都是代表其他裝置的實作有問題... (噗)

這次發現的電阻問題看起來有點苦 (看起來需要改版子)，目前文章作者建議的 workaround 主要就是「不要用那麼好的設備」，比較簡單的包括了 Type C 的線不要那麼好 (像是找充手機用的線就好，不要找拿可以跑 5A 的線)，或是透過 Type A 轉 Type C 的線也應該可以避開這個問題，最差的情況應該是找其他的充電器：

Now onto some solutions. Assuming the issue you are having is caused by the problem discussed above, using a non e-marked cable (most USB-C phone charger cables are likely this type) rather than an e-marked cable (many laptop charger/thunderbolt cables and any 5A capable cable will be in this category) will allow for the pi to be powered. In addition using older chargers with A-C cables or micro B to C adaptors will also work if they provide enough power as these don’t require CC detection to provide power. Ultimately though the best solution in the long run will be for there to be a board revision for the pi 4 which adds the 2nd CC resistor and fixes the problem.

對於已經入手的人，如果真的中獎，workaround cost 應該還在可以控制的範圍...

歐盟對十四套 Open Source 軟體推出 Bug Bounty Program

歐盟對於 14 套 open source 軟體推出 bug bounty program，協助改善這些軟體的品質 (主要是資安這塊)：「EU to fund bug bounty programs for 14 open source projects starting January 2019」、「In January, the EU starts running Bug Bounties on Free and Open Source Software」。

這十四套軟體的選擇應該可以參考「EU aims to increase the security of password manager and web server software: KeePass and Apache chosen for open source audits」這邊...

然後看到「Intigriti/Deloitte」這個才知道原來 Deloitte 也有做這個啊...

Ubuntu 撥 HiNet PPPoE 時會因為 MTU 而導致有些網站連不上

之前用 HiNet 固定制 (不需要 PPPoE，直接設 IP 就會通的那種)，跑起來順順的也沒麼問題，最近剛好合約滿了就打算換成非固定制 (需要撥 PPPoE 才會通)，結果換完後發現有些網站常常連不上 (不是一直都連不上)，但只要設了 proxy.hinet.net (今年年底要停止服務了) 或是改從 cable 線路出去就正常。

測了不少設定都沒用 (像是改 tcp timestamp 設定，或是 sack 之類的設定)，後來發現 MTU 的值不太對，用 ifconfig 看發現我的 ppp0 是 1500 而不是 1492，直接先 ifconfig ppp0 mtu 1492 改下去測，發現本來不能連的網站就通了...

(補充一下，我看了 Windows 的設定是 1480，所以也沒問題，但不知道怎麼算的...)

查了一下 MTU 相關的問題，發現在「wrong mtu value on dsl connection」這邊有討論到。裡面提到的 workaround 是到 /etc/NetworkManager/system-connections/ 裡找出你的 PPPoE 設定檔，然後在 ppp 區域的裡面寫死 mtu 參數：「mtu=1492」(這邊的 1492 是從 1500 bytes 扣掉 PPPoE 的 8 bytes 得出來的)，不過我測試發現在修改設定檔時會被改回來，加上測試發現沒用，只好自己寫一個 /etc/network/if-up.d/pppoe-mtu 惡搞了：

#!/bin/sh -e

if [ "$IFACE" != "ppp0" ]; then
        exit 0
fi

/sbin/ifconfig ppp0 mtu 1492

放進去後要記得 chmod 755。

從 ticket 上面看起來還是沒有解 (2009 年就發現了)，看起來 PPPoE 不是絕對多數而且又有 workaround，短期應該不會修正...

CVE-2018-14665：setuid 複寫檔案的 security issue...

在 Twitter 上看到的 security issue，好久沒在這麼普及的軟體上看到這種 bug 了：

在 CVE - CVE-2018-14665 的說明裡面有提到 1.20.3 前的版本都有中，但沒講到從哪個版本開始，看起來是全系列...？

A flaw was found in xorg-x11-server before 1.20.3. An incorrect permission check for -modulepath and -logfile options when starting Xorg. X server allows unprivileged users with the ability to log in to the system via physical console to escalate their privileges and run arbitrary code under root privileges.

這一臉 orz...

ORM 常見的效能問題

在「How not to structure your database-backed web applications: a study of performance bugs in the wild」這邊看到的，裡面提到的論文是以 Rails 的 ActiveRecord 分析，不過概念上還算通用...

重點在最後一張 (Table 7 那張)：

看一下在腦裡留個印象，之後遇到的時候至少大概知道怎麼查...

把本來 dehydrated 的 PPA 改成 dehydrated-lite

本來有做 dehydrated 的 PPA (在「PPA for dehydrated : Gea-Suan Lin」這邊)，後來在 17.10+ 就有更專業的人包進去了 (參考「Ubuntu – Package Search Results -- dehydrated」)，為了避免名稱相同但是內容物差很多，我把 PPA 的名字換成 dehydrated-lite 了 (參考「PPA for dehydrated (lite) : Gea-Suan Lin」)。

然後 0.6.2 的 dehydrated 針對 ACMEv2 有修正，這在 0.6.1 時會產生 certificate 裡有多餘資訊 (而 PPA 版的 gslin/dehydrated 只會停留在 0.6.1)，這點需要注意一下：

Don't walk certificate chain for ACMEv2 (certificate contains chain by default)

之後再找機會拔掉 gslin/dehydrated，也許會照著現在 APT 內的架構來做...

Linus (又) 不爽了... XD

看得出來 Linus 對於 Intel 的行為很不爽：「Re: Avoid speculative indirect calls in kernel」。

Please talk to management. Because I really see exactly two possibibilities:

 - Intel never intends to fix anything

OR

 - these workarounds should have a way to disable them.

Which of the two is it?

那個 possibibilities 應該是 typo，但不知道為什麼看起來很有味道 XDDD

Spectre 與 Meltdown 兩套 CPU 的安全漏洞

The Register 發表了「Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign」這篇文章，算是頗完整的說明了這次的安全漏洞 (以 IT 新聞媒體標準來看)，引用了蠻多資料並且試著說明問題。

而這也使得整個事情迅速發展與擴散超出本來的預期，使得 Google 的 Project Zero 提前公開發表了 Spectre 與 Meltdown 這兩套 CPU 安全漏洞。文章非常的長，描述的也比 The Register 那篇還完整：「Reading privileged memory with a side-channel」。

在 Google Project Zero 的文章裡面，把這些漏洞分成三類，剛好依據 CVE 編號分開描述：

  • Variant 1: bounds check bypass (CVE-2017-5753)
  • Variant 2: branch target injection (CVE-2017-5715)
  • Variant 3: rogue data cache load (CVE-2017-5754)

前兩個被稱作 Spectre，由 Google Project Zero、Cyberus Technology 以及 Graz University of Technology 三個團隊獨立發現並且回報原廠。後面這個稱作 Meltdown，由 Google Project Zero 與另外一個團隊獨立發現並且回報原廠。

這兩套 CPU 的安全漏洞都有「官網」，網址不一樣但內容一樣：spectreattack.com 與 meltdownattack.com。

影響範圍包括 Intel、AMD 以及 ARM，其中 AMD 因為架構不一樣，只有在特定的情況下會中獎 (在使用者自己打開 eBPF JIT 後才會中)：

(提到 Variant 1 的情況) If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU.

這次的洞主要試著透過 side channel 資訊讀取記憶體內容 (會有一些條件限制)，而痛點在於修正 Meltdown 的方式會有極大的 CPU 效能損失，在 Linux 上對 Meltdown 的修正的資訊可以參考「KAISER: hiding the kernel from user space」這篇，裡面提到：

KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.

KAISER 後來改名為 KPTI，查資料的時候可以注意一下。

不過上面提到的是實體機器，在 VM 裡面可以預期會有更多 syscall 與 context switch，於是 Phoronix 測試後發現在 VM 裡效能的損失比實體機器大很多 (還是跟應用有關，主要看應用會產生多少 syscall 與 context switch)：「VM Performance Showing Mixed Impact With Linux 4.15 KPTI Patches」。

With these VM results so far it's still a far cry from the "30%" performance hit that's been hyped up by some of the Windows publications, etc. It's still highly dependent upon the particular workload and system how much performance may be potentially lost when enabling page table isolation within the kernel.

這對各家 cloud service 不是什麼好消息，如果效能損失這麼大，不太可能直接硬上 KPTI patch... 尤其是 VPS，對於平常就會 oversubscription 的前提下，KPTI 不像是可行的方案。

可以看到各 VPS 都已經發 PR 公告了 (先發個 PR 稿說我們有在注意，但都還沒有提出解法)：「CPU Vulnerabilities: Meltdown & Spectre (Linode)」、「A Message About Intel Security Findings (DigitalOcean)」、「Intel CPU Vulnerability Alert (Vultr)」。

現在可以預期會有更多人投入研究，要怎麼樣用比較少的 performance penalty 來抵抗這兩套漏洞，現在也只能先等了...

用 Psalm 掃出 PHP 有問題的程式碼

Psalm 的 slogan 是「A static analysis tool for PHP」，由 Vimeo 發展並開放出來的軟體：「vimeo/psalm」。

目前是 v0.3.71，所以需要 PHP 5.6 以上才能跑：

  • v0.3.x supports checking PHP 5.4 - 7.1 code, and requires PHP 5.6+ to run.
  • v0.2.x supports checking PHP 5.4 - 7.0 code and requires PHP 5.4+ to run.

Psalm 主要的目標是找出哪邊「已經發生錯誤」，而不像其他幾套的目標是「預防」，這樣可以避免過高的 false alarm...