突然訪れた不審な挙動

遡ること半年以上前。昨年9月のオープンソースカンファレンス 2017 Tokyo/Fallで筆者はUbuntu 17.10（Artful）の紹介セミナーを担当することになっていました。そこで実機確認と当日のデモとを兼ねて，8月当時はまだ開発中だったUbuntu 17.10を自前のノートPCにインストールし，発表の準備をしていました。

ところが，その日を境にPCの挙動がおかしくなりました。この機種はカーネルに起因するあのバグが「発症」する機種だったのです。

そもそもどういうバグなのか

このバグはUbuntu Weekly Topicsでも2018年1月12日と1月19日に取り上げられました。世間では比較的話題になったバグなので，目にした人も多いでしょう。

ところで，そもそもこのバグはどういうものだったのでしょうか？　1月19日の記事には「Intel SPI Flash」という用語が出てきます。Intel SPI Flashがどういうもので，何を目的にしているかはLinuxカーネルのドキュメントに次のように簡潔に書かれています。

「BayTrailやBraswell世代のIntel社製CPUの多くにはSPIシリアルフラッシュホストコントローラーが含まれていて，これはBIOSやその他プラットフォーム固有のデータを保持するために使われている」

SPIシリアルフラッシュの中身はマシンの正常動作に不可欠なことから，典型的にはハードウェア的に保護されています。しかし，「⁠主にOSから直接BIOSイメージのアップグレードができるようにするために，すべての製造元がSPIシリアルフラッシュを保護しているわけではない」のです（※1）⁠。

※1

Windows上でUEFIをアップグレードした経験を持っている人もいると思いますが，それはこの機能を利用していると考えて良いでしょう。

intel-spiドライバーはこのようなSPIシリアルフラッシュを読み書きするためのものです。ドキュメントにはddコマンドを利用してフラッシュの読み書き，すなわちUEFIのバックアップとアップグレードの例が書かれています （⁠※2）⁠。

※2

IntelのサイトではGalileoボードのフラッシュアップグレード手順を見つけることができました。

2016年11月28日に，このSPIシリアルフラッシュホストコントローラーをサポートするためのコードがメインストリームのカーネルにコミットされました。しかし2017年7月28日に，一部のハードウェアで問題があることが発覚し，9月にはこのコードの一部が差し戻されています。

差し戻しコミットのメッセージには次のように書かれています。

「少なくともLenovo Thinkpad Yogaでは，BIOSがSPI-NOR書き込み保護ビットを監視していて，このビットが読み・書きに切り替わると，BIOSは設定が次回のリブート時に変わったものと想定する。このときに理由はよくわからないが，BIOS設定がデフォルトにリセットされてしまう（※3）⁠。」

※3

引用している文章の強調は筆者によります（以下同）⁠。

ただし「デフォルトにリセットされてしまう」とありますが，UEFIの設定がRead Only状態になってしまい，変更できないというのが実際の症状のようです。

Ubuntu 17.10のカーネルは運悪く問題のコードを含んだカーネルをインポートしてしまっていました（※4）⁠。

※4

Ubuntu Weekly Recipe 第278回には「Ubuntuの最新版で使われるカーネルのバージョンは『リリースの2ヶ月前くらいの最新版』になります」とあります。

カーネルのバージョンによってこのバグが発症する・しないは昨年12月末のLaunchpad上のサマリーで確認できます。このサマリーによるとバグの発生するカーネルは 4.11から4.13.0-17となっています。

また現時点での対処として，問題を起こすIntel SPIのモジュールがカーネルに組み込まれないように，カーネルコンフィグから設定を落としています。

したがって，問題のあるカーネルであるかどうかは，次のコマンドで確認できます。

$ lsmod | grep spi

ここでintel_spi_platformといった行が表示されれば，問題のあるカーネルを使用していることになります。

筆者の場合

ところで，筆者がこのバグを踏んだのはDell社製のInspiron 3147という機種で筆者が2014年10月に購入したものでした。

一時期はUbuntu 14.04 LTSを入れて常用していましたが，その後はリカバリをし，Windows専用機として利用していました。改めてUbuntuを入れたのは冒頭に挙げたように限定的な目的だったため，WindowsとUbuntuとのデュアルブートになるようにインストールしました。Ubuntuをインストールすると，UEFIでブートローダーにgrubが一番に選択されるようになりますが，これをデフォルトのWindows Boot Loaderに設定するつもりでした。つまり，普段はWindows Boot Loaderを使ってWindowsを起動させ，Ubuntuが必要なときにUEFIのブートメニューから起動元を切り替えて起動させるという算段だったのです。

しかし，開発版のUbuntu 17.10を入れて以来，UEFIの画面でいくら起動順を入れ替えてもその設定が反映されないという状態になってしまいました。起動に関連するその他の項目をいくら変更しても症状は改善しませんでした。Ubuntu 16.04を入れていたときはこのような問題が発生したことがなかったので，購入から3年ほど経っていることもあり，ついに調子が悪くなったかと諦めていました。

先に挙げた1月12日のTopicsでは「Ubuntu 17.10において，一部の（最新の）ノートPCにおいて，UEFI設定の変更を妨げる（実装によっては，特定デバイスからのブートができなくなる）事象が生じています」と記述されていたため，まさか自分のPCがそれにあたるとは思ってもいませんでした。結局，バグを踏んでいるとの考えに至ったのは1月下旬で，実際に踏んでから5ヶ月近くも経っていました。

バグに気づいてからは，1月19日のTopicsにリンクの張られたサマリを頼りに，この問題の修正を含んだカーネルパッケージをインストールしました。カーネルパッケージは1つダメならもう1つと，2種類インストールするよう案内されていますが，筆者の場合は両方のパッケージを導入することで問題は解消しました。

なお，本稿の導入として執筆前には「バグの再現は簡単で，手元に残っていたリリース直後のUbuntu 17.10のISOイメージからインストールUSBメモリを作成し，問題を起こしたPCにインストールしてみる」ことを考えていましたが，そこまで単純な話ではありませんでした。というのも，実際に執筆するにあたって試行錯誤を繰り返しましたが，問題が再現しなかったのです。書き込み可能ビットの操作がRead Only状態になってしまう原因の1つであることはわかっていますが，他にも条件があるようです。 アップストリームカーネルの差し戻しコミットで「 理由はよくわからないが」と言われているゆえんは，このあたりなのでしょう（※5）⁠。

※5

バグを再現させるのにこれほど努力が必要とは思いませんでした。

悲劇を繰り返さないために

最後に，アップストリームカーネルの動き，Ubuntuの動き，筆者の動きを時系列で重ねて見てみます。

これを見て思うことは，もしかすると筆者は早い段階でこのバグを踏んでいた一人だったのかもしれず，「⁠9月の段階でこの事象をバグとして報告できていれば，かなり違った展開がありえたのかもしれない」ということです。もっともこれは完全なる後知恵ですし，理想的に事が運んだとしての仮定ではあります。ですが，忸怩たる思いがないわけではありません。

折しも来月には18.04 LTSのリリースを控えています。重大なバグも今月中に報告できれば，正式リリースまでに修正が間に合う可能性があります。Ubuntu Japnese Teamでは日本語でバグ報告をできる場としてKaizen Projectを用意しています。開発版であれ，リリース版であれ，問題があればフィードバックをすることでUbuntuの品質はずっと良くなると筆者は信じています。