Ubuntu Weekly Recipe

第511回 UEFIの設定が変更できなくなる,あのバグの話

この記事を読むのに必要な時間:およそ 2 分

突然訪れた不審な挙動

遡ること半年以上前。昨年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の動き,筆者の動きを時系列で重ねて見てみます。

2016/11/28問題のコードがアップストリームカーネルにコミットされる
2017/8頃Ubuntu 17.10(artful)のカーネルがアップストリームからインポートされる
2017/9/5問題のコードがアップストリームカーネルで差し戻される
2017/9初旬筆者のPCで問題が発生
2017/10/5Ubuntu 17.10(artful) Kernel Freeze
2017/10/18Ubuntu 17.10リリース
2017/11/23Launchpadでバグが報告される

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

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

著者プロフィール

たなかあきら

Ubuntu Japanese Team Member。ちょっとお高い電子辞書を買ったので,楽しく翻訳をしていたところ,気づいたらメンバーになっていました。

コメント

コメントの記入