ArchWiki - 利用者の投稿記録 [ja]

セキュリティ

2025-12-30T03:56:37Z

N: /* proc ファイルシステム内のカーネルポインタへのアクセスを制限する */

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
[[zh-hans:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事には、Arch Linux システムを[[Wikipedia:ja:ハードニング|ハードニング]]するための推奨事項とベストプラクティスを並べています。

== 概念 ==

* システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で ''かつ'' 使いやすいシステムを作ること。
* 最大の脅威は常にユーザー自身である。
* [[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
* 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
* 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
* システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
* 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。

==パスワード==
パスワードは安全な Linux システムの鍵です。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

=== 安全なパスワードの選び方 ===

パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法で[[Wikipedia:Password cracking|クラック]]されないようにする必要があります。強力なパスワードの基本原則は、''長さ''と''ランダム性''に基づいています。暗号学では、パスワードの品質はその[[Wikipedia:Password strength#Entropy as a measure of password strength|エントロピー]]によって測られます。

安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。

* 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
* 単純な文字の置き換えを行った単語(例:{{ic|k1araj0hns0n}})最新の辞書攻撃ではこれらも簡単に解析可能
* 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:{{ic|DG091101%}})
* 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:{{ic|photocopyhauntbranchexpose}})文字の置き換えを行っても(例:{{ic|Ph0toc0pyh4uN7br@nch3xp*se}})、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり)
* [[Wikipedia:List of the most common passwords|最も一般的なパスワード]]のいずれか

最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。[https://www.theregister.com/2019/02/14/password_length 弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能] です。

{{Pkg|pwgen}} や {{AUR|apg}} のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。

パスワード管理とは別に、{{Pkg|keepassxc}} はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。

パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:{{ic|t6!WdtR5}} より複雑な例:{{ic|t&6!RrlW@dtR,57}}
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]] を参照)

また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。

さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードを[[パスワードマネージャ]]に保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。
また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。

覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、[https://xkcd.com/936/ xkcdのコミック] に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については [https://www.rempe.us/diceware/ Diceware] を参照してください。

さらに詳しい情報については、[https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] や [[Wikipedia:Password strength]] も参考になります。

=== パスワードの管理 ===

強力なパスワードを選んだら、それを安全に保管することが重要です。[[Wikipedia:Keylogger|キーロガー]] (ソフトウェアおよびハードウェア)、スクリーンロガー、[[Wikipedia:Social engineering (security)|ソーシャルエンジニアリング]]、[[Wikipedia:Shoulder surfing (computer security)|ショルダースーフィング]]に注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。[[アプリケーション一覧/セキュリティ#パスワードマネージャ|パスワードマネージャ]]を使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、{{ic|.bash_history}} などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、[https://www.spookjs.com サイドチャネル攻撃]に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。

原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[https://www.schneier.com/blog/archives/2005/06/write_down_your.html] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。

パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。

ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、{{ic|/etc/shadow}} が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については [[SHA hashes#SHA パスワードハッシュ|SHA パスワードハッシュ]] を参照してください)

{{Tip|Arch Linux は [https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのハッシュアルゴリズム]を yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、{{ic|passwd}} を実行してパスワード変更を行うなどして下さい。}}

パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。

データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。

=== パスワードのハッシュ ===

ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)

パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)[[Wikipedia:Key derivation function|鍵導出関数]] (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。

デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な {{ic|/etc/shadow}} ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な {{ic|/etc/passwd}} ファイルから分離されています。詳細は [[ユーザーとグループ#ユーザーデータベース]] を参照してください。また、[[#root の制限]] も参照してください。

パスワードは '''passwd''' コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードを[[Wikipedia:Key stretching|ストレッチ]]し、その後 {{ic|/etc/shadow}} に保存されます。パスワードは[[Wikipedia:Salt (cryptography)|ソルト]]も施され、[[Wikipedia:Rainbow table|レインボーテーブル]]攻撃に対して防御されます。詳細は[https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils Linux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)]を参照してください。

パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな ''passwd'' コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、{{ic|/etc/shadow}} ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。

フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、{{man|5|crypt}} を参照してください。

{{ic|/etc/login.defs}} ファイルでは、[https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのパスワードハッシュメソッド]{{ic|ENCRYPT_METHOD YESCRYPT}} とそのパラメータ {{ic|YESCRYPT_COST_FACTOR}} が設定されます。

例えば、デフォルトの {{ic|YESCRYPT_COST_FACTOR}} パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。

これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては [[SHA パスワードハッシュ]] を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_pwquality'' は、[[Wikipedia:Dictionary attack|辞書攻撃]]に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは ''pam_cracklib'' をベースにしており、そのオプションとの後方互換性があります。

{{Pkg|libpwquality}} パッケージを[[インストール]]してください。

{{Warning|デフォルトでは、''root'' アカウントはこのポリシーの影響を受けません。}}

{{Note|
* ''root'' アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
* 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。
}}

例えば、以下のポリシーを強制したい場合:

* エラーが発生した場合にパスワードを2回入力する (retry オプション)
* 最小長10文字 (minlen オプション)
* 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
* 最低1桁の数字 (dcredit オプション)
* 最低1つの大文字 (ucredit オプション)
* 最低1つの小文字 (lcredit オプション)
* 最低1つのその他の文字 (ocredit オプション)
* "myservice" および "mydomain" という単語を含めない
* root にもこのポリシーを強制する

{{ic|/etc/pam.d/passwd}}ファイルを以下のように編集します:

{{bc|1=
#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} は、''pam_unix'' モジュールに対してパスワードの入力を促さず、代わりに ''pam_pwquality'' で提供されたものを使用するように指示します。

詳細については、{{man|8|pam_pwquality}} および {{man|8|pam_unix}} のマニュアルページを参照してください。

== CPU ==

=== マイクロコード ===

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。

=== ハードウェアの脆弱性 ===

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

==== 同時マルチスレッディング (ハイパースレッディング) ====

[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

== メモリ ==

===ハード化された malloc ===

[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパースクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に [[#パスワード|強力なパスフレーズ]] を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。

ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。

また、[[Trusted Platform Module#LUKS による保存データの暗号化|TPMにキーを保存してドライブを暗号化]] することもできますが、過去に [https://tpm.fail 脆弱性] があり、キーは [https://pulsesecurity.co.nz/articles/TPM-sniffing TPMバススニッフィング攻撃] によって抽出される可能性があります。

[[dm-crypt]] のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。

[[ディスク暗号化]] の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば [[保存データ暗号化#クラウドストレージの最適化|クラウドストレージ]])に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。

ファイルを暗号化するためのいくつかの方法は次の通りです:

* 一部の [[アーカイブと圧縮|アーカイブおよび圧縮]] ツールは基本的な暗号化も提供します。例としては、[[7-Zip]] ({{ic|-p}} フラグ)、{{Pkg|zip}} ({{ic|-e}}フラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[https://math.ucr.edu/~mike/zipattacks.pdf]
* [[GnuPG]] を使用してファイルを [[GnuPG#Encrypt and decrypt|暗号化]] できます。
* {{Pkg|age}} は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)

関連するマウントオプションは以下の通りです:

* {{ic|nodev}}: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。
* {{ic|nosuid}}: set-user-identifier や set-group-identifier ビットを無効にする。
* {{ic|noexec}}: マウントされたファイルシステム上のバイナリを直接実行できないようにする。
** {{ic|/home}} に {{ic|noexec}} を設定すると、実行可能なスクリプトが禁止され、[[Wine]]、[[Steam]]、PyCharm、[[.NET]] などが動作しなくなります。
*** Wine は Windows バイナリの実行に {{ic|exec}} フラグを必要としません。ただし、Wine 自体を {{ic|/home}} にインストールする場合は必要です。
*** [[Steam]] を動作させるには、{{ic|/home/user/.local/share/Steam}} を [[fstab]] で {{ic|exec}} としてマウントできます。以下の設定を追加してください: {{bc|/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0}}
** 一部のパッケージ(例:{{Pkg|nvidia-dkms}} のビルド)では、{{ic|/var}} に {{ic|exec}} が必要な場合があります。

データ用のファイルシステムは、常に {{ic|nodev}}、{{ic|nosuid}}、{{ic|noexec}} を指定してマウントするべきです。

マウントを検討すべきファイルシステム:

* {{ic|/var}}
* {{ic|/home}}
* {{ic|/dev/shm}}
* {{ic|/tmp}}
* {{ic|/boot}}

{{Tip|[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]] を使用する場合、ESP および XBOOTLDR パーティションは [https://github.com/systemd/systemd-stable/commit/49804cfb71d3a79f433096e4cfb5616980171336 常に {{ic|noexec,nosuid,nodev}} で強化] されます。}}

==== スナップショット ====

ファイルシステムのスナップショットを利用する場合(例えば [[Btrfs]]、[[LVM]]、[[ZFS]] など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、[[Snapper]] のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。

以下は、{{ic|/home/}} 内の機密情報がスナップショットに残存する例です:

* 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、{{ic|.local/share/Trash/}}、{{ic|.history}} などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
* 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル({{ic|.cache/thumbnails}})や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴({{ic|.mozilla/}}、{{ic|.config/chromium/}} など)も、削除される前にスナップショットに記録されている場合があります。

対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、[[Btrfs]] を使用している場合、{{ic|.cache/}}、{{ic|.config/}}、{{ic|.local/}}、{{ic|.var/}} など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。

{{Note|{{ic|.local/share/Trash}} を別のサブボリュームに移動すると、場合によっては [[GNOME/Files]] などでゴミ箱の機能が正常に動作しなくなる可能性があります。}}

===ファイルシステムのパーミッション===

デフォルトの [[パーミッション]] では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、{{ic|http}} ユーザーや {{ic|nobody}} ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。[[chmod]] を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。

# chmod go-r ''path_to_hide''

{{Warning|この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、{{ic|g}} をコマンドから削除するか、既に実行してしまった場合は {{ic|chmod g+r path}} で再度許可を追加する必要があるかもしれません。}}

考慮すべきパスの例:

* {{ic|/boot}}: [[パーティショニング#/boot|ブートディレクトリ]]、[[vmlinuz]] や [[initramfs]] image、または [[ユニファイドカーネルイメージ]] が含まれる場合があります。なお、[[systemd# GPT パーティションの自動マウント]] を使用する場合、デフォルトで安全なパーミッションが適用されます。
* {{ic|/etc/nftables.conf}}: [[nftables]] の設定ファイル({{Pkg|nftables}} および {{Pkg|iptables-nft}} に適用)
* {{ic|/etc/iptables}}: レガシーな [[iptables]] の設定ファイル({{Pkg|iptables}} に適用)

また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの [[umask]] 値 {{ic|0022}} を変更することも可能です。[https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] では最大限のセキュリティを確保するために、{{ic|0077}} を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については [[Umask#マスクの値を設定]] を参照してください。

さらに、[[sudo]] を使用する場合、[[Sudo#Permissive umask|デフォルトの root umask]] を適用するよう設定することを検討してください。

=== SUID ファイルと SGID ファイル ===

[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。

* [[PAM|unix_chkpwd]]
* chage, expiry, gpasswd, groupmems, [[passwd]], sg, ({{Pkg|shadow}})
* [[FUSE|fusermount3]], fusermount
* pkexec
* [[OpenSSH|ssh-keysign]]
* chfn, chsh, mount, newgrp, umount, wall, write ({{Pkg|util-linux}})
* [[sudo]], {{Pkg|sudo-rs}}, [[doas]], [[su]], su-rs, [[Kerberos|ksu]]
* [[firejail]]
* [[Dbus|dbus-daemon-launch-helper]]
* [[Chromium|chromium-sandbox]]
* [[Xorg|Xorg.wrap]]

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}

SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:

$ find /usr/bin -perm "/u=s,g=s"

== ユーザー設定 ==

=== root アカウントを日常的に使用しない ===

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。

=== ログイン失敗後の遅延時間の設定 ===

以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。

{{hc|/etc/pam.d/system-login|2=
auth optional pam_faildelay.so delay=4000000
}}

{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。

===3回ログインを失敗したユーザーをロックアウトする===

{{Pkg|pambase}} 20200721.1-2 の時点では、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。

$ faillock --reset --user ''username''

デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。

モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。

* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)

{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

=== Wayland を使用する ===

[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

=== su の代わりに sudo を使う ===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

==== sudo を使ってファイルを編集する ====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

=== root ログインの制限 ===
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。

==== 特定のユーザーだけに許可を与える ====
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

==== ssh ログインを拒否する ====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==== access.conf で許容されるログインの組み合わせを指定する ====

誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは {{man|5|access.conf}} で確認してください。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

== カーネルの堅牢化 ==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

* {{AUR|skypeforlinux-preview-bin}}
* {{AUR|skypeforlinux-stable-bin}}
* {{pkg|throttled}}

[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。

==== ユーザー空間 ASLR の比較 ====

{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

===== 64 ビットプロセス =====

{{hc|linux-hardened 5.4.21.a-1-hardened|
Anonymous mapping randomization test : 32 quality bits (guessed)
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
Heap randomization test (PIE) : 40 quality bits (guessed)
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
Main executable randomization (PIE) : 32 quality bits (guessed)
Shared library randomization test : 32 quality bits (guessed)
VDSO randomization test : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)
}}

{{hc|linux 5.5.5-arch1-1|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
}}

{{hc|linux-lts 4.19.101-1-lts|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
}}

===== 32 ビットプロセス (x86_64 カーネル上) =====

{{hc|linux-hardened|
Anonymous mapping randomization test : 16 quality bits (guessed)
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 18 quality bits (guessed)
Shared library randomization test : 16 quality bits (guessed)
VDSO randomization test : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)
}}

{{hc|linux|
Anonymous mapping randomization test : 8 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) : 13 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 8 quality bits (guessed)
Shared library randomization test : 8 quality bits (guessed)
VDSO randomization test : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization
}}

=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===

{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用された場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。

{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。

{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
kernel.kptr_restrict = 1
}}

{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}

=== BPF の堅牢化 ===

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。

{{Tip|
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
}}

=== ptrace スコープ ===

{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。

{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}

デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。

=== hidepid ===

{{Warning|
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
}}

カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。

例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:

{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:

{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

=== モジュールのロードを制限する ===

デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。

=== kexec を無効にする ===

Kexec は、現在実行中のカーネルを置き換えることを可能にします。

{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
kernel.kexec_load_disabled = 1
}}

{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}

=== カーネルロックダウンモード ===

Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。

{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}

ロックダウンには2つの動作モードがあります:

* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください:

# echo ''mode'' > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:

{{Note|
* カーネルロックダウンを実行時に無効化することはできません。
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
}}

{{man|7|kernel_lockdown}} も参照してください。

=== Linux Kernel Runtime Guard (LKRG) ===

[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

== アプリケーションのサンドボックス化 ==

こちらも参照 [[Wikipedia:ja:サンドボックス (セキュリティ)]]

{{Note|ユーザー名前空間の設定項目 {{ic|CONFIG_USER_NS}} は、現在 {{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}}、および {{Pkg|linux-hardened}} で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。}}

{{Warning|非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) は、{{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}} でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します([https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction AppArmorのWiki] および {{Bug|36969}} を参照。}}

これを軽減するためには、次のいずれかを行ってください:

* 安全なデフォルトを持つ {{Pkg|linux-hardened}} カーネルを使用する、または
* {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] を {{ic|0}} に設定する。

これにより、[[Zoom Meetings|Zoom]] や {{pkg|nsjail}} などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに {{pkg|bubblewrap}} がインストールされている場合は、{{pkg|bubblewrap-suid}} に置き換える必要があります。詳細は [[Bubblewrap#インストール]] を参照してください。

=== Firejail ===

[[Firejail]] は、アプリケーションやサーバーをサンドボックス化するための使いやすいツールです。元々はブラウザやインターネット向けアプリケーションのために作成されましたが、現在では多くのアプリケーションに対応しています。さまざまな機能を備えたサンドボックス環境を構築するために、suid バイナリとしてインストールされ、ブラックリストとホワイトリストに基づいてターゲットアプリケーションのサンドボックス化された実行環境を構築します。

=== bubblewrap ===

[[bubblewrap]] は、[[Flatpak]] などの非特権コンテナツール向けに開発されたサンドボックスアプリケーションで、Firejail よりもリソース消費と複雑さが大幅に小さいです。ファイルパスのホワイトリスト機能は欠けていますが、bubblewrap はバインドマウントのほか、ユーザー/IPC/PID/ ネットワーク /cgroup 名前空間の作成をサポートしており、シンプルなものから複雑なサンドボックスまで対応可能です。

[[Bubblejail]] サンドボックスは [[bubblewrap]] を基にしており、リソース指向の権限モデルと、権限を調整するためのグラフィカルインターフェースを提供します。

=== chroot ===

手動で [[chroot]] してサンドボックス化されたプロセス環境を作成できます。しかし、これは他のサンドボックス技術に比べて非常に制限されています。そのサンドボックス化の範囲はファイルパスの隔離に限られています。

=== Linux Containers ===

[[Linux Containers]] は、他のオプション([[#完全な仮想化オプション|完全な仮想化オプション]] を除く) よりも多くの隔離が必要な場合に適した選択肢です。LXC は、既存のカーネルの上で擬似 chroot 内で実行され、独自の仮想ハードウェアを持っています。

=== 完全な仮想化オプション ===

[[VirtualBox]]、[[KVM]]、[[Xen]]、または [https://www.qubes-os.org/ Qubes OS](Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。

==ネットワークとファイアウォール==

===ファイアウォール===

標準の Arch カーネルは [[Wikipedia:Netfilter|Netfilter]] の [[iptables]] および [[nftables]] を使用できますが、これらのサービスはデフォルトで [[有効化]] されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。

* 一般的な情報については [[iptables]] および [[nftables]] を参照してください。
* iptables ファイアウォールの設定方法については [[シンプルなステートフルファイアウォール]] を参照してください。
* netfilter の設定方法については [[ファイアウォール]] を参照してください。
* Bluetack などの IP アドレスリストをブロックするには [[Ipset]] を参照してください。
* {{Pkg|opensnitch}} は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。

==== ポートを開く ====

一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が [https://samy.pl/slipstream/ ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする] 可能性があります。これは、[https://nvd.nist.gov/vuln/detail/CVE-2019-13450 localhost にバインドされたプロセス] にも発生することがあります。

一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば {{ic|0.0.0.0/0}})ではなく、Unix ドメインソケット({{man|7|unix}})や {{ic|localhost}} のようなループバックアドレスにバインドするべきです。

サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な [[ファイアウォール]] ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。

現在のすべてのオープンポートをリストするには、{{ic|ss -l}} を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:

# ss -lpntu

その他のオプションについては、{{man|8|ss}}を参照してください。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。

=== SSL 証明書の管理 ===

サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
# root で ''update-ca-trust'' を実行してください。

お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。

== 物理セキュリティ ==

{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識やそこまでの意図はなく、現実に実行されることはほとんどありません。

[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

=== ブートローダー ===

[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、[[カーネルパラメータ]]に{{ic|1=init=/bin/sh}} を設定することでシェルに直接ブートしてログインの制限を回避することができます。

==== Syslinux ====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

==== GRUB ====

[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。

==== systemd-boot ====

[[systemd-boot]] は [[#セキュアブート]] が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、[[systemd-boot#パスワードで保護されたカーネルパラメータエディタ]] を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。

=== セキュアブート ===

[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立ちます。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。

=== トラステッドプラットフォームモジュール(TPM) ===

[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーが秘密情報を保管することができます。

=== リムーバブルフラッシュドライブ上のブートパーティション ===

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。

この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== 不正なUSBデバイスから保護する ===

[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。

=== 揮発性データの収集 ===

電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。

== パッケージ ==

=== パッケージの認証 ===
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。

=== アップグレード ===

定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。

=== 脆弱性アラートの確認 ===

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

=== パッケージの再ビルド ===

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

{| class="wikitable"
! フラグ !! 目的
|-
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
|-
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
|-
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
|-
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
|-
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
|-
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
|-
| -fplugin=annobin || ハードニング品質管理用データの作成
|-
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
|-
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
|-
| -fstack-protector-strong || 同様に
|-
| -g || デバッグ情報を生成する
|-
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
|-
| -mcet -fcf-protection || 制御フローの完全性保護
|-
| -O2 || 推奨される最適化
|-
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
|-
| -Wall || 推奨されるコンパイラの警告
|-
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
|-
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
|-
| -Wl,-z,defs || アンダーリンクの検出と拒否
|-
| -Wl,-z,now || 遅延バインディングを無効にする
|-
| -Wl,-z,relro || 移設後の読み出し専用セグメント
|}

* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]

== 参照 ==

* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

Systemd-boot

2025-12-14T05:35:06Z

N: /* ローダーの追加 */

{{lowercase title}}
[[Category:ブートローダー]]
[[de:Gummiboot]]
[[en:Systemd-boot]]
[[es:Systemd-boot]]
[[pt:Systemd-boot]]
[[ru:Systemd-boot]]
[[zh-hans:Systemd-boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|ブートローダー}}
{{Related|セキュアブート}}
{{Related|Unified Extensible Firmware Interface}}
{{Related articles end}}
'''systemd-boot''' (旧名 '''gummiboot'''。ドイツ語で「ゴムボート」)は、設定された EFI イメージを実行するシンプルな [[UEFI]] [[ブートマネージャー]]です。デフォルトのエントリは設定されたパターン (glob) または矢印キーで操作する画面上のメニューによって選択されます。{{Pkg|systemd}} に含まれており、Arch システムにデフォルトでインストールされます。

systemd-boot は EFI 実行可能ファイル ([[EFISTUB]]、[[UEFI シェル]]、[[GRUB]]、[https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/boot-and-uefi#understanding-the-windows-boot-manager Windows ブートマネージャ]) のみを起動できることに注意してください。

== サポートされているファイルシステム ==

systemd-boot はファイルシステムのサポートを [[Arch ブートプロセス#UEFI|ファームウェア]] から引き継ぎます (少なくとも FAT12、FAT16、FAT32) さらに、{{ic|''esp''/EFI/systemd/drivers/}} にある [[Unified Extensible Firmware Interface#UEFI ドライバ|UEFI ドライバ]] を全てロードします。

== インストール ==

''systemd-boot'' は、{{Pkg|base}} メタパッケージの依存関係である {{Pkg|systemd}} パッケージとともに出荷されるため、追加のパッケージを手動でインストールする必要はありません。

== EFI ブートマネージャのインストール ==

''systemd-boot'' の EFI ブートマネージャをインストールする場合、まず UEFI モードでシステムが起動しているかどうか、[[Unified Extensible Firmware Interface#UEFI 変数|UEFI 変数]] が利用できるかどうか確かめてください。{{ic|efivar --list}} コマンドを実行することでチェックできます。または、efivar がインストールされていない場合は、{{ic|ls /sys/firmware/efi/efivars}} を実行してください (ディレクトリが存在する場合、システムは UEFI モードにブートされます)

このページでは ESP のマウントポイントを {{ic|''esp''}} として表します (大抵の場合は {{ic|/efi}} か {{ic|/boot}} です) これは、システムのマウントポイントに [[chroot]] していることを前提としています。

{{man|1|bootctl}} を使用して EFI システムパーティションに ''systemd-boot'' をインストールします:

# bootctl install

これにより、''systemd-boot'' UEFI ブートマネージャーが ESP にコピーされ、その UEFI ブートエントリが作成され、UEFI ブート順序の最初に設定されます。

* x64 UEFI では、{{ic|/usr/lib/systemd/boot/efi/systemd-bootx64.efi}} は {{ic|''esp''/EFI/systemd/systemd-bootx64.efi}} と {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} にコピーされます。
* IA32 UEFI では、{{ic|/usr/lib/systemd/boot/efi/systemd-bootia32.efi}} は {{ic|''esp''/EFI/systemd/systemd-bootia32.efi}} と {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} にコピーされます。

UEFI ブートエントリは "Linux Boot Manager" と呼ばれ、UEFI のビット数によって、ESP 上の {{ic|EFI}systemd-bootx64.efi}} か {{ic|EFI}systemd-bootia32.efi}} を指します。

{{Note|
* {{ic|bootctl install}} を実行すると、''systemd-boot'' は ESP を {{ic|/efi}},{{ic|/boot}},{{ic|/boot/efi}} に配置しようとします。{{ic|''esp''}} を別の場所に設定するには、{{ic|1=--esp-path=''esp''}} オプションを渡す必要があります。(詳細は {{man|1|bootctl|OPTIONS}} を参照)
* ''systemd-boot'' をインストールすると既存の {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} は上書きされます。(または、{{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} の IA32 UEFI)、例えば Microsoft 版のファイルなどです。
}}

インストールを完了するには、''systemd-boot'' を[[systemd-boot#設定|設定]]します。

=== XBOOTLDR を使用したインストール ===

カーネルと initramfs を ESP から分離するために、"Linux extended boot" タイプ (XBOOTLDR) の別の [[パーティショニング#/boot|/boot パーティション]]を作成することができます。これは、既存の [[EFI システムパーティション|ESP]] が小さすぎる [[Windows と Arch のデュアルブート]] 時に特に役立ちます。

通常どおり ESP を作成し、同じ物理ドライブに XBOOTLDR 用の別のパーティションを作成します。XBOOTLDR のパーティションタイプ GUID は {{ic|"bc13c2ff-59e6-4262-a352-b275fd6f7172}} である必要があります。XBOOTLDR パーティションのサイズは、インストールする全てのカーネルを収納できる十分な大きさが必要です。

{{Note|
* systemd-boot は、 ESP の場合のようにファイルシステムチェックを行いません。したがって、他のファイルシステムを使用することは可能ですが、 UEFI 実装が起動中にそれを読み取ることができる場合に限ります。
* "fast boot" モードが有効の場合、UEFI ファームウェアは ESP 以外のパーティションのロードをスキップすることがあります。これにより、''システム起動'' が XBOOTLDR パーティション上のエントリを見つけられなくなる可能性があります。XBOOTLDRを使用するには、"fast boot" を無効にする必要があります。
* XBOOTLDR パーティションは、system-boot が認識できるように ESP と同じ物理ディスク上になければならない場合があります。
}}

インストール中に、ESP を {{ic|/mnt/efi}} にマウントし、 {{ic|''boot''}} を {{ic|/mnt/boot}} にマウントします。

chroot になったら、次のコマンドを使用します:

# bootctl --esp-path=/efi --boot-path=/boot install

インストールを完了するには ''systemd-boot'' を[[#設定|設定]]します。

=== UEFI ブートマネージャの更新 ===

新しいバージョンの ''systemd-boot'' がリリースされるたびに、UEFI ブートマネージャはオプションでユーザーによって再インストールできます。これは手動または自動で行うことができ、以下にその2つの方法を説明します。

{{Note|UEFI ブートマネージャは独立した EFI 実行可能ファイルであり、任意のバージョンを使用してシステムをブートできます(部分的な更新は適用されません。pacman は ''systemd-boot'' インストーラーのみをインストールし、''systemd-boot'' 本体はインストールしません)ただし、新しいバージョンは新機能を追加したり、バグを修正したりする可能性があるため、''systemd-boot'' の更新はおそらく良いアイデアです。}}

{{Warning|[[セキュアブート]] が有効な場合、ブートローダーの更新に署名する必要があります。詳細は [[#セキュアブートのための署名]] を参照してください。}}

==== 手動で更新 ====

''bootctl'' を使用して ''systemd-boot'' を更新:

# bootctl update

{{Note|{{ic|bootctl install}} と同様に、''systemd-boot''は ESP を {{ic|/efi}}、{{ic|/boot}}、{{ic|/boot/efi}} に配置しようとします。{{ic|''esp''}} を別の場所に設定するには、{{ic|1=--esp-path=''esp''}} オプションを渡す必要があります。}}

==== 自動で更新 ====

''systemd-boot'' を自動的に更新するには、[[systemd#ユニットを使う|systemd サービス]] または [[pacman フック]] を使用してください。これらの2つの方法については、以下に説明します。

===== systemd サービス =====

バージョン 250 以降、{{Pkg|systemd}} には {{ic|systemd-boot-update.service}} が同梱されています。このサービスを [[有効化]] すると、次回の起動時にブートローダーが更新されます。

===== Pacman フック =====

{{AUR|systemd-boot-pacman-hook}} パッケージは {{Pkg|systemd}} がアップグレードされる度に実行される pacman フックを追加します。

systemd-boot-pacman-hook をインストールするのではなく、次のファイルを {{ic|/etc/pacman.d/hooks/}} に手動で配置することをお勧めします:

{{hc|/etc/pacman.d/hooks/95-systemd-boot.hook|2=
[Trigger]
Type = Package
Operation = Upgrade
Target = systemd

[Action]
Description = Gracefully upgrading systemd-boot...
When = PostTransaction
Exec = /usr/bin/systemctl restart systemd-boot-update.service
}}

=== セキュアブートのための署名 ===

[[セキュアブート]] が有効な場合、パッケージのアップグレード時にブートマネージャを自動的に署名するために、pacmanフックを追加したい場合:

{{hc|/etc/pacman.d/hooks/80-secureboot.hook|2=
[Trigger]
Operation = Install
Operation = Upgrade
Type = Path
Target = usr/lib/systemd/boot/efi/systemd-boot*.efi

[Action]
Description = Signing systemd-boot EFI binary for Secure Boot
When = PostTransaction
Exec = /bin/sh -c 'while read -r i; do sbsign --key ''/path/to/keyfile.key'' --cert ''/path/to/certificate.crt'' "$i"; done;'
Depends = sh
Depends = sbsigntools
NeedsTargets
}}

{{ic|''/path/to/keyfile.key''}} と {{ic|''/path/to/certificate.crt''}} をそれぞれ署名鍵と証明書に置き換えてください。このフックの詳細な理解には、{{man|1|sbsign}} を参照してください。

作成された {{ic|/usr/lib/systemd/boot/efi/systemd-boot*.efi.signed}} は、{{ic|bootctl install}} または {{ic|bootctl update}} によって自動的に認識されます。詳細は {{man|1|bootctl|SIGNED .EFI FILES}} を参照してください。

別の方法としてこちらも参照、[[Unified Extensible Firmware Interface/セキュアブート#pacman フックを使って自動的に署名する|sbctl]]

== 設定 ==

=== ローダー設定 ===

ローダーの設定は {{ic|''esp''/loader/loader.conf}} ファイルに保存されます。詳細は、{{man|5|loader.conf|OPTIONS}} を参照してください。

ローダーの設定例を以下に示します:

{{hc|''esp''/loader/loader.conf|
default arch.conf
timeout 4
console-mode max
editor no
}}

{{Tip|
* systemd-boot はインデント用のタブを受け入れません。代わりにスペースを使用してください。
* {{ic|default}} と {{ic|timeout}} はブートメニューで変更することができ、変更した場合は EFI 変数として保存されます。上記のオプションよりも優先して設定されます。
* {{ic|bootctl set-default ""}} を使用すると、 {{ic|default}} オプションに優先して EFI 変数をクリアできます。
* 基本的なローダーの設定ファイルは {{ic|/usr/share/systemd/bootctl/loader.conf}} に存在します。
* {{ic|timeout 0}} を設定している場合、{{ic|Space}} を押すことでブートメニューにアクセスできます。
* ブートローダー(エントリ選択中)が歪んで表示される場合や、誤った解像度が使用されている場合は、{{ic|console-mode}} を {{ic|auto}}(最適な解像度を選択するためのヒューリスティックスを使用)、{{ic|keep}}(ファームウェアが提供する解像度を維持)、または {{ic|2}}(最初の非 UEFI 標準解像度を選択しようと試みる)に設定してみることができます。}}

=== ローダーの追加 ===

''systemd-boot''は、起動元の[[EFI システムパーティション]]上の{{ic|/loader/entries/}}ディレクトリ内にある''.conf''ファイルおよび同一ディスク上の[[Systemd-boot#XBOOTLDR_を使用したインストール|XBOOTDR]]パーティションも検索対象とします。

{{Note|
* {{ic|''esp''/loader/entries/*.conf}}内のエントリーは{{ic|''esp/''}}ディレクトリ内のファイル(kernel, initramfs, imageなど)のみ参照でき、{{ic|''boot''/loader/entries/*.conf}}内のエントリーは{{ic|''boot/''}}ディレクトリ内のファイルのみ参照出来ます。
* ファイルパスはEFIシステムパーティションまたはXBOOTLDRパーティションをルートにしたパスです。例えばEFIシステムパーティションまたはXBOOTLDRパーティションが{{ic|/boot}}ディレクトリにマウントされている時は{{ic|/boot/vmlinuz-linux}}ファイルは{{ic|linux}}キーで{{ic|/vmlinuz-linux}}として指定する必要があります。
* [[セキュアブート]]が有効になっている場合、組み込みの{{ic|.cmdline}}を持つ[[ユニファイドカーネルイメージ]](UKI)はブートエントリーで指定したオプションや対話的に渡されるコマンドラインオプションを全て無視します。セキュアブートが無効の場合コマンドラインで渡されたオプションは組み込みの{{ic|.cmdline}}の内容を上書きします。
}}

[[UUID]] ''xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx''のボリュームからArch Linuxを起動するloaderファイルの例:
{{hc|''esp''/loader/entries/arch.conf|2=
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=UUID=''xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'' rw
}}
{{hc|''esp''/loader/entries/arch-fallback.conf|2=
title Arch Linux (fallback initramfs)
linux /vmlinuz-linux
initrd /initramfs-linux-fallback.img
options root=UUID=''xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'' rw
}}
全構成オプションの詳細については、[https://uapi-group.org/specifications/specs/boot_loader_specification/#type-1-boot-loader-specification-entries Boot Loader Specification]を参照してください。

''systemd-boot''は起動時に、{{ic|/EFI/Microsoft/Boot/Bootmgfw.efi}}の'''Windows Boot Manager'''、ファームウェア内の'''Apple macOS Boot Manager'''、{{ic|/shellx64.efi}}の[[Unified_Extensible_Firmware_Interface#UEFI_シェル|UEFIシェル]]、{{ic|/EFI/BOOT/bootx64.efi}}の'''EFIデフォルトローダー'''をチェックし、存在する場合それぞれ{{ic|auto-windows}}、{{ic|auto-osx}}、{{ic|auto-efi-shell}}、{{ic|auto-efi-default}}というタイトルで対応するエントリが生成されます。さらに{{ic|/EFI/Linux/}}に置かれた特別なカーネルファイルを検出します。これらのエントリは手動でローダーを構成する必要はありません。ただし他のEFIアプリケーションの自動検出機能は([[rEFInd]]とは異なり)備えていません、Linuxカーネルを起動するには手動でエントリを作成する必要があります。
{{Tip|
* 設定済みのブートエントリは、{{ic|bootctl list}}コマンドで表示できます。
* エントリファイルの例は{{ic|/usr/share/systemd/bootctl/arch.conf}}にあります。
* [[LVM]]、[[LUKS]]、[[dm-crypt]]、[[Btrfs]]などで必要な[[カーネルパラメータ]]はそれぞれのページを確認してください。
}}

{{Note|
[[マイクロコード#別個のマイクロコード_initramfs_ファイルを使う|外部のマイクロコードinitramfsイメージ]]を使用する場合(例えばBoosterをinitramfs生成ツールとして使用する場合)、{{ic|/boot/amd-ucode.img}}または{{ic|/boot/intel-ucode.img}}を別の{{ic|inird}}として指定し、メインのinitramfsイメージより'''前に'''記述する必要があります。
}}

==== EFI シェルや他の EFI アプリ ====

[[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]] を {{Pkg|edk2-shell}} パッケージとともにインストールした場合、"systemd-boot" は EFI ファイルが {{ic|''esp''/shellx64.efi}} に配置されると自動的に検出して新しいエントリを作成します。
これを実行するには、パッケージをインストールした後に以下のようなコマンドを使用します:

# cp /usr/share/edk2-shell/x64/Shell.efi /boot/shellx64.efi

それ以外の場合は、[[rEFInd#ツール|その他の EFI アプリケーション]] を ESP にインストールした場合、次のスニペットを使用できます。

{{Note|{{ic|efi}} 行のファイルパスパラメータは、[[EFI システムパーティション]] のルートに対して相対的です。もし EFI システムパーティションが {{ic|/boot}} にマウントされていて、EFI バイナリが {{ic|/boot/EFI/xx.efi}} と {{ic|/boot/yy.efi}} に存在する場合、それぞれのパラメータは {{ic|efi /EFI/xx.efi}} と {{ic|efi /yy.efi}} のように指定します。}}

{{hc|''esp''/loader/entries/fwupd.conf|
title Firmware updater
efi /EFI/tools/fwupdx64.efi
}}

{{hc|''esp''/loader/entries/gdisk.conf|
title GPT fdisk (gdisk)
efi /EFI/tools/gdisk_x64.efi
}}

===== Memtest86+ =====

これを機能させるには、{{pkg|memtest86+-efi}} をインストールする必要があります。また、セキュアブートを使用するときに EFI バイナリに署名する必要があります。

{{hc|''esp''/loader/entries/memtest.conf|
title Memtest86+
efi /memtest86+/memtest.efi
}}

===== Netboot =====

"systemd-boot" は [[Netboot]] をチェーンロードできます。{{ic|ipxe-arch.efi}} EFI バイナリとその署名をダウンロードし、それを検証した後、提案された場所に {{ic|''esp''/EFI/arch_netboot/arch_netboot.efi}} として配置します。

{{hc|''esp''/loader/entries/arch_netboot.conf|
title Arch Linux Netboot
efi /EFI/arch_netboot/arch_netboot.efi
}}

===== GRUB =====

''systemd-boot'' は [[GRUB]] をチェーンロードできます。{{ic|grubx64.efi}} バイナリの場所は、GRUB が ESP にインストールされた際に使用された {{ic|1=--bootloader-id=}} と一致します。

{{hc|''esp''/loader/entries/grub.conf|
title GRUB
efi /EFI/GRUB/grubx64.efi
}}

==== 別のディスクから起動 ====

"systemd-boot" は起動元の ESP や同一ディスク上のXBOOTLDRパーティション以外のパーティションからEFIバイナリを起動 [https://github.com/systemd/systemd/issues/3252 できませんが、] [[UEFI シェル]] を使ってそれを行うことができます。

まず、上記の [[#EFI シェルや他の EFI アプリ]] のセクションに従って、{{Pkg|edk2-shell}} パッケージをインストールします。UEFI シェルで "map" コマンドを使用して、対応する PARTUUID を持つパーティションの '''FS エイリアス''' (例:HD0a66666a2、HD0b、FS1、BLK7) を確認します。

次に、{{ic|exit}} コマンドを使用して Linux に戻り、UEFI シェルを通じてターゲット EFI プログラムを実行するための新しいローダーエントリを作成します:

{{hc|''esp''/loader/entries/windows.conf|
title Windows
efi /shellx64.efi
options -nointerrupt -nomap -noversion HD0b:EFI\Microsoft\Boot\Bootmgfw.efi
}}

{{ic|efi}} パスは、 {{ic|shellx64.efi}} がコピーされた "esp" パーティション内の場所と一致していることを確認してください。また、{{ic|shellx64.efi}} EFI ファイルは、"systemd-boot" による自動エントリ作成を避けるために他の場所に移動することもできます。

{{ic|HD0b}} は、前述の "FS エイリアス" に置き換えてください。

* {{ic|-nointerrupt}} オプションは、{{ic|Ctrl+c}} でターゲット EFI プログラムを中断しないようにします。
* {{ic|-nomap -noversion}} オプションは、デフォルトの UEFI シェルの挨拶を非表示にします。
* ターゲットEFIプログラムが終了した場合(例えばエラーで)にUEFIシェルが自動的にブートローダーに戻るようにするには、{{ic|-exit}} オプションを追加します。
* もし UEFI シェル内にまだ不要な出力がある場合、{{ic|-noconsoleout}} オプションを追加できます。

=== UEFI ファームウェアセットアップの起動 ===

systemd-boot は、デバイスのファームウェアが OS からセットアップに再起動することをサポートしている場合、UEFI ファームウェアセットアップに起動するエントリを自動的に追加します。

=== ハイバネーション ===

[[サスペンドとハイバネート]]の記事を参照してください。

=== パスワードで保護されたカーネルパラメータエディタ ===

{{ic|password}} 設定オプションをサポートしている {{AUR|systemd-boot-password}} をインストールすることもできます。{{ic|sbpctl generate}} を使ってオプションで指定する値を生成できます。

''systemd-boot-password'' は以下のコマンドでインストールしてください:

{{bc|1=# sbpctl install ''esp''}}

カーネルパラメータを編集する前にパスワードの入力が求められるようになります。

== ヒントとテクニック ==

=== ブートメニューで使用できるキー ===

ブートメニューで使用できるキー割り当てについては、{{man|7|systemd-boot|KEY BINDINGS}} を参照してください。

=== 再起動後の起動対象を選択する ===

ブートマネージャーは systemctl コマンドに統合されており、再起動後に起動させるオプションを選択できます。例えば、カスタムカーネルのエントリファイルが {{ic|''esp''/loader/entries/arch-custom.conf}} にあるとき、次のようにするとデフォルト設定はそのままにカスタムカーネルが起動します:

$ systemctl reboot --boot-loader-entry=arch-custom


マザーボードのファームウェアを起動させるときは次のようにします:

$ systemctl reboot --firmware-setup

=== ユニファイドカーネルイメージを使う ===

{{ic|''esp''/EFI/Linux/}} にある [[ユニファイドカーネルイメージ|Unified kernel image]] (UKI)は、systemd-boot によって自動的に読み込まれ、{{ic|''esp''/loader/entries}} にエントリを追加する必要はありません。(Unified kernel image は、systemd-boot によって識別されるためには、{{ic|.efi}} 拡張子を持っている必要があります。)

{{Tip|{{ic|''esp''/loader/entries/}} 内のファイルは、{{ic|''esp''/loader/loader.conf}} に {{ic|default}} が設定されていない場合、最初に起動されます。それらのエントリを削除するか、フルファイル名でデフォルトを設定してください。例:{{ic|1=default arch-linux.efi}}}}

=== ESP 上の Grml ===

{{Note|以下の手順は、Grml 専用ではありません。若干の調整で他のソフト (例: [http://www.system-rescue-cd.org/ SystemRescueCD]) のインストールも可能です。}}
{{Tip|{{ic|PKGBUILD}} が利用可能です: {{AUR|archiso-systemd-boot}}}}

[https://grml.org/ Grml] は、システム管理とレスキュー用のソフトウェアを集めた小さなライブシステムです。

Grml を ESP にインストールするには、カーネル {{ic|vmlinuz}}、 initramfs {{ic|initrd.img}}、圧縮イメージ {{ic|grml64-small.squashfs}} を iso ファイルから ESP にコピーするだけです。そのためには、まず [https://grml.org/ grml64-small.iso] ファイルをダウンロードして(マウントポイントは以降 ''mnt'' と表記される) ファイルをマウントします。カーネルと initramfs は {{ic|''mnt''/boot/grml6 small/}} にあり、圧縮されたイメージは {{ic|''mnt''/live/grml64-small/}} にあります。

次に、Grml 用のディレクトリを ESP に作成します:

# mkdir -p ''esp''/grml

上記のファイルをコピーします:

# cp ''mnt''/boot/grml64small/vmlinuz ''esp''/grml
# cp ''mnt''/boot/grml64small/initrd.img ''esp''/grml
# cp ''mnt''/live/grml64-small/grml64-small.squashfs ''esp''/grml

最後のステップで、システムブートローダー用のエントリを作成します。 {{ic|''esp''/loader/entries}} 次の内容の {{ic|grml.conf}} ファイルを作成します:

{{hc|''esp''/loader/entries/grml.conf|2=
title Grml Live Linux
linux /grml/vmlinuz
initrd /grml/initrd.img
options apm=power-off boot=live live-media-path=/grml/ nomce net.ifnames=0}}

使用可能なブートオプションの概要については、 [http://git.grml.org/?p=grml-live.git;a=blob_plain;f=templates/GRML/grml-cheatcodes.txt;hb=HEAD cheatcode for Grml]

=== ESP 上の Archiso ===

{{Tip|{{ic|PKGBUILD}} が利用可能です: {{AUR|archiso-systemd-boot}}}}

Grml と同様に、Arch Linux の ISO を使用することができます。そのためには、ISO ファイルからカーネル {{ic|vmlinuz-linux}}、initramfs {{ic|initramfs-linux.img}}、および squashfs イメージ {{ic|airootfs.sfs}} を EFI システムパーティションにコピーする必要があります。

最初に [https://archlinux.org/download/ archlinux-yyy.mm.dd-x86_64.iso] をダウンロードします。

次に、ESP に Archiso のディレクトリを作成します:

# mkdir -p ''esp''/EFI/archiso

そこに {{ic|arch}} ディレクトリの内容を抽出します:

# bsdtar -v -x --no-same-permissions --strip-components 1 -f archlinux-''YYYY''.''MM''.''DD''-x86_64.iso -C ''esp''/EFI/archiso arch

最後のステップでは、systemd-boot Loader のブートエントリを作成します:{{ic|''esp''/roader/entries}}:

{{hc|''esp''/loader/entries/arch-rescue.conf|2=
title Arch Linux (rescue system)
linux /EFI/archiso/boot/x86_64/vmlinuz-linux
initrd /EFI/archiso/boot/x86_64/initramfs-linux.img
options archisobasedir=/EFI/archiso archisosearchfilename=/EFI/archiso/boot/x86_64/vmlinuz-linux
}}

利用可能なブートオプションの概要については、[https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/blob/master/docs/README.bootparams README.bootparams for mkinitcpio-archiso] を参照してください。

=== BIOS システムでの systemd-boot ===

[https://systemd.io/BOOT_LOADER_SPECIFICATION/ ブートローダーの仕様] に従う BIOS システム用のブートローダーが必要な場合は、 BIOS システムで systemd-boot を押してサービスを開始できます。 [[Clover]] ブートローダーは BIOS システムからの起動をサポートし、シミュレートされた EFI 環境を提供します。

== トラブルシューティング ==

=== systemd-boot がブートエントリを表示しない ===

これは、カーネルへのパスが間違って指定されているなど、設定ファイルに関するさまざまな問題が原因である可能性があります。確認するには、次のコマンドを実行してください:

# bootctl

=== BIOS モードで起動後にインストール ===

{{Note|こちらの起動方法は推奨されません。}}

BIOS モードで OS を起動したいときも ''systemd-boot'' をインストールすることは可能です。ただし、起動時に ''systemd-boot'' の EFI ファイルを実行するようにファームウェアを設定する必要があります:

* 他の場所に機能する UEFI Shell がある場合。
* ファームウェアのインターフェイスから起動時にロードされる EFI ファイルを設定する。
* 一部のファームウェアは、UEFI に他のエントリが設定されていない場合、デフォルトで {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} を使用することがあります。

設定できる場合、インストールは簡単です: EFI シェルやファームウェアの設定インターフェイスを開いて、マシンのデフォルトの EFI ファイルを {{ic|''esp''/EFI/systemd/systemd-bootx64.efi}} (32ビット環境の場合 {{ic|systemd-bootia32.efi}}) に変更してください。

{{Note|Dell Latitude シリーズのファームウェアインターフェースは、UEFI ブートの設定に必要なすべてを提供しますが、UEFI シェルはコンピュータの ROM に書き込むことができません。}}

=== efibootmgr を使って手動エントリを追加する ===

{{ic|bootctl install}} コマンドが失敗した場合、{{Pkg|efibootmgr}} ユーティリティを使って EFI ブートエントリを手動で作成することができます:

# efibootmgr --create --disk /dev/sd''X'' --part ''Y'' --loader '\EFI\systemd\systemd-bootx64.efi' --label "Linux Boot Manager" --unicode

{{ic|/dev/sdXY}} は [[EFI システムパーティション]]に置き換えてください。

{{Note|EFI イメージのパスでは区切り文字としてバックスラッシュ ({{ic|\}}) を使用します。}}

=== Windows の bcdedit を使用した手動入力 ===

何らかの理由で Windows から EFI ブートエントリを作成する必要がある場合は、管理者プロンプトから次のコマンドを使用してください。

> bcdedit /copy {bootmgr} /d "Linux Boot Manager"
> bcdedit /set {''guid''} path \EFI\systemd\systemd-bootx64.efi

{{ic|''guid''}} を最初のコマンドによってリターンされた ID に置き換えます。これをデフォルトのエントリとして設定するには:

> bcdedit /default {''guid''}

=== Windows をアップグレードした後にメニューが表示されない ===

[[Unified Extensible Firmware Interface#Windows によってブート順序が変わってしまう]]を見てください。

=== Windows BitLocker TPM ロック解除のサポートを追加 ===

BitLocker による回復キーの要求を停止するには、次の行を ''loader.conf'' に追加します。

{{hc|''esp''/loader/loader.conf|
reboot-for-bitlocker yes
}}

これにより、''BootNext'' UEFI 変数が設定され、BitLocker が回復キーを必要とせずに ''Windows ブートマネージャー'' がロードされます。これは 1 回限りの変更であり、''systemd-boot'' がデフォルトのブートローダーのままです。Windows が自動検出された場合は、エントリとして指定する必要はありません。

これは実験的な機能なので、必ず {{man|5|loader.conf}} を参照してください。

== 参照 ==

* https://systemd.io/BOOT/
* https://bbs.archlinux.org/viewtopic.php?id=254374
* https://uapi-group.org/specifications/specs/boot_loader_specification/

Systemd-boot

2025-12-14T05:28:22Z

N: /* ローダーの追加 */

{{lowercase title}}
[[Category:ブートローダー]]
[[de:Gummiboot]]
[[en:Systemd-boot]]
[[es:Systemd-boot]]
[[pt:Systemd-boot]]
[[ru:Systemd-boot]]
[[zh-hans:Systemd-boot]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|ブートローダー}}
{{Related|セキュアブート}}
{{Related|Unified Extensible Firmware Interface}}
{{Related articles end}}
'''systemd-boot''' (旧名 '''gummiboot'''。ドイツ語で「ゴムボート」)は、設定された EFI イメージを実行するシンプルな [[UEFI]] [[ブートマネージャー]]です。デフォルトのエントリは設定されたパターン (glob) または矢印キーで操作する画面上のメニューによって選択されます。{{Pkg|systemd}} に含まれており、Arch システムにデフォルトでインストールされます。

systemd-boot は EFI 実行可能ファイル ([[EFISTUB]]、[[UEFI シェル]]、[[GRUB]]、[https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/boot-and-uefi#understanding-the-windows-boot-manager Windows ブートマネージャ]) のみを起動できることに注意してください。

== サポートされているファイルシステム ==

systemd-boot はファイルシステムのサポートを [[Arch ブートプロセス#UEFI|ファームウェア]] から引き継ぎます (少なくとも FAT12、FAT16、FAT32) さらに、{{ic|''esp''/EFI/systemd/drivers/}} にある [[Unified Extensible Firmware Interface#UEFI ドライバ|UEFI ドライバ]] を全てロードします。

== インストール ==

''systemd-boot'' は、{{Pkg|base}} メタパッケージの依存関係である {{Pkg|systemd}} パッケージとともに出荷されるため、追加のパッケージを手動でインストールする必要はありません。

== EFI ブートマネージャのインストール ==

''systemd-boot'' の EFI ブートマネージャをインストールする場合、まず UEFI モードでシステムが起動しているかどうか、[[Unified Extensible Firmware Interface#UEFI 変数|UEFI 変数]] が利用できるかどうか確かめてください。{{ic|efivar --list}} コマンドを実行することでチェックできます。または、efivar がインストールされていない場合は、{{ic|ls /sys/firmware/efi/efivars}} を実行してください (ディレクトリが存在する場合、システムは UEFI モードにブートされます)

このページでは ESP のマウントポイントを {{ic|''esp''}} として表します (大抵の場合は {{ic|/efi}} か {{ic|/boot}} です) これは、システムのマウントポイントに [[chroot]] していることを前提としています。

{{man|1|bootctl}} を使用して EFI システムパーティションに ''systemd-boot'' をインストールします:

# bootctl install

これにより、''systemd-boot'' UEFI ブートマネージャーが ESP にコピーされ、その UEFI ブートエントリが作成され、UEFI ブート順序の最初に設定されます。

* x64 UEFI では、{{ic|/usr/lib/systemd/boot/efi/systemd-bootx64.efi}} は {{ic|''esp''/EFI/systemd/systemd-bootx64.efi}} と {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} にコピーされます。
* IA32 UEFI では、{{ic|/usr/lib/systemd/boot/efi/systemd-bootia32.efi}} は {{ic|''esp''/EFI/systemd/systemd-bootia32.efi}} と {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} にコピーされます。

UEFI ブートエントリは "Linux Boot Manager" と呼ばれ、UEFI のビット数によって、ESP 上の {{ic|EFI}systemd-bootx64.efi}} か {{ic|EFI}systemd-bootia32.efi}} を指します。

{{Note|
* {{ic|bootctl install}} を実行すると、''systemd-boot'' は ESP を {{ic|/efi}},{{ic|/boot}},{{ic|/boot/efi}} に配置しようとします。{{ic|''esp''}} を別の場所に設定するには、{{ic|1=--esp-path=''esp''}} オプションを渡す必要があります。(詳細は {{man|1|bootctl|OPTIONS}} を参照)
* ''systemd-boot'' をインストールすると既存の {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} は上書きされます。(または、{{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}} の IA32 UEFI)、例えば Microsoft 版のファイルなどです。
}}

インストールを完了するには、''systemd-boot'' を[[systemd-boot#設定|設定]]します。

=== XBOOTLDR を使用したインストール ===

カーネルと initramfs を ESP から分離するために、"Linux extended boot" タイプ (XBOOTLDR) の別の [[パーティショニング#/boot|/boot パーティション]]を作成することができます。これは、既存の [[EFI システムパーティション|ESP]] が小さすぎる [[Windows と Arch のデュアルブート]] 時に特に役立ちます。

通常どおり ESP を作成し、同じ物理ドライブに XBOOTLDR 用の別のパーティションを作成します。XBOOTLDR のパーティションタイプ GUID は {{ic|"bc13c2ff-59e6-4262-a352-b275fd6f7172}} である必要があります。XBOOTLDR パーティションのサイズは、インストールする全てのカーネルを収納できる十分な大きさが必要です。

{{Note|
* systemd-boot は、 ESP の場合のようにファイルシステムチェックを行いません。したがって、他のファイルシステムを使用することは可能ですが、 UEFI 実装が起動中にそれを読み取ることができる場合に限ります。
* "fast boot" モードが有効の場合、UEFI ファームウェアは ESP 以外のパーティションのロードをスキップすることがあります。これにより、''システム起動'' が XBOOTLDR パーティション上のエントリを見つけられなくなる可能性があります。XBOOTLDRを使用するには、"fast boot" を無効にする必要があります。
* XBOOTLDR パーティションは、system-boot が認識できるように ESP と同じ物理ディスク上になければならない場合があります。
}}

インストール中に、ESP を {{ic|/mnt/efi}} にマウントし、 {{ic|''boot''}} を {{ic|/mnt/boot}} にマウントします。

chroot になったら、次のコマンドを使用します:

# bootctl --esp-path=/efi --boot-path=/boot install

インストールを完了するには ''systemd-boot'' を[[#設定|設定]]します。

=== UEFI ブートマネージャの更新 ===

新しいバージョンの ''systemd-boot'' がリリースされるたびに、UEFI ブートマネージャはオプションでユーザーによって再インストールできます。これは手動または自動で行うことができ、以下にその2つの方法を説明します。

{{Note|UEFI ブートマネージャは独立した EFI 実行可能ファイルであり、任意のバージョンを使用してシステムをブートできます(部分的な更新は適用されません。pacman は ''systemd-boot'' インストーラーのみをインストールし、''systemd-boot'' 本体はインストールしません)ただし、新しいバージョンは新機能を追加したり、バグを修正したりする可能性があるため、''systemd-boot'' の更新はおそらく良いアイデアです。}}

{{Warning|[[セキュアブート]] が有効な場合、ブートローダーの更新に署名する必要があります。詳細は [[#セキュアブートのための署名]] を参照してください。}}

==== 手動で更新 ====

''bootctl'' を使用して ''systemd-boot'' を更新:

# bootctl update

{{Note|{{ic|bootctl install}} と同様に、''systemd-boot''は ESP を {{ic|/efi}}、{{ic|/boot}}、{{ic|/boot/efi}} に配置しようとします。{{ic|''esp''}} を別の場所に設定するには、{{ic|1=--esp-path=''esp''}} オプションを渡す必要があります。}}

==== 自動で更新 ====

''systemd-boot'' を自動的に更新するには、[[systemd#ユニットを使う|systemd サービス]] または [[pacman フック]] を使用してください。これらの2つの方法については、以下に説明します。

===== systemd サービス =====

バージョン 250 以降、{{Pkg|systemd}} には {{ic|systemd-boot-update.service}} が同梱されています。このサービスを [[有効化]] すると、次回の起動時にブートローダーが更新されます。

===== Pacman フック =====

{{AUR|systemd-boot-pacman-hook}} パッケージは {{Pkg|systemd}} がアップグレードされる度に実行される pacman フックを追加します。

systemd-boot-pacman-hook をインストールするのではなく、次のファイルを {{ic|/etc/pacman.d/hooks/}} に手動で配置することをお勧めします:

{{hc|/etc/pacman.d/hooks/95-systemd-boot.hook|2=
[Trigger]
Type = Package
Operation = Upgrade
Target = systemd

[Action]
Description = Gracefully upgrading systemd-boot...
When = PostTransaction
Exec = /usr/bin/systemctl restart systemd-boot-update.service
}}

=== セキュアブートのための署名 ===

[[セキュアブート]] が有効な場合、パッケージのアップグレード時にブートマネージャを自動的に署名するために、pacmanフックを追加したい場合:

{{hc|/etc/pacman.d/hooks/80-secureboot.hook|2=
[Trigger]
Operation = Install
Operation = Upgrade
Type = Path
Target = usr/lib/systemd/boot/efi/systemd-boot*.efi

[Action]
Description = Signing systemd-boot EFI binary for Secure Boot
When = PostTransaction
Exec = /bin/sh -c 'while read -r i; do sbsign --key ''/path/to/keyfile.key'' --cert ''/path/to/certificate.crt'' "$i"; done;'
Depends = sh
Depends = sbsigntools
NeedsTargets
}}

{{ic|''/path/to/keyfile.key''}} と {{ic|''/path/to/certificate.crt''}} をそれぞれ署名鍵と証明書に置き換えてください。このフックの詳細な理解には、{{man|1|sbsign}} を参照してください。

作成された {{ic|/usr/lib/systemd/boot/efi/systemd-boot*.efi.signed}} は、{{ic|bootctl install}} または {{ic|bootctl update}} によって自動的に認識されます。詳細は {{man|1|bootctl|SIGNED .EFI FILES}} を参照してください。

別の方法としてこちらも参照、[[Unified Extensible Firmware Interface/セキュアブート#pacman フックを使って自動的に署名する|sbctl]]

== 設定 ==

=== ローダー設定 ===

ローダーの設定は {{ic|''esp''/loader/loader.conf}} ファイルに保存されます。詳細は、{{man|5|loader.conf|OPTIONS}} を参照してください。

ローダーの設定例を以下に示します:

{{hc|''esp''/loader/loader.conf|
default arch.conf
timeout 4
console-mode max
editor no
}}

{{Tip|
* systemd-boot はインデント用のタブを受け入れません。代わりにスペースを使用してください。
* {{ic|default}} と {{ic|timeout}} はブートメニューで変更することができ、変更した場合は EFI 変数として保存されます。上記のオプションよりも優先して設定されます。
* {{ic|bootctl set-default ""}} を使用すると、 {{ic|default}} オプションに優先して EFI 変数をクリアできます。
* 基本的なローダーの設定ファイルは {{ic|/usr/share/systemd/bootctl/loader.conf}} に存在します。
* {{ic|timeout 0}} を設定している場合、{{ic|Space}} を押すことでブートメニューにアクセスできます。
* ブートローダー(エントリ選択中)が歪んで表示される場合や、誤った解像度が使用されている場合は、{{ic|console-mode}} を {{ic|auto}}(最適な解像度を選択するためのヒューリスティックスを使用)、{{ic|keep}}(ファームウェアが提供する解像度を維持)、または {{ic|2}}(最初の非 UEFI 標準解像度を選択しようと試みる)に設定してみることができます。}}

=== ローダーの追加 ===

''systemd-boot''は、起動元の[[EFI システムパーティション]]上の{{ic|/loader/entries/}}ディレクトリ内にある''.conf''ファイルおよび同一ディスク上の[[Systemd-boot#XBOOTLDR_を使用したインストール|XBOOTDR]]パーティションも検索対象とします。

{{Note|
* {{ic|''esp''/loader/entries/*.conf}}内のエントリーは{{ic|''esp/''}}ディレクトリ内のファイル(kernel, initramfs, imageなど)のみ参照でき、{{ic|''boot''/loader/entries/*.conf}}内のエントリーは{{ic|''boot/''}}ディレクトリ内のファイルのみ参照出来ます。
* ファイルパスはEFIシステムパーティションまたはXBOOTLDRパーティションをルートにしたパスです。例えばEFIシステムパーティションまたはXBOOTLDRパーティションが{{ic|/boot}}ディレクトリにマウントされている時は{{ic|/boot/vmlinuz-linux}}ファイルは{{ic|linux}}キーで{{ic|/vmlinuz-linux}}として指定する必要があります。
* [[セキュアブート]]が有効になっている場合、組み込みの{{ic|.cmdline}}を持つ[[ユニファイドカーネルイメージ]](UKI)はブートエントリーで指定したオプションや対話的に渡されるコマンドラインオプションを全て無視します。セキュアブートが無効の場合コマンドラインで渡されたオプションは組み込みの{{ic|.cmdline}}の内容を上書きします。
}}

UUID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxのボリュームからArch Linuxを起動するloaderファイルの例:
{{hc|''esp''/loader/entries/arch.conf|2=
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx rw
}}
{{hc|''esp''/loader/entries/arch-fallback.conf|2=
title Arch Linux (fallback initramfs)
linux /vmlinuz-linux
initrd /initramfs-linux-fallback.img
options root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx rw
}}
全構成オプションの詳細については、[https://uapi-group.org/specifications/specs/boot_loader_specification/#type-1-boot-loader-specification-entries Boot Loader Specification]を参照してください。

''systemd-boot''は起動時に、{{ic|/EFI/Microsoft/Boot/Bootmgfw.efi}}の'''Windows Boot Manager'''、ファームウェア内の'''Apple macOS Boot Manager'''、{{ic|/shellx64.efi}}の[[Unified_Extensible_Firmware_Interface#UEFI_シェル|UEFIシェル]]、{{ic|/EFI/BOOT/bootx64.efi}}の'''EFIデフォルトローダー'''をチェックし、存在する場合それぞれ{{ic|auto-windows}}、{{ic|auto-osx}}、{{ic|auto-efi-shell}}、{{ic|auto-efi-default}}というタイトルで対応するエントリが生成されます。さらに{{ic|/EFI/Linux/}}に置かれた特別なカーネルファイルを検出します。これらのエントリは手動でローダーを構成する必要はありません。ただし他のEFIアプリケーションの自動検出機能は([[rEFInd]]とは異なり)備えていません、Linuxカーネルを起動するには手動でエントリを作成する必要があります。
{{Tip|
* 設定済みのブートエントリは、{{ic|bootctl list}}コマンドで表示できます。
* エントリファイルの例は{{ic|/usr/share/systemd/bootctl/arch.conf}}にあります。
* [[LVM]]、[[LUKS]]、[[dm-crypt]]、[[Btrfs]]などで必要な[[カーネルパラメータ]]はそれぞれのページを確認してください。
}}

{{Note|
[[マイクロコード#別個のマイクロコード_initramfs_ファイルを使う|外部のマイクロコードinitramfsイメージ]]を使用する場合(例えばBoosterをinitramfs生成ツールとして使用する場合)、{{ic|/boot/amd-ucode.img}}または{{ic|/boot/intel-ucode.img}}を別の{{ic|inird}}として指定し、メインのinitramfsイメージより'''前に'''記述する必要があります。
}}

==== EFI シェルや他の EFI アプリ ====

[[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]] を {{Pkg|edk2-shell}} パッケージとともにインストールした場合、"systemd-boot" は EFI ファイルが {{ic|''esp''/shellx64.efi}} に配置されると自動的に検出して新しいエントリを作成します。
これを実行するには、パッケージをインストールした後に以下のようなコマンドを使用します:

# cp /usr/share/edk2-shell/x64/Shell.efi /boot/shellx64.efi

それ以外の場合は、[[rEFInd#ツール|その他の EFI アプリケーション]] を ESP にインストールした場合、次のスニペットを使用できます。

{{Note|{{ic|efi}} 行のファイルパスパラメータは、[[EFI システムパーティション]] のルートに対して相対的です。もし EFI システムパーティションが {{ic|/boot}} にマウントされていて、EFI バイナリが {{ic|/boot/EFI/xx.efi}} と {{ic|/boot/yy.efi}} に存在する場合、それぞれのパラメータは {{ic|efi /EFI/xx.efi}} と {{ic|efi /yy.efi}} のように指定します。}}

{{hc|''esp''/loader/entries/fwupd.conf|
title Firmware updater
efi /EFI/tools/fwupdx64.efi
}}

{{hc|''esp''/loader/entries/gdisk.conf|
title GPT fdisk (gdisk)
efi /EFI/tools/gdisk_x64.efi
}}

===== Memtest86+ =====

これを機能させるには、{{pkg|memtest86+-efi}} をインストールする必要があります。また、セキュアブートを使用するときに EFI バイナリに署名する必要があります。

{{hc|''esp''/loader/entries/memtest.conf|
title Memtest86+
efi /memtest86+/memtest.efi
}}

===== Netboot =====

"systemd-boot" は [[Netboot]] をチェーンロードできます。{{ic|ipxe-arch.efi}} EFI バイナリとその署名をダウンロードし、それを検証した後、提案された場所に {{ic|''esp''/EFI/arch_netboot/arch_netboot.efi}} として配置します。

{{hc|''esp''/loader/entries/arch_netboot.conf|
title Arch Linux Netboot
efi /EFI/arch_netboot/arch_netboot.efi
}}

===== GRUB =====

''systemd-boot'' は [[GRUB]] をチェーンロードできます。{{ic|grubx64.efi}} バイナリの場所は、GRUB が ESP にインストールされた際に使用された {{ic|1=--bootloader-id=}} と一致します。

{{hc|''esp''/loader/entries/grub.conf|
title GRUB
efi /EFI/GRUB/grubx64.efi
}}

==== 別のディスクから起動 ====

"systemd-boot" は起動元の ESP や同一ディスク上のXBOOTLDRパーティション以外のパーティションからEFIバイナリを起動 [https://github.com/systemd/systemd/issues/3252 できませんが、] [[UEFI シェル]] を使ってそれを行うことができます。

まず、上記の [[#EFI シェルや他の EFI アプリ]] のセクションに従って、{{Pkg|edk2-shell}} パッケージをインストールします。UEFI シェルで "map" コマンドを使用して、対応する PARTUUID を持つパーティションの '''FS エイリアス''' (例:HD0a66666a2、HD0b、FS1、BLK7) を確認します。

次に、{{ic|exit}} コマンドを使用して Linux に戻り、UEFI シェルを通じてターゲット EFI プログラムを実行するための新しいローダーエントリを作成します:

{{hc|''esp''/loader/entries/windows.conf|
title Windows
efi /shellx64.efi
options -nointerrupt -nomap -noversion HD0b:EFI\Microsoft\Boot\Bootmgfw.efi
}}

{{ic|efi}} パスは、 {{ic|shellx64.efi}} がコピーされた "esp" パーティション内の場所と一致していることを確認してください。また、{{ic|shellx64.efi}} EFI ファイルは、"systemd-boot" による自動エントリ作成を避けるために他の場所に移動することもできます。

{{ic|HD0b}} は、前述の "FS エイリアス" に置き換えてください。

* {{ic|-nointerrupt}} オプションは、{{ic|Ctrl+c}} でターゲット EFI プログラムを中断しないようにします。
* {{ic|-nomap -noversion}} オプションは、デフォルトの UEFI シェルの挨拶を非表示にします。
* ターゲットEFIプログラムが終了した場合(例えばエラーで)にUEFIシェルが自動的にブートローダーに戻るようにするには、{{ic|-exit}} オプションを追加します。
* もし UEFI シェル内にまだ不要な出力がある場合、{{ic|-noconsoleout}} オプションを追加できます。

=== UEFI ファームウェアセットアップの起動 ===

systemd-boot は、デバイスのファームウェアが OS からセットアップに再起動することをサポートしている場合、UEFI ファームウェアセットアップに起動するエントリを自動的に追加します。

=== ハイバネーション ===

[[サスペンドとハイバネート]]の記事を参照してください。

=== パスワードで保護されたカーネルパラメータエディタ ===

{{ic|password}} 設定オプションをサポートしている {{AUR|systemd-boot-password}} をインストールすることもできます。{{ic|sbpctl generate}} を使ってオプションで指定する値を生成できます。

''systemd-boot-password'' は以下のコマンドでインストールしてください:

{{bc|1=# sbpctl install ''esp''}}

カーネルパラメータを編集する前にパスワードの入力が求められるようになります。

== ヒントとテクニック ==

=== ブートメニューで使用できるキー ===

ブートメニューで使用できるキー割り当てについては、{{man|7|systemd-boot|KEY BINDINGS}} を参照してください。

=== 再起動後の起動対象を選択する ===

ブートマネージャーは systemctl コマンドに統合されており、再起動後に起動させるオプションを選択できます。例えば、カスタムカーネルのエントリファイルが {{ic|''esp''/loader/entries/arch-custom.conf}} にあるとき、次のようにするとデフォルト設定はそのままにカスタムカーネルが起動します:

$ systemctl reboot --boot-loader-entry=arch-custom


マザーボードのファームウェアを起動させるときは次のようにします:

$ systemctl reboot --firmware-setup

=== ユニファイドカーネルイメージを使う ===

{{ic|''esp''/EFI/Linux/}} にある [[ユニファイドカーネルイメージ|Unified kernel image]] (UKI)は、systemd-boot によって自動的に読み込まれ、{{ic|''esp''/loader/entries}} にエントリを追加する必要はありません。(Unified kernel image は、systemd-boot によって識別されるためには、{{ic|.efi}} 拡張子を持っている必要があります。)

{{Tip|{{ic|''esp''/loader/entries/}} 内のファイルは、{{ic|''esp''/loader/loader.conf}} に {{ic|default}} が設定されていない場合、最初に起動されます。それらのエントリを削除するか、フルファイル名でデフォルトを設定してください。例:{{ic|1=default arch-linux.efi}}}}

=== ESP 上の Grml ===

{{Note|以下の手順は、Grml 専用ではありません。若干の調整で他のソフト (例: [http://www.system-rescue-cd.org/ SystemRescueCD]) のインストールも可能です。}}
{{Tip|{{ic|PKGBUILD}} が利用可能です: {{AUR|archiso-systemd-boot}}}}

[https://grml.org/ Grml] は、システム管理とレスキュー用のソフトウェアを集めた小さなライブシステムです。

Grml を ESP にインストールするには、カーネル {{ic|vmlinuz}}、 initramfs {{ic|initrd.img}}、圧縮イメージ {{ic|grml64-small.squashfs}} を iso ファイルから ESP にコピーするだけです。そのためには、まず [https://grml.org/ grml64-small.iso] ファイルをダウンロードして(マウントポイントは以降 ''mnt'' と表記される) ファイルをマウントします。カーネルと initramfs は {{ic|''mnt''/boot/grml6 small/}} にあり、圧縮されたイメージは {{ic|''mnt''/live/grml64-small/}} にあります。

次に、Grml 用のディレクトリを ESP に作成します:

# mkdir -p ''esp''/grml

上記のファイルをコピーします:

# cp ''mnt''/boot/grml64small/vmlinuz ''esp''/grml
# cp ''mnt''/boot/grml64small/initrd.img ''esp''/grml
# cp ''mnt''/live/grml64-small/grml64-small.squashfs ''esp''/grml

最後のステップで、システムブートローダー用のエントリを作成します。 {{ic|''esp''/loader/entries}} 次の内容の {{ic|grml.conf}} ファイルを作成します:

{{hc|''esp''/loader/entries/grml.conf|2=
title Grml Live Linux
linux /grml/vmlinuz
initrd /grml/initrd.img
options apm=power-off boot=live live-media-path=/grml/ nomce net.ifnames=0}}

使用可能なブートオプションの概要については、 [http://git.grml.org/?p=grml-live.git;a=blob_plain;f=templates/GRML/grml-cheatcodes.txt;hb=HEAD cheatcode for Grml]

=== ESP 上の Archiso ===

{{Tip|{{ic|PKGBUILD}} が利用可能です: {{AUR|archiso-systemd-boot}}}}

Grml と同様に、Arch Linux の ISO を使用することができます。そのためには、ISO ファイルからカーネル {{ic|vmlinuz-linux}}、initramfs {{ic|initramfs-linux.img}}、および squashfs イメージ {{ic|airootfs.sfs}} を EFI システムパーティションにコピーする必要があります。

最初に [https://archlinux.org/download/ archlinux-yyy.mm.dd-x86_64.iso] をダウンロードします。

次に、ESP に Archiso のディレクトリを作成します:

# mkdir -p ''esp''/EFI/archiso

そこに {{ic|arch}} ディレクトリの内容を抽出します:

# bsdtar -v -x --no-same-permissions --strip-components 1 -f archlinux-''YYYY''.''MM''.''DD''-x86_64.iso -C ''esp''/EFI/archiso arch

最後のステップでは、systemd-boot Loader のブートエントリを作成します:{{ic|''esp''/roader/entries}}:

{{hc|''esp''/loader/entries/arch-rescue.conf|2=
title Arch Linux (rescue system)
linux /EFI/archiso/boot/x86_64/vmlinuz-linux
initrd /EFI/archiso/boot/x86_64/initramfs-linux.img
options archisobasedir=/EFI/archiso archisosearchfilename=/EFI/archiso/boot/x86_64/vmlinuz-linux
}}

利用可能なブートオプションの概要については、[https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/-/blob/master/docs/README.bootparams README.bootparams for mkinitcpio-archiso] を参照してください。

=== BIOS システムでの systemd-boot ===

[https://systemd.io/BOOT_LOADER_SPECIFICATION/ ブートローダーの仕様] に従う BIOS システム用のブートローダーが必要な場合は、 BIOS システムで systemd-boot を押してサービスを開始できます。 [[Clover]] ブートローダーは BIOS システムからの起動をサポートし、シミュレートされた EFI 環境を提供します。

== トラブルシューティング ==

=== systemd-boot がブートエントリを表示しない ===

これは、カーネルへのパスが間違って指定されているなど、設定ファイルに関するさまざまな問題が原因である可能性があります。確認するには、次のコマンドを実行してください:

# bootctl

=== BIOS モードで起動後にインストール ===

{{Note|こちらの起動方法は推奨されません。}}

BIOS モードで OS を起動したいときも ''systemd-boot'' をインストールすることは可能です。ただし、起動時に ''systemd-boot'' の EFI ファイルを実行するようにファームウェアを設定する必要があります:

* 他の場所に機能する UEFI Shell がある場合。
* ファームウェアのインターフェイスから起動時にロードされる EFI ファイルを設定する。
* 一部のファームウェアは、UEFI に他のエントリが設定されていない場合、デフォルトで {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} を使用することがあります。

設定できる場合、インストールは簡単です: EFI シェルやファームウェアの設定インターフェイスを開いて、マシンのデフォルトの EFI ファイルを {{ic|''esp''/EFI/systemd/systemd-bootx64.efi}} (32ビット環境の場合 {{ic|systemd-bootia32.efi}}) に変更してください。

{{Note|Dell Latitude シリーズのファームウェアインターフェースは、UEFI ブートの設定に必要なすべてを提供しますが、UEFI シェルはコンピュータの ROM に書き込むことができません。}}

=== efibootmgr を使って手動エントリを追加する ===

{{ic|bootctl install}} コマンドが失敗した場合、{{Pkg|efibootmgr}} ユーティリティを使って EFI ブートエントリを手動で作成することができます:

# efibootmgr --create --disk /dev/sd''X'' --part ''Y'' --loader '\EFI\systemd\systemd-bootx64.efi' --label "Linux Boot Manager" --unicode

{{ic|/dev/sdXY}} は [[EFI システムパーティション]]に置き換えてください。

{{Note|EFI イメージのパスでは区切り文字としてバックスラッシュ ({{ic|\}}) を使用します。}}

=== Windows の bcdedit を使用した手動入力 ===

何らかの理由で Windows から EFI ブートエントリを作成する必要がある場合は、管理者プロンプトから次のコマンドを使用してください。

> bcdedit /copy {bootmgr} /d "Linux Boot Manager"
> bcdedit /set {''guid''} path \EFI\systemd\systemd-bootx64.efi

{{ic|''guid''}} を最初のコマンドによってリターンされた ID に置き換えます。これをデフォルトのエントリとして設定するには:

> bcdedit /default {''guid''}

=== Windows をアップグレードした後にメニューが表示されない ===

[[Unified Extensible Firmware Interface#Windows によってブート順序が変わってしまう]]を見てください。

=== Windows BitLocker TPM ロック解除のサポートを追加 ===

BitLocker による回復キーの要求を停止するには、次の行を ''loader.conf'' に追加します。

{{hc|''esp''/loader/loader.conf|
reboot-for-bitlocker yes
}}

これにより、''BootNext'' UEFI 変数が設定され、BitLocker が回復キーを必要とせずに ''Windows ブートマネージャー'' がロードされます。これは 1 回限りの変更であり、''systemd-boot'' がデフォルトのブートローダーのままです。Windows が自動検出された場合は、エントリとして指定する必要はありません。

これは実験的な機能なので、必ず {{man|5|loader.conf}} を参照してください。

== 参照 ==

* https://systemd.io/BOOT/
* https://bbs.archlinux.org/viewtopic.php?id=254374
* https://uapi-group.org/specifications/specs/boot_loader_specification/

Bluetooth

2025-12-06T13:14:57Z

N: /* Windows での展開 */

[[Category:Bluetooth]]
[[de:Bluetooth]]
[[en:Bluetooth]]
[[es:Bluetooth]]
[[ru:Bluetooth]]
[[zh-hans:Bluetooth]]
{{Related articles start}}
{{Related|Bluetooth マウス}}
{{Related|Bluetooth キーボード}}
{{Related|Bluetooth ヘッドセット}}
{{Related|Blueman}}
{{Related|ObexFTP}}
{{Related articles end}}
[[Wikipedia:ja:Bluetooth|Bluetooth]] は携帯電話やコンピュータなどの電子デバイス用の近距離無線通信規格です。Linux においては、Bluetooth プロトコルスタックの実装として [http://www.bluez.org/ BlueZ] が標準的に使われています。

== インストール ==

# Bluetooth プロトコロスタックを提供する、{{Pkg|bluez}} パッケージを[[インストール]]します。
# {{ic|bluetoothctl}} ユーティリティを提供する、{{Pkg|bluez-utils}} を[[インストール]]します。{{Pkg|bluez-deprecated-tools}} を[[インストール]]して、[[#非推奨の BlueZ ツール|非推奨の BlueZ ツール]] を追加します。
# 一般的な Bluetooth ドライバは、{{ic|btusb}} カーネルモジュールです。このモジュールがロードされているかどうかを[[カーネルモジュール#情報を取得|確認]]してください。もしロードされていなければ、[[カーネルモジュール#手動でモジュールを扱う|モジュールをロード]]してください。
# {{ic|bluetooth.service}} を[[起動/有効化]]します。

{{Note|
* デフォルトでは bluetooth デーモンは {{ic|lp}} [[ユーザーとグループ#システムグループ|グループ]]のメンバーのユーザーだけに bnep0 デバイスを提供します。bluetooth テザリングに接続するときはユーザーをグループに追加しておいてください。必要なグループは {{ic|/etc/dbus-1/system.d/bluetooth.conf}} ファイルで変更することができます。
* Bluetooth アダプターには Wi-Fi カードがバンドルされているものもあります (例: [https://www.intel.com/content/www/us/en/wireless-products/centrino-advanced-n-6235.html Intel Centrino]{{Dead link|2023|09|16|status=404}})。これらの Bluetooth アダプターをカーネルから見えるようにするには、まず Wi-Fi カードを有効にする必要があります (大体はラップトップ上のキーボードショートカットを使う)。
* Bluetooth カードによってはネットワークアダプタと衝突することがあります (例: Broadcom)。したがって、ネットワークサービスを起動する前に Bluetooth デバイスを接続するようにしてください。
* hcitool や hciconfig などのツールは上流では非推奨となっており、{{Pkg|bluez-utils}} にはもはや含まれていません。アップデートされないことが決まっているため、スクリプトの中で使用している場合は使わないように書き換えることを推奨します。それでも使いたい場合は {{Pkg|bluez-deprecated-tools}} をインストールしてください。詳しい情報は {{Bug|53110}} や [https://lore.kernel.org/linux-bluetooth/20170104133401.3636-1-luiz.dentz@gmail.com/ Bluez メーリングリスト] を参照。
* 2024年から、{{Pkg|bluez-obex}}と{{Pkg|bluez-mesh}}は{{Pkg|bluez}}から分離されました。よって、Bluetooth越しにファイルを転送したい場合は、{{Pkg|bluez-obex}}をインストールし、ユーザーサービス {{ic|obex.service}} を有効化する必要があります。}}

=== フロントエンド ===

==== コンソール ====

* {{App|bluetoothctl|シェルからデバイスをペアリングすることは、最も単純で信頼性の高いオプションの一つです。|http://www.bluez.org/|{{Pkg|bluez-utils}}}}
* {{App|bluetuith|ターミナルユーザインターフェイスによる Bluetooth マネージャを提供します。OBEX ファイル転送とマウスのサポート付きで、デバイス/アダプタを簡単に管理できます。|https://www.github.com/darkhz/bluetuith|{{AUR|bluetuith}}}}

{{Tip|bluetoothctl コマンドを自動化するには、{{ic|echo -e "''command1''\n''command2''\n" {{!}} bluetoothctl}} または {{ic|bluetoothctl -- ''command''}} を使用します。}}

==== グラフィカル ====

以下のパッケージでは、Bluetooth をカスタマイズするためのグラフィカルインターフェイスが利用可能です。

* {{App|GNOME Bluetooth|[[GNOME]] の Bluetooth ツール。
** {{Pkg|gnome-bluetooth-3.0}} バックエンドを提供 ({{Pkg|gnome-bluetooth}} はレガシーです)
** {{Pkg|gnome-shell}} ステータスモニターアプレットを提供
** {{Pkg|gnome-control-center}} は設定用のフロントエンド GUI を提供しており、アクティビティ概要で Bluetooth と入力するか、 {{ic|gnome-control-center bluetooth}} コマンドでアクセスすることができます。
** また、{{ic|bluetooth-sendto}} コマンドを直接起動して、リモートデバイスにファイルを送信することも可能です。
** {{AUR|nautilus-bluetooth}} は Nautilus の右クリックメニューに "Bluetoothで送信" エントリを追加します。
** ファイルを受信するには、Bluetooth 設定パネルを開きます。Bluetooth パネルが開いている間のみ受信できます。
** Thunar のファイルプロパティメニューの ''送信先'' メニューに Bluetooth エントリを追加するには、説明 [https://docs.xfce.org/xfce/thunar/send-to ここ] を参照してください。(設定が必要なコマンドは {{ic|bluetooth-sendto %F}} です)
|https://wiki.gnome.org/Projects/GnomeBluetooth|}}
* {{App|Bluedevil|[[KDE]] の Bluetooth ツール。 Dolphin やシステムトレイに Bluetooth のアイコンが表示されていない場合は、システムトレイオプションで有効にするか、ウィジェットを追加してください。アイコンをクリックすることで、Bluedevil の設定や Bluetooth デバイスの検出が可能です。KDE システム設定からもインターフェースが利用できます。|https://invent.kde.org/plasma/bluedevil|{{Pkg|bluedevil}}}}
* {{App|Blueberry|GNOME Bluetooth から Linux Mint でスピンオフした ''Blueberry'' は全てのデスクトップ環境で動作します。Obex Object Push によるファイル受信をサポートしていません。|https://github.com/linuxmint/blueberry|{{Pkg|blueberry}}}}
* {{App|[[Blueman]]|フル機能の Bluetooth マネージャー|https://github.com/blueman-project/blueman|{{Pkg|blueman}}}}
* {{App|[[ObexFTP]]|OBEX 対応のデバイスとの間でファイルを転送するツール。|http://dev.zuckschwerdt.org/openobex/wiki/ObexFtp|{{AUR|obexftp}}}}

== ペアリング ==

{{Note|Bluetooth デバイスを使用する前に、[[rfkill]] でブロックされていないことを確認してください。}}

このセクションでは、''bluetoothctl'' CLI を使って ''bluez5'' を直接設定する方法を説明しています。これは、代替のフロントエンドツール(例えば GNOME Bluetooth)を使用している場合は必要ないかもしれません。

正確な手順は、利用するデバイスとその入力機能によります。以下は {{ic|bluetoothctl}} を使ってデバイスをペアリングする一般的な説明です。

{{ic|bluetoothctl}} 対話コマンドを実行してください。{{ic|help}} と入力することで利用できるコマンドのリストを表示できます。

# (任意) {{ic|select ''MAC Address''}} と入力してデフォルトのコントローラを選択してください。
# (任意) デバイスがオフになっている場合、{{ic|power on}} と入力してコントローラへの電源供給をオンにしてください。デバイスはデフォルトでオンになっています ([[#アダプタのデフォルト電源状態]])。
# {{ic|devices}} と入力して、ペアリングしたいデバイスの MAC アドレスを取得してください。
# デバイスが表示されないときは {{ic|scan on}} コマンドでデバイス検出モードにしてください。
# {{ic|agent on}} でエージェントをオンにするか、特定のエージェントを選択してください: {{ic|agent}} の後にタブキーを2回押すと、利用可能なエージェントのリストが表示されるはずです。Bluetooth エージェントとは、Bluetooth の 'ペアリングコード' を管理するもののことです。エージェントは、'ペアリングコード'の受信に応答したり、'ペアリングコード'を送信したりできます。ほとんどの場合、{{ic|default-agent}} を使うのが適切なはずです。[https://askubuntu.com/questions/763939/bluetoothctl-what-is-a-bluetooth-agent]
# {{ic|pair ''MAC Address''}} と入力することでペアリングを実行します (タブ補完が使えます)。
# PIN がないデバイスを使う場合は、手動でデバイスを信頼する必要があるかもしれません。{{ic|trust ''MAC Address''}} と入力してこれを行なって下さい。デバイスを信頼するには {{ic|trust ''MAC_address''}} と入力してください。
# {{ic|connect ''MAC_address''}} を使って接続を確立してください。

セッションの例は以下のようになります:

{{hc|$ bluetoothctl|
[NEW] Controller 00:10:20:30:40:50 ''hostname'' [default]
[bluetooth]# agent KeyboardOnly
Agent registered

[bluetooth]# default-agent
Default agent request successful

[bluetooth]# power on
Changing power on succeeded
[CHG] Controller 00:10:20:30:40:50 Powered: yes

[bluetooth]# scan on
Discovery started
[CHG] Controller 00:10:20:30:40:50 Discovering: yes
[NEW] Device 00:12:34:56:78:90 ''device name''
[CHG] Device 00:12:34:56:78:90 LegacyPairing: yes

[bluetooth]# pair 00:12:34:56:78:90
Attempting to pair with 00:12:34:56:78:90
[CHG] Device 00:12:34:56:78:90 Connected: yes
[CHG] Device 00:12:34:56:78:90 Connected: no
[CHG] Device 00:12:34:56:78:90 Connected: yes
Request PIN code
[agent] Enter PIN code: 1234
[CHG] Device 00:12:34:56:78:90 Paired: yes
Pairing successful
[CHG] Device 00:12:34:56:78:90 Connected: no

[bluetooth]# connect 00:12:34:56:78:90
Attempting to connect to 00:12:34:56:78:90
[CHG] Device 00:12:34:56:78:90 Connected: yes
Connection successful
}}

=== デュアルブートペアリング ===

デュアルブート環境でデバイスをペアリングするには、Linux の方でペアリングキーを変更して Windows または macOS で使用されているペアリングキーと同じにする必要があります。

このページでは、これを手動で行う方法のみを説明しています。この手順を自動化するには、[https://github.com/x2es/bt-dualboot bt-dualboot プロジェクト]や関連するリポジトリを参照してください。

==== 設定方法 ====

これを行うには、まず Arch Linux 上でデバイスのペアリングを行います。その後、もう一方の OS を再起動し、デバイスをペアリングします。ここでペアリング・キーを取り出す必要がありますが、まず Bluetooth デバイスの電源を切り、接続を試みないようにします。

{{Note|([[Logitech MX Master]] や Logitech 604 Lightspeed などの) 一部の Logitech デバイスは、デバイスが新しいシステムとペアリングするたびに MAC アドレスの値を1つ増加させます。プロセスの最後にこれに対処するために、このケースに該当するかどうかを確認する必要があります。}}

==== Windows の場合 ====

===== Windows での展開 =====

まず、Windows を起動してください。

リンクキーを含むレジストリキーは、ログイン不可能な[https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts#system SYSTEM アカウント]でしかアクセスできません。そのため、{{ic|regedit.exe}} を {{ic|SYSTEM}} として実行するには、Windows Sysinternals 公式サイトにある Microsoft の [https://docs.microsoft.com/en-us/sysinternals/downloads/psexec PsExec] ツールが必要になります。

[https://download.sysinternals.com/files/PSTools.zip PsTools] をダウンロードし、{{ic|PsExec64.exe}} を解凍します。

[https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/windows-commands#command-shell-overview コマンドシェル] の管理者インスタンスで、解凍した EXE の場所からレジストリエディタを起動してください:

.\PsExec64.exe -s -i regedit.exe

レジストリエディタで、以下のレジストリキーに移動します:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys

このキーの中に各 Bluetooth アダプターの MAC アドレス別のキーがあります。複数のキーがあり、どれを使えばいいかわからない場合は、[https://www.addictivetips.com/windows-tips/find-bluetooth-mac-address-windows-10/ このガイド]に従って、目的の Bluetooth アダプタの MAC アドレスを検索してください。

目的のデバイスアダプタキーの中に、ペアリングされたデバイスのそれぞれに対してキーが、MAC アドレスと関連付けられて存在しています。

インストール間で共有したい各ペアデバイスについて、キー全体を右クリックし、''.reg'' ファイルとしてエクスポートしてください。これはテキストファイルで、このファイルからキーをコピーできます。

このファイルにバイナリキーが1つだけ存在する場合、Bluetooth 5.1 デバイスではなく、そのペアリングキーが必要なもの全てであるということになります。

ペアリングしたデバイスに複数のキー ({{ic|LTK}} や {{ic|IRK}} など) が存在する場合、これは Bluetooth 5.1 デバイスで''ある''ということになります。これらのキーを使う方法は [[#Bluetooth 5.1 キーの準備]] を見てください。

最後に、キーを Linux 環境にインポートするために、Linux を起動して [[#終わりに]] へ進んでください。

===== Linux での展開 =====

{{Note|Windows パーティションが Bitlocker で暗号化されている場合、Linux から chntpw を使ってアクセスすることはできません。}}

Arch をリブートしてください。{{Pkg|chntpw}} をインストールして、Windows システムドライブをマウントします。

$ cd ''/path/to/windows/system''/Windows/System32/config
$ chntpw -e SYSTEM
{{Note|CurrentControlSet の代わりに ControlSet00X（X は任意の数字）と表示されることがあります。ls コマンドで確認してください。}}
{{ic|chntpw}} 環境の中で以下を実行します。

> cd CurrentControlSet\Services\BTHPORT\Parameters\Keys
もしくは
> cd ControlSet00X\Services\BTHPORT\Parameters\Keys

次に、Bluetooth アダプタの MAC アドレスを取得し、そのフォルダを入力します。

> ls
> cd ''your-device's-mac-address''

ペアリングしているデバイスにも同じことをします。Bluetooth 5.1 デバイスで''ない''場合、ペアリングキーしか表示されません:

{{hc|> ls|
Node has 0 subkeys and 1 values
size type value name [value if type DWORD]
16 REG_BINARY <123456789876>
}}

Bluetooth 5.1 デバイスである場合、{{ic|hex}} を通して、デバイスのキーを取得します。

{{hc|> hex 123456789876|
:00000 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX (いくつかの他の文字)
}}

”XX" はペアリング・キーです。どのキーがどの MAC アドレスにマッピングされているか、メモしておいてください。

Bluetooth 5.1 デバイスで''ある''場合、1つのデバイスに対応するキーが複数表示されます。

{{bc|
Node has 0 subkeys and 8 values
size type value name [value if type DWORD]
16 3 REG_BINARY <LTK>
4 4 REG_DWORD <KeyLength> 16 [0x10]
8 b REG_QWORD <ERand>
4 4 REG_DWORD <EDIV> 37520 [0x9290]
16 3 REG_BINARY <IRK>
8 b REG_QWORD <Address>
4 4 REG_DWORD <AddressType> 1 [0x1]
4 4 REG_DWORD <AuthReq> 45 [0x2d]
}}

これらのキーを使う方法は [[#Bluetooth 5.1 キーの準備]] を見てください。必要な値を得るには {{ic|hex ''value_name''}} を使います。

最後に、キーを Linux 環境にインポートするために [[#終わりに]] へ進んでください。

==== macOS の場合 ====

macOS を起動し:

* macOS Monterey 及びそれ以降の場合:
*# Keychain Access を開き、Bluetooth と検索してください。
*# 日付順でソートしてください。
*# 対象のデバイスを最近取り除いて再接続した場合、キーを変更日時順でソートして、最新のものを選べばよいです。キーはおそらく MobileBluetooth (古い Bluetooth デバイスの場合) という名前か、UUID (Bluetooth 5.1 以降) だけです。
*# 対象のエントリをダブルクリックしてください。Account フィールドの MAC アドレスが対象デバイスの MAC アドレスと一致することを確認してください。
*# "Show password" チェックボックスをクリックしてください。ここで、パスワードを2回入力する必要があります。
*# パスワードフィールド内のテキストをコピーしてください ({{ic|⌘+a}} {{ic|⌘+c}})。これは実際には XML ファイルです。
#* テキストをホームディレクトリ内の {{ic|bt_keys.txt}} ファイルにペーストしてください。
* High Sierra 及びそれ以降の場合、次のコマンドをターミナルで実行してください: {{bc|# defaults read /private/var/root/Library/Preferences/com.apple.bluetoothd.plist LinkKeys > ~/bt_keys.txt}}
* Sierra 及びそれ以前の場合、次のコマンドをターミナルで実行してください: {{bc|# defaults read /private/var/root/Library/Preferences/blued.plist LinkKeys > ~/bt_keys.txt}}

すると、{{ic|~/.bt_keys.txt}} ファイルには、確立された Bluetooth キーが含まれています。古いバージョンの macOS (High Sierra 及びそれ以前) では、先に進む前にキーの並びを逆にする必要があります。例えば、{{ic|98 54 2f aa bb cc dd ee ff gg hh ii jj kk ll mm}} は {{ic|MM LL KK JJ GG FF EE DD CC BB AA 2F 54 98}} になります。

{{Note|キーの並びを逆にするには、以下の [[Python]] コードを使用できます:
{{bc|1=
>>> key = "98 54 2f aa bb cc dd ee ff gg hh ii jj kk ll mm"
>>> " ".join(reversed(key.strip().split()))
}}
}}

Bluetooth 5.1 デバイスの場合、1つのデバイスに対して複数のキーが関連付けられています。それらのキーを使用する方法については [[#Bluetooth 5.1 キーの準備]] を見てください。

最後に、キーを Linux 環境にインポートするために、Linux を起動し、[[#終わりに]] へ進んでください。

==== Bluetooth 5.1 キーの準備 ====

[[#Windows の場合]] や [[#macOS の場合]] の章に従っていて Bluetooth 5.1 キーが存在していた場合、それらのキーを Linux にインポートする前に特定の変換をかける必要があります。[[#終わりに]] の章で使うために、要求されたファイルを適切に作成してください。この手順は対象デバイスによって異なり、キーの一部を操作する必要があります。これを行うためのユーティリティは以下で挙げられています。

{| class="wikitable"
! デバイス !! 元のキー及び変換 (Windows) !! 元のキー及び変換 (macOS) || キーの保存先ファイル
|-
|rowspan="3"|
* Logitech MX Master 3
* Xbox One S Wireless Controller
|
* {{ic|IRK}} をコピー。
* 16進数の桁間のスペースを除去。
| {{Grey|?}}
| {{ic|IdentityResolvingKey.Key}}
|-
|
* {{ic|LTK}} をコピー。
* 16進数の桁間のスペースを除去。
| {{Grey|?}}
| {{ic|SlaveLongTermKey.Key}} と {{ic|PeripheralLongTermKey.Key}}
|-
|{{ic|ERand}} と {{ic|EDIV}} は {{ic|0}} にする必要あり。
|''Random Number'' と ''Encrypted Diversifier'' は {{ic|0}} にする必要あり。
| {{-}}
|-
|rowspan="4"|
* ThinkPad TrackPoint Keyboard II
* Pebble M350 マウス
* Logitech G604 Lightspeed マウス
|
* {{ic|IRK}} をコピー
* バイトの順番を逆に。
|
* ''Remote IRK'' をコピー。
* Base64 から16進数に変換。
| {{ic|IdentityResolvingKey.Key}}
|-
|
* {{ic|LTK}} をコピー。
* 16進数の桁間のスペースを除去。
|
* ''Remote Encryption'' を ''Long-term Key'' にコピー。
* Base64 から16進数に変換。
| {{ic|LongTermKey.Key}}
|-
|
* {{ic|ERand}} をコピー。
* バイトの順番を逆に。
* 数値全体を10進数に変換。
|
* ''Remote Encryption'' を ''Random Number'' にコピー
* Base64 をリトルエンディアンの10進数に変換 (以下の Python コードを参照)。
| {{ic|LongTermKey.Rand}}
|-
|
* {{ic|EDIV}} をコピー。
* バイトの順番を逆に。
* 数値全体を10進数に変換。
|
* ''Remote Encryption'' を ''Encrypted Diversifier'' にコピー。
* Base64 からリトルエンディアンの10進数に変換 (以下の Python コードを参照)。
| {{ic|LongTermKey.EDiv}}
|-
|rowspan="3"|他のデバイス
|
* {{ic|LTK}} をコピー。
* 16進数の桁間のスペースを除去。
|
* ''Remote IRK'' をコピー。
* Base64 から16進数に変換。
| {{ic|LongTermKey.Key}}
|-
|
* {{ic|ERand}} をコピー。
* バイトの順番を逆に。
* 数値全体を10進数に変換。
|
* ''Remote Encryption'' を ''Long-term Key'' にコピー。
* Base64 から16進数に変換。
| {{ic|LongTermKey.Rand}}
|-
|
* {{ic|EDIV}} をコピー。
* 16進数の桁間のスペースを除去。
|
* ''Remote Encryption'' を ''Encrypted Diversifier'' にコピー。
* Base64 から16進数に変換。
* バイトの順番を逆に。
| {{ic|LongTermKey.EDiv}}
|-
|rowspan="1"|Xbox ワイヤレスコントローラ
|
* {{ic|LTK}} をコピー。
* 16進数の桁間のスペースを除去。
| {{Grey|?}}
| {{ic|SlaveLongTermKey.Key}}
|}

{{Note|
* 値からスペースを取り除くには、[https://www.browserling.com/tools/remove-all-whitespace このオンラインツール]や以下の [[Python]] コードを使用できます:
>>> "''key_value''".replace(" ", "")
* 以下の Python コードはバイトの順番を逆にするだけです:
{{bc|1=
>>> ERand=" 63 02 84 B8 5D 40 44 DF "
>>> ERand=list(reversed(ERand.strip().split()))
}}
* 以下の Python コードは、一部で必要となる追加の10進数変換を行います:
{{bc|1=
>>> int("".join(ERand), 16)
16088054540146049635
}}
* 以下の Python コードは base64 から16進数への変換を行います:
binascii.hexlify(base64.decodebytes(b'...')).upper()
* 以下の Python コードは完全な macOS Encrypted Diversifier の変換を行います:
struct.unpack('<H', base64.decodebytes(b'...'))
* 以下の Python コードは完全な macOS Random Number の変換を行います:
struct.unpack('<Q', base64.decodebytes(b'...'))
}}

一般的なケースの例としては:
* {{ic|LTK}} の値 {{ic|48 4D AF CD 0F 92 22 88 0A 52 9A F4 76 DA 8B 94}} は、{{ic|LongTermKey.Key}} の値 {{ic|484DAFCD0F9222880A529AF476DA8B94}} となります。
* {{ic|ERand}} の値 {{ic|63 02 84 B8 5D 40 44 DF}} は、{{ic|Rand}} の値 {{ic|16088054540146049635}} となります。
* {{ic|EDIV}} の値 {{ic|37520}} は、{{ic|EDiv}} の値 {{ic|37520}} となります。

==== 設定の保存 ====

キーを手に入れたら、ユーザーを root に変更し、以下を実行してください:

{{bc|# cd /var/lib/bluetooth/''BT-Adapter-MAC-address''}}

ここには、ペアリングした Bluetooth 機器ごとのフォルダがあります。Arch とデュアルブートでペアリングしたい各デバイスについて、以下を実行します:

{{bc|# cd ''device-MAC-address''}}

{{Note|この時点で、ペアリング時に MAC アドレスの値を増加させるデバイスを使用している場合、MAC アドレスのディレクトリを、値を増加させたパスへ移動させる必要があります。Windows から MAC アドレスをコピーするか、あるいは、各オクテットが2桁の[[Wikipedia:Hexadecimal|16進数]]であることに注意しながら自分で値を増加させてください。}}

ペアリングキーを持っている場合 (つまり、これは Bluetooth 5.1 デバイスでない)、{{ic|info}} ファイルを編集し、{{ic|[LinkKey]}} 以下のキーを変更します。例えば:

{{hc|1=info|2=
[LinkKey]
Key=XXXXXXXXXXXXXXX
}}

{{Note|すべての文字が大文字であることを確認する必要があります。スペースはすべて削除してください。}}

複数のキーが存在する場合 (Bluetooth 5.1 の場合)、以下の {{ic|info}} ファイルを編集して、全てのキーをそれぞれの値で置き換えてください。例えば、Xbox One S Wireless Controller の場合:

{{hc|1=info|2=
[IdentityResolvingKey]
Key=<IdentityResolvingKey.Key>

[PeripheralLongTermKey]
Key=<PeripheralLongTermKey.Key>

[SlaveLongTermKey]
Key=<SlaveLongTermKey.Key>
}}

次に、{{ic|bluetooth.service}} と {{ic|pulseaudio}} を[[再起動]]してください。({{ic|pulseaudio -k && pulseaudio --start}} を使ってください。)

これで、デバイスに接続できるはずです。

{{Note|Bluetooth マネージャによっては、デバイスに再接続するために完全な再起動が必要な場合があります。}}

== 設定 ==

=== アダプタのデフォルト電源状態 ===

{{Pkg|bluez}} 5.65 以降、BlueZ はデフォルトで、サービスの起動時やサスペンドからの復帰時にすべての Bluetooth アダプタをオンにします。[https://github.com/bluez/bluez/commit/180cf09933b2d8eb03972c8638063429fe5fece5]

アダプタを自動で有効化させたくない場合(例えば、ポータブルデバイスなどでバッテリを節約したい場合)、{{ic|/etc/bluetooth/main.conf}} の {{ic|[Policy]}} セクションで {{ic|1=AutoEnable=false}} を設定してください:

{{hc|1=/etc/bluetooth/main.conf|2=
[Policy]
AutoEnable=false
}}

この設定を行っても、[[#ペアリング]] で説明されているように {{ic|power on}} を実行すれば、アダプタを手動でオンにできます。

=== 起動時に発見可能にする ===

デバイスが常に見えていて、かつ直接接続できる必要がある場合:

{{hc|1=/etc/bluetooth/main.conf|2=
[General]
DiscoverableTimeout = 0
}}

=== サスペンドからの復帰 ===

Bluetooth キーボードやマウスなどをサスペンドから起動できるようにする。まず、bios の設定を確認し、サスペンドからの復帰が無効になっていないことを確認します。多くの場合、マザーボードからの Bluetooth は USB デバイスです。

bluetooth アダプターのベンダーコードとデバイス ID を確認してください:

{{hc|$ lsusb {{!}} grep bluetooth -i|
Bus 001 Device 002: ID 8087:0039 Intel Corp. AX200 Bluetooth
}}

サスペンドからの復帰を有効にするために、ベンダコードとデバイス ID の新しい udev ルールを追加してください:

{{hc|/etc/udev/rules.d/91-keyboard-mouse-wakeup.rules|2=
SUBSYSTEM=="usb", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="0039" RUN+="/bin/sh -c 'echo enabled > /sys$env{DEVPATH}/../power/wakeup;'"
}}

復帰後に Bluetooth キーボードを自動的に再設定して、例えば異なるキーマップやキーのリピート速度をもたせたりする(詳細は [[Xorg でのキーボード設定#typematic delay と rate の調整]] と [[xmodmap]])には、[[実行可能属性|実行可能]]なスクリプトを作成してください。

{{hc|configure_keyboard.sh|2=
#!/bin/sh
export DISPLAY=:0
xset r rate 220 30
xmodmap /''your''/''path''/''to''/.Xmodmap
}}

そして、上記のような追加の udev ルールを作成してください。

{{hc|/etc/udev/rules.d/92-keyboard-reconfiguration-wakeup.rules|2=
SUBSYSTEM=="usb", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="0039" RUN+="/''your''/''path''/''to''/configure_keyboard.sh"
}}

=== 実験的な機能を有効化する ===

Bluez スタックは、バグがあるかもしれない新しい機能を D-Bus 実験的オプションおよびカーネル実験的オプションに留めます。実験的な機能は最終的に、安定していると判断され、もはやオプションを必要としなくなるので、どのような実験的な機能が存在するかはバージョンによって異なります (例えば、現在 D-Bus の実験的なインターフェイスを有効化すると、古いヘッドセットのバッテリーレベルを報告できるようになります)。実験的な機能を有効化するには、設定の対応する行をアンコメントしてください:

{{hc|/etc/bluetooth/main.conf|2=
...

# Enables D-Bus experimental interfaces
# Possible values: true or false
'''#Experimental = true'''

# Enables kernel experimental features, alternatively a list of UUIDs
# can be given.
# Possible values: true,false,<UUID List>
# Possible UUIDS:
...
# Defaults to false.
'''#KernelExperimental = true'''
}}

あるいは、{{ic|bluetooth.service}} を[[編集]]して、{{ic|--experimental}} フラグあるいは {{ic|--kernel}} フラグを追加してください。例えば、以下の[[ドロップインファイル]]のように:

{{hc|/etc/systemd/system/bluetooth.service.d/override.conf|2=
[Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/bluetoothd --experimental
}}

いずれの場合でも、{{ic|bluetooth.service}} を[[再起動]]する必要があります。

== オーディオ ==

通常は、オーディオサーバーと Bluetooth を統合するために追加の手順を実行する必要があります。これについては、以下のセクションで説明します。

Bluetooth オーディオや Bluetooth ヘッドセットなどの情報については [[Bluetooth ヘッドセット]] のページを見てください。

=== PulseAudio ===

Bluetooth ヘッドフォンやスピーカーのようなオーディオ機器を使うには {{Pkg|pulseaudio-bluetooth}} パッケージのインストールが必要です。インストールを反映させるために、pulseaudio を再起動してください: {{ic|pulseaudio -k}}。デフォルトの Pulseaudio インストールでは (具体的には、パッケージングされているデフォルトの {{ic|default.pa}} でユーザインスタンスを使用している場合)、即座に Bluetooth デバイスからスピーカーにオーディオをストリーミングできるはずです。[https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/stable-16.x/src/daemon/default.pa.in#L84-93]

システム全体の PulseAudio 設定がある場合は、デーモンを実行しているユーザー（通常は {{ic|pulse}}) が {{ic|lp}} グループに属しており、PulseAudio 設定に Bluetooth モジュールをロードしていることを確認します:

{{hc|/etc/pulse/system.pa|2=
...
load-module module-bluetooth-policy
load-module module-bluetooth-discover
...
}}

これは任意ですが、Bluetooth デバイスの接続時にすべてのオーディオをそのデバイスに自動で切り替えたい場合、{{ic|load-module module-switch-on-connect}} を追加してください。

=== PipeWire ===

v0.3.19 以降の PipeWire はデフォルトで Bluetooth をサポートしています。

=== ALSA ===

{{Note|Bluez5 は [[ALSA]] の直接統合を中止し、 [[PulseAudio]] のみをサポートします。 PulseAudio を使用できない場合、または使用しない場合は、次の手順に従ってください。}}

まず、 Bluetooth オーディオデバイスが正しくペアリングされ、システムに接続されていることを確認します。

次に、 {{AUR|bluez-alsa-git}} をインストールし、 {{ic|bluealsa}} サービスを開始(そして、有効に) し、ユーザーを {{ic|audio}} グループに追加します。

次のコマンドを実行して、すべてが意図したとおりに動作しているかどうかを確認します({{ic|''XX:XX:XX:XX:XX:XX''}} と {{ic|''FILE.wav''}} の部分は置き換えてください):

$ aplay -D bluealsa:SRV=org.bluealsa,DEV=''XX:XX:XX:XX:XX:XX'',PROFILE=a2dp ''FILE.wav''

最後に、 {{ic|~/.asoundrc}} に次の行を追加します。

{{hc|~/.asoundrc|
defaults.bluealsa {
service "org.bluealsa"
device "XX:XX:XX:XX:XX:XX"
profile "a2dp"
}
}}

これで、 {{ic|bluealsa}} デバイスを使って Bluetooth オーディオデバイスに接続できるようになります。ボリューム管理は {{ic|alsamixer}} とオプション {{ic|-D bluealsa}} を使って通常行われます。

== Bluetooth シリアル ==

Bluetooth-to-Serial modules (HC-05、HC-06) で Bluetooth シリアル通信が機能するようにするには、次の手順に従います:

[[#ペアリング|上記]]で説明したように、 {{ic|bluetoothctl}} を使って Bluetooth デバイスを'''ペアリング'''します。

{{Pkg|bluez-deprecated-tools}} をインストールします。新しいツールにはない機能があります。

ペアになっているデバイスの MAC アドレスを tty 端末にバインドします:

# rfcomm bind rfcomm0 ''MAC_address_of_Bluetooth_device''

これで、シリアル通信用に {{ic|/dev/rfcomm0}} を開くことができます:

$ picocom /dev/rfcomm0 -b 115200

== トラブルシューティング ==

{{Out of date|Replace hciconfig with newer commands.}}

=== 一般的なトラブルシューティング ===

==== デバッグ ====

デバッグするには、最初に {{ic|bluetooth.service}} を[[停止]]します。

そして {{ic|-d}} パラメーターを付けて開始します。

# /usr/lib/bluetooth/bluetoothd -n -d

別のオプションとして、 {{ic|btmon}} ツールが有ります。

==== 非推奨の BlueZ ツール ====

8つの BlueZ ツールは[https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=b1eb2c4cd057624312e0412f6c4be000f7fc3617 非推奨となり]、{{Pkg|bluez-utils}} から削除されましたが、それらのすべてが新しいツールに取って代わられたわけではありません。{{Pkg|bluez-deprecated-tools}} パッケージが非推奨となったツールを提供します。

{| class="wikitable"
|-
! 非推奨のツール
! あり得る代替
|-
| [https://manpages.debian.org/latest/bluez/gatttool.1.en.html gatttool] || btgatt-client, [https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/gatt-api.txt D-Bus Gatt API]{{Dead link|2023|10|29|status=404}}
|-
| [https://manpages.debian.org/latest/bluez/hciattach.1.en.html hciattach] || btattach
|-
| [https://manpages.debian.org/latest/bluez/hciconfig.1.en.html hciconfig] || btmgmt (そして bluetoothctl?)
|-
| [https://manpages.debian.org/latest/bluez-hcidump/hcidump.1.en.html hcidump] || btmon (そして btsnoop)
|-
| [https://manpages.debian.org/latest/bluez/hcitool.1.en.html hcitool] || なし、[https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/device-api.txt D-Bus Device API]{{Dead link|2023|10|29|status=404}} が利用可能
|-
| [https://manpages.debian.org/latest/bluez/rfcomm.1.en.html rfcomm]
| rowspan="2" | なし、[https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/profile-api.txt D-Bus Profile1 API]{{Dead link|2023|10|29|status=404}} の実装?
|-
| [https://manpages.debian.org/latest/bluez/ciptool.1.en.html ciptool]
|-
|[https://manpages.debian.org/latest/bluez/sdptool.1.en.html sdptool]
| なし、機能が、異なる D-Bus オブジェクトに散らばっている模様: [https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/profile-api.txt Profile]{{Dead link|2023|10|29|status=404}}、[https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/advertising-api.txt Advertising]{{Dead link|2023|10|29|status=404}}、そして [https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/device-api.txt device]{{Dead link|2023|10|29|status=404}} と [https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/adapter-api.txt adapter]{{Dead link|2023|10|29|status=404}} の UUID の配列。
|}

=== サービスの問題 ===

==== systemd: Condition check resulted in Bluetooth service being skipped ====

{{ic|bluetooth.service}} は {{ic|/sys/class/bluetooth}} ディレクトリが存在することのみを要求します。このディレクトリは {{ic|bluetooth}} カーネルモジュールによって作成されるはずです。このカーネルモジュールは、{{ic|systemd-udev}} が動作している Bluetooth ハードウェアデバイスを発見した場合にのみ、{{ic|systemd-udev}} により自動的にロードされます。

{{ic|/sys/class/bluetooth}} が存在しない場合、{{ic|lsmod}} コマンドを使って、Bluetooth カーネルモジュールがロードされているかどうかを確認してください。Bluetooth デバイスがあるにも関わらずロードされていない場合、[[カーネルモジュール#手動でモジュールを扱う|Bluetooth モジュールをロード]]し、{{ic|bluetooth.service}} を[[再起動]]することで、手動で起動できます。

また、{{ic|bluetooth}} モジュールをロードする際に、対応するカーネル Bluetooth ドライバもロードする必要があります。{{ic|btusb}} が最も可能性がありますが、{{ic|btrtl,btintel,btbcm,bnep,btusb}} などの可能性もあります。

{{ic|bluetooth.service}} の[[ユニットステータス]]を確認して、このサービスが起動しているかどうかを確認してください。

[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853207 Debian Bug report logs - #853207] も参照してください。

{{ic|bluetooth.service}} の起動に成功したが、まだ Bluetooth を使えないことがあります (例: {{ic|scan on}} の時に {{ic|bluetoothctl}} が {{ic|org.Bluez.Error.NotReady}} のようなメッセージを発する)。この場合、コンピュータを再起動し、次のことをダブルチェックしてください: {{ic|/sys/class/bluetooth}} ディレクトリが存在するか; {{ic|lsmod}} の出力に正しい Bluetooth モジュールが含まれているか; [[journal]] のログを確認するなど。{{ic|systemd-udev}} は、また手動の変更をせずとも Bluetooth ハードウェアを自動的に認識するはずです。

==== Bluetooth が suspend-to-idle 中のデバイスを即座に立ち上げてしまう ====

[[サスペンドとハイバネート|suspend-to-idle/S2idle/S0ix/Modern Standby]] する能力のあるシステムにおいては、Bluetooth コントローラがスリープ中も有効化されたままになります。通常、これにより、Bluetooth デバイスが接続されていると、システムが[https://bugzilla.kernel.org/show_bug.cgi?id=200039 スリープに移行した直後にスリープが解除されてしまいます]。

これを防ぐには、スリープに移行する前に Bluetooth を完全に無効化できます。{{Pkg|bluez-utils}} をインストールし、以下のファイルを作成してください:

{{hc|/etc/systemd/system/bluetooth-disable-before-sleep.service|2=
[Unit]
Description=Disable Bluetooth before going to sleep
Before=sleep.target
Before=suspend.target
Before=hybrid-sleep.target
Before=suspend-then-hibernate.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStart=/usr/bin/bluetoothctl power off
ExecStop=/usr/bin/bluetoothctl power on

[Install]
WantedBy=sleep.target
WantedBy=suspend.target
WantedBy=hybrid-sleep.target
WantedBy=suspend-then-hibernate.target
}}

このサービスを[[有効化]]し、スリープに移行した時に Bluetooth デバイスが切断されることや、スリープからの復帰時に Bluetooth が再び接続されることを確認してください。

この回避策を使用すると、[[#サスペンドからの復帰|Bluetooth マウス/キーボードを使ってシステムをスリープから復帰させること]]ができなくなります。

==== ヘッドレス/サーバのシステムでログアウト後に Bluetooth がオフになる ====

様々な原因が考えられます:

* [[PulseAudio]] と [[PipeWire]] は両方ともデフォルトでユーザサービスとして動作します。よって、最後のセッションが終了するとこれらのサービスは終了されます。この問題を解決するには、対象のユーザに対して [[systemd/ユーザー#systemd のユーザーインスタンスを自動起動|Lingering (残留)]] を有効化してください。
* さらに、[[WirePlumber]] を [[PipeWire]] と共に実行している場合 (これはよくある環境です)、WirePlumber は "logind-monitor" を実行します。これは、Bluetooth をログイン時に有効化し、ログアウト時に無効化します。問題の解決方法は [[WirePlumber#ログアウト後も Bluetooth を実行し続ける/ヘッドレス Bluetooth]] を見てください。

=== アダプタの問題 ===

==== hcitool scan: Device not found ====

* 一部のラップトップ (例: Dell Studio 15、Lenovo Thinkpad X1) では、Bluetooth モードを HID から HCI に切り替える必要があります。{{Pkg|bluez-hid2hci}} パッケージをインストールすれば、[[udev]] が自動的に切り替えを行うはずです。また、次のコマンドを実行して手動で HCI に切り替えることもできます:

# /usr/lib/udev/hid2hci

* デバイスが表示されず、かつマシンに Windows オペレーティングシステムがある場合、Windows から bluetooth アダプターを有効にして見てください。

* 場合によっては次のコマンドで問題が解決するかもしれません:

# bluetoothctl power on

==== bluetoothctl: No default controller available ====

一部のマザーボード Bluetooth コントローラにはバグがあります。バグがこの問題の原因であるか調べるには、{{ic|journalctl {{!}} grep hci}} を実行してください。このコマンドの出力に "command tx timeout" や "Reading Intel version command failed" のようなエントリが存在する場合、PC の電源を切り、電源ケーブルを物理的に外して数秒間放置してください。これにより、コントローラにファームウェアを再ロードさせます (通常の再起動では再ロードしません)。[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1859592 こちら]のバグレポートを参照してください。

デバイスが [[rfkill]] によってブロックされていないことを確認してください。

また、一部の Intel カード (8260 など) は Bluetooth サービスによって正しく認識されないかもしれません。{{Pkg|bluez-utils}} の代わりに非推奨の {{Pkg|bluez-deprecated-tools}} を使うことでこの問題が解決したというケースが報告されています。

また、これは省電力機能が原因かもしれません。その場合、{{ic|1=btusb.enable_autosuspend=n}} [[カーネルパラメータ#設定|カーネルパラメータ]]により解決できる可能性があります。[https://bugzilla.redhat.com/show_bug.cgi?id=1573562 Red Hat Bugzilla – Bug 1573562] も参照してください。

時々、{{ic|btusb}} をオプション無しでアンロード・ロードすればコントローラを元に戻せることがあります:

# modprobe -r btusb
# modprobe btusb

また、ドングルが [[#CSR ドングル 0a12:0001|CSR クローン]]である場合にもこの問題が発生することがあります。

==== rfkill unblock: Do not unblock ====

デバイスがソフトブロックされていて [[ConnMan]] を動作させている場合、次を試してみて下さい:

$ connmanctl enable bluetooth

==== Bluetooth USB ドングル ====

USB ドングルを使う場合は、Bluetooth ドングルが認識されているか確認してください。USB ドングルを挿入する時に {{ic|journalctl -f}} を root として実行する(もしくは {{ic|/var/log/messages.log}} を調査する)ことで、そのことを確認できます。以下のような見た目であるはずです(hci を見てください)。

{{bc|
Feb 20 15:00:24 hostname kernel: [ 2661.349823] usb 4-1: new full-speed USB device number 3 using uhci_hcd
Feb 20 15:00:24 hostname bluetoothd[4568]: HCI dev 0 registered
Feb 20 15:00:24 hostname bluetoothd[4568]: Listening for HCI events on hci0
Feb 20 15:00:25 hostname bluetoothd[4568]: HCI dev 0 up
Feb 20 15:00:25 hostname bluetoothd[4568]: Adapter /org/bluez/4568/hci0 has been enabled
}}

最初の2行しか表示されていなかった場合、デバイスは見つかっていますが、そのデバイスを立ち上げる必要があります。
例:

{{hc|# btmgmt|
[mgmt]# info
Index list with 1 item
hci0: Primary controller
addr 00:1A:7D:DA:71:10 version 6 manufacturer 10 class 0x000000
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr
'''current settings:''' connectable discoverable bondable ssp br/edr le secure-conn
name Mozart
short name

[mgmt]# select hci0
Selected index 0

[hci0]# power up
hci0 Set Powered complete, settings: '''powered''' connectable discoverable bondable ssp br/edr le secure-conn

[hci0]# info
hci0: Primary controller
addr 00:1A:7D:DA:71:10 version 6 manufacturer 10 class 0x1c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr
'''current settings: powered''' connectable discoverable bondable ssp br/edr le secure-conn
}}

または

{{hc|# bluetoothctl|
[bluetooth]# show
Controller 00:1A:7D:DA:71:10 (public)
Name: Mozart
Alias: Mozart
Class: 0x0000095c
'''Powered: no'''
Discoverable: yes
Pairable: yes

[bluetooth]# power on
[CHG] Controller 00:1A:7D:DA:71:10 Class: 0x001c0104
Changing power on succeeded
[CHG] Controller 00:1A:7D:DA:71:10 '''Powered: yes'''

[bluetooth]# show
Controller 00:1A:7D:DA:71:10 (public)
Name: Mozart
Alias: Mozart
Class: 0x001c0104
'''Powered: yes'''
Discoverable: yes
Pairable: yes
}}

[https://www.bluetooth.com/specifications/assigned-numbers/host-controller-interface/ 公式の仕様表]に従って、Bluetooth のバージョンが HCI のバージョンにマップされていることを確認できます。例えば、先の出力では、HCI '''version 6''' が Bluetooth version 4.0 です。

デバイスが検出されているか確認するために {{ic|bluez-utils}} に含まれている {{ic|hcitool}} を使うことができます。次のコマンドで利用可能なデバイスとその識別子・MAC アドレスのリストを表示することが可能です:

{{hc|$ btmgmt info|
Index list with 1 item
hci0: Primary controller
addr 00:1A:7D:DA:71:10 '''version 6''' manufacturer 10 class 0x1c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr
current settings: powered connectable discoverable bondable ssp br/edr le secure-conn
}}

デバイスに関するもっと詳細な情報は、非推奨の {{ic|hciconfig}} を使うことで取得できます。({{AUR|bluez-utils-compat}})

{{hc|$ hciconfig -a hci0|
hci0: Type: USB
BD Address: 00:1B:DC:0F:DB:40 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:1226 acl:0 sco:0 events:27 errors:0
TX bytes:351 acl:0 sco:0 commands:26 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'BlueZ (0)'
Class: 0x000100
Service Classes: Unspecified
Device Class: Computer, Uncategorized
HCI Ver: 2.0 (0x3) HCI Rev: 0xc5c LMP Ver: 2.0 (0x3) LMP Subver: 0xc5c
Manufacturer: Cambridge Silicon Radio (10)
}}

===== ドングルから短距離にいるときにオーディオデバイスがおかしくなる =====

他のデバイスと同一の USB ホストを共有している場合、[https://bbs.archlinux.org/viewtopic.php?pid=1440161#p1440161 オーディオデバイスとの通信に干渉] する可能性があります。オーディオデバイスがバスに接続されている唯一のデバイスであることを確認してください。例:

{{hc|$ lsusb|
Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 048d:1345 Integrated Technology Express, Inc. Multi Cardreader
Bus 001 Device 003: ID 0424:a700 Standard Microsystems Corp. 2 Port Hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
}}

===== CSR ドングル 0a12:0001 =====

デバイス {{ic|ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)}} にはリグレッションのバグがあり、現在、カーネルバージョン 5.17 及び < 6.0 でしか動作しません。詳細は、[https://bugzilla.kernel.org/show_bug.cgi?id=60824 Kernel Bug 60824] を参照してください。

==== Logitech Bluetooth USB ドングル ====

Logitech のドングルには Embedded と HCI という二つのモードで動作するものがあります (例: Logitech MX5000)。embedded モードではドングルは USB デバイスをエミュレートするので PC は普通の USB マウス・キーボードを使っていると認識します。

USB BT ミニレシーバの小さな赤いボタンを押すと他のモードが有効になります。BT ドングルの赤いボタンを押しながらコンピュータに接続してください。ボタンを押して3-5秒で、Bluetooth アイコンがシステムトレイに表示されます ([https://ubuntuforums.org/showthread.php?t=1332197 議論])。

また、{{Pkg|bluez-hid2hci}} パッケージをインストールすることもできます。Logitech のドングルを接続すると自動的に切り替えます。

==== Foxconn / Hon Hai / Lite-On の Broadcom デバイス ====

一部のデバイスでは、起動時にファームウェアを書き込む必要があります。

一部のファームウェアは、[[AUR]] で [https://aur.archlinux.org/packages?K=broadcom broadcom] と検索すると入手できます。特出すべきパッケージは {{AUR|broadcom-bt-firmware}} です。これは、[https://github.com/winterheart/broadcom-bt-firmware/blob/master/DEVICES.md 様々なカード]用のファイルを提供します。

または、[https://github.com/jessesung/hex2hcd hex2hcd] ({{Pkg|bluez-utils}} でインストールされます) を使ってファームウェアを Microsoft Windows の ''.hex'' ファイルから ''.hcd'' ファイルに変換することもできます。

正しい ''.hex'' ファイルを取得するために、''lsusb'' でデバイスの vendor:product コードを検索してください。例:

Bus 002 Device 004: ID '''04ca:2006''' Lite-On Technology Corp. Broadcom BCM43142A0 Bluetooth Device

または:

Bus 004 Device 004: Id '''0489:e031''' Foxconn / Hon Hai

もしくは、Windows (仮想マシンでもかまいません) を起動して Device Manager ユーティリティからファームウェアの名前を取得してください。デバイスのモデルを知りたいのに ''lsusb'' で表示されない場合、''lsusb -v'' の {{ic|iProduct}} でわかることがあります。

''.hex'' ファイルはダウンロードした Windows ドライバーから抽出することができます。Windows を実行する必要はありません。適切なドライバーをダウンロードしてください (例えば、[http://www.fujitsupc.com/downloads/mobile/BLUETOOTH_WIDCOMM_V6.5.0.3100_WIN7-32_FPC46-1771-01.EXE Bluetooth Widcomm]{{Dead link|2023|09|16|status=domain name not resolved}})。フォーマットにも依りますが、ファイルの展開には{{Pkg|unrar}} か {{Pkg|cabextract}} が必要である場合があります。多数の ''.hex'' ファイルの中から必要なファイルを見つけるには、{{ic|Win32/bcbtums-win7x86-brcm.inf}} ファイルの中身を確認して {{ic|[RAMUSB'''E031'''.CopyList]}} を検索してください。{{ic|E031}} はあなたの使っているデバイスの product コード (大文字) に置き換えて下さい (''lsusb'' で確認できる2番目の16進数)。その下に、必要な ''.hex'' ファイルの名前が書かれているはずです。

''.hcd'' ファイルを手に入れたら、{{ic|/lib/firmware/brcm/BCM.hcd}} にコピーしてください - このファイル名は [[dmesg]] からわかります。あなたのマシンでは異なっている可能性があるため ''dmesg'' の出力で確認してください。そして ''btusb'' モジュールをリロードしてください:

# rmmod btusb
# modprobe btusb

これでデバイスが使えるようになるはずです。以上の設定を永続化させる方法は [https://bbs.archlinux.org/viewtopic.php?id=162688 BBS#162688] を参照。

==== Intel の複合 WiFi と Bluetooth カード ====

[[ネットワーク設定/ワイヤレス#Bluetooth の共存]] を見てください。

==== Windows とのデュアルブート環境における Mediatek MT7921 や MT7961 ====

デュアルブートシステムでは、Bluetooth のファームウェアバージョンが Windows と Linux とで異なる場合、Windows を起動した後に Bluetooth アダプタが動作しなくなります。

これを防ぐ最も良い方法は、各 OS 用の Bluetooth ドライバ (特にファームウェア) を最新にすることです。

Windows 用の最新バージョンのドライバ (またはファームウェア) を見つけられない場合、最新のファームウェアファイル {{ic|/usr/lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin.xz}} を Arch Linux からコピーし、Windows へ展開することができます (例えば、{{ic|C:\WINDOWS\system32\DRIVERS\}}。Windows でのファームウェアファイルへのパスはデバイスマネージャから確認できます)。

==== サスペンド/復帰後にアダプタが消える ====

まず、アダプタのベンダーと製品 ID を見つけてください。例:

First, find vendor and product ID of the adapter. For example:

{{hc|$ lsusb -tv|<nowiki>
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
...
|__ Port 3: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
ID 8087:0025 Intel Corp.
|__ Port 3: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
ID 8087:0025 Intel Corp.
...
</nowiki>}}

この場合、ベンダー ID は 8087 で、製品 ID は 0025 です。

次に、 {{pkg|usb_modeswitch}} を使用してアダプタをリセットします:

# usb_modeswitch -R -v ''vendor_ID'' -p ''product_ID''

=== ペアリングと接続の問題 ===

==== コンピュータが表示されない ====

携帯からコンピュータが表示されないときは、discoverable モードを有効にしてください:

# bluetoothctl discoverable on

discoverable モードがオンになっていることを確認してください:

{{hc|# bluetoothctl show|
Powered: yes
Discoverable: yes
Pairable: yes
}}

{{Note|{{ic|/etc/bluetooth/main.conf}} の {{ic|PairableTimeout}} と {{ic|DiscoverableTimeout}} を確認してください。}}

まだコンピュータが表示されない場合、以下のように {{ic|/etc/bluetooth/main.conf}} 内のデバイスクラスを変更してみて下さい:

# Default device class. Only the major and minor device class bits are
# considered.
#Class = 0x000100 # Computer Type (from default config)
Class = 0x100100 # (Object-Transfer Service & Computer Type)

{{Note|場合によっては、{{ic|main.conf}} 内の {{ic|Class}} はデバイスの初期化後に上書きされます。なので、{{ic|hciconfig hci0 class 100100}} のようにクラスを直接設定してください。}}

あるユーザは、携帯からコンピュータを見られるようにするためにはこうするしか無いと報告しています。LG TV(そして、一部の他の機器)はオーディオデバイスから発見可能です。なので、{{ic|000414}} (soundbar クラス)を使用することでそのようなデバイスを発見できるようにできます。

Bluetooth デバイス/サービスのクラスを生成するには https://bluetooth-pentest.narod.ru/software/bluetooth_class_of_device-service_generator.html を見てください。

==== デバイスを接続した数秒後に切断してしまう ====

デバイスを接続したすぐ後に切断が発生し、ジャーナルの出力に以下のようなメッセージが確認できる場合:

bluetoothd: Unable to get connect data for Headset Voice gateway: getpeername: Transport endpoint is not connected (107)
bluetoothd: connect error: Connection refused (111)

おそらく別のオペレーティングシステムで同一の Bluetooth アダプタを使ってデバイスがペアリングされていることが原因です (例: デュアルブート)。一部のデバイスは同一の MAC アドレス (例: Bluetooth アダプタ) に対して複数のペアリングを関連付けた場合に対処できません。この問題を解決するには [[#デュアルブートペアリング]] の指示に従ってください。

==== スキャンしてもデバイスが表示されない ====

Bluetooth Low Energy を使用しているデバイスは bluetoothctl でスキャンしても表示されないことがあります (例: [[Logitech MX Master]])。{{ic|transport le}} を使ってスキャンすることができます。

{{hc|# bluetoothctl|
[bluetooth]# menu scan
[bluetooth]# transport le
[bluetooth]# back
[bluetooth]# scan on
[bluetooth]# devices
...
Device XX:XX:XX:XX:XX:XX DA V2 X <---- 低消費電力なデバイス
}}

もう一つの方法は、{{aur|bluez-utils-compat}} をインストールし、{{ic|bluetooth.service}} を[[開始]]し、以下を実行することです:

{{hc|# bluetoothctl|
[NEW] Controller (MAC) myhostname [default]

[bluetooth]# power on
[CHG] Controller (MAC) Class: 0x0c010c
Changing power on succeeded
[CHG] Controller (MAC) Powered: yes

[bluetooth]# scan on
Discovery started
[CHG] Controller (MAC) Discovering: yes
}}

他のターミナルで:

# hcitool lescan

デバイスが表示されるまで待機してから hcitool を {{ic|Ctrl+c}} で閉じてください。bluetoothctl からデバイスが認識されたら通常通りにペアリングできます。

==== Intel Corp. AX200 Bluetooth で BLE デバイスが見つからない ====

どうやら、このデバイスでは BLE のパッシブスキャンが壊れているようです。詳細は[https://community.intel.com/t5/Wireless/AX200-Passive-BLE-scan-linux/m-p/1227456 上流のバグレポート]を見てください。

==== スリープ後に再接続できない ====

スリープ後や、コンピュータがスリープから復帰した後に、デバイスが自動的に再接続されないことがあります。

この時、ログに以下のエラーが記録されます:

{{bc|
bluetoothd[487]: Authentication attempt without agent
bluetoothd[487]: Access denied: org.bluez.Error.Rejected
}}

これは、デバイスが ''trusted'' としてマークされていないことが原因です。[[#ペアリング]] を参照してください。

=== デバイス固有の問題 ===

==== Bluetooth マウスのラグ / 接続断 / 応答なし ====

[[Bluetooth マウス#トラブルシューティング]] を参照してください。

==== オーディオデバイスが br-connection-profile-unavailable で接続に失敗する ====

PipeWire (pulseaudio-bluetooth ではない) が使用されているが、PipeWire のインスタンスが実行されていない場合、bluetooth オーディオデバイスは接続に失敗します。PipeWire デーモンを開始するには、{{ic|pipewire.service}} [[ユーザーユニット]]を[[開始]]するか、何らかの音声を再生してください。その後、オーディオデバイスをもう一度接続してみてください。

==== ヘッドホンとマウスの干渉 ====

Bluetooth マウスとキーボードを同時に使用しているときに音声が途切れる場合は #23 https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/424215 で参照されているように、次を試してくみてださい:

# hciconfig hci0 lm ACCEPT,MASTER
# hciconfig hci0 lp HOLD,SNIFF,PARK

==== TP-LINK UB400 と Xbox のコントローラが接続/切断を繰り返す ====

以下の設定を使用してください:

{{hc|/etc/bluetooth/main.conf|2=
...
[General]
JustWorksRepairing = always
FastConnectable = true
Class = 0x000100
...
[GATT]
ReconnectIntervals=1,1,2,3,5,8,13,21,34,55
AutoEnable=true
...
}}

そして、{{ic|bluetooth.service}} を[[再起動]]してください。

関連する [https://github.com/atar-axis/xpadneo/issues/166 xpadneo に関する議論]を見ることができますが、xpadneo のドライバは必要ありません。

=== ファイル転送の問題 ===

==== gnome-bluetooth ====

bluetooth-properties でファイルの受信を有効にしようとしたときに以下のメッセージが表示される場合:

Bluetooth OBEX start failed: Invalid path
Bluetooth FTP start failed: Invalid path

[[XDG ユーザーディレクトリ]]が存在することを確認してください。

==== シンボリックリンクのせいで、転送されたファイルを受信できない ====

有効な Bluetooth 接続でファイルの受信に失敗する場合、問題はファイルの転送パス内のシンボリックリンクである場合があります。ジャーナルに以下のようなログが現れます:

Jun 18 11:18:13 ember obexd[3338969]: open(/home/me/.cache/obexd/MOC740): Operation not permitted (1)

エラーメッセージに表示されれたパス内にシンボリックリンクが含まれている場合、obexd はデフォルトで[https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/plugins/filesystem.c#n90 それを拒否します]。この挙動は、[[ドロップインファイル]]を {{ic|obex.service}} [[systemd/ユーザー|ユーザサービス]]に対して使うことにより初期化時に上書きできます:

{{hc|~/.config/systemd/user/obex.service.d/10-symlink.conf|2=
[Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/obexd --symlinks
}}

その後、ユーザの ''systemd'' マネージャの設定を[[リロード]]し、{{ic|obex.service}} ユーザユニットを[[再起動]]してください。

== 参照 ==

* [https://averylarsen.com/2019/12/20/keeping-bluetooth-devices-paired-between-linux-and-windows/ Keeping Bluetooth devices paired between Linux and Windows]
* [https://nullroute.eu.org/~grawity/bluetooth-key-sharing.html Bluetooth link keys on dual-boot systems]

{{TranslationStatus|Bluetooth|2023-11-03|791392}}

Bluetooth

2025-12-06T13:06:27Z

[[Category:Bluetooth]]
[[de:Bluetooth]]
[[en:Bluetooth]]
[[es:Bluetooth]]
[[ru:Bluetooth]]
[[zh-hans:Bluetooth]]
{{Related articles start}}
{{Related|Bluetooth マウス}}
{{Related|Bluetooth キーボード}}
{{Related|Bluetooth ヘッドセット}}
{{Related|Blueman}}
{{Related|ObexFTP}}
{{Related articles end}}
[[Wikipedia:ja:Bluetooth|Bluetooth]] は携帯電話やコンピュータなどの電子デバイス用の近距離無線通信規格です。Linux においては、Bluetooth プロトコルスタックの実装として [http://www.bluez.org/ BlueZ] が標準的に使われています。

== インストール ==

# Bluetooth プロトコロスタックを提供する、{{Pkg|bluez}} パッケージを[[インストール]]します。
# {{ic|bluetoothctl}} ユーティリティを提供する、{{Pkg|bluez-utils}} を[[インストール]]します。{{Pkg|bluez-deprecated-tools}} を[[インストール]]して、[[#非推奨の BlueZ ツール|非推奨の BlueZ ツール]] を追加します。
# 一般的な Bluetooth ドライバは、{{ic|btusb}} カーネルモジュールです。このモジュールがロードされているかどうかを[[カーネルモジュール#情報を取得|確認]]してください。もしロードされていなければ、[[カーネルモジュール#手動でモジュールを扱う|モジュールをロード]]してください。
# {{ic|bluetooth.service}} を[[起動/有効化]]します。

{{Note|
* デフォルトでは bluetooth デーモンは {{ic|lp}} [[ユーザーとグループ#システムグループ|グループ]]のメンバーのユーザーだけに bnep0 デバイスを提供します。bluetooth テザリングに接続するときはユーザーをグループに追加しておいてください。必要なグループは {{ic|/etc/dbus-1/system.d/bluetooth.conf}} ファイルで変更することができます。
* Bluetooth アダプターには Wi-Fi カードがバンドルされているものもあります (例: [https://www.intel.com/content/www/us/en/wireless-products/centrino-advanced-n-6235.html Intel Centrino]{{Dead link|2023|09|16|status=404}})。これらの Bluetooth アダプターをカーネルから見えるようにするには、まず Wi-Fi カードを有効にする必要があります (大体はラップトップ上のキーボードショートカットを使う)。
* Bluetooth カードによってはネットワークアダプタと衝突することがあります (例: Broadcom)。したがって、ネットワークサービスを起動する前に Bluetooth デバイスを接続するようにしてください。
* hcitool や hciconfig などのツールは上流では非推奨となっており、{{Pkg|bluez-utils}} にはもはや含まれていません。アップデートされないことが決まっているため、スクリプトの中で使用している場合は使わないように書き換えることを推奨します。それでも使いたい場合は {{Pkg|bluez-deprecated-tools}} をインストールしてください。詳しい情報は {{Bug|53110}} や [https://lore.kernel.org/linux-bluetooth/20170104133401.3636-1-luiz.dentz@gmail.com/ Bluez メーリングリスト] を参照。
* 2024年から、{{Pkg|bluez-obex}}と{{Pkg|bluez-mesh}}は{{Pkg|bluez}}から分離されました。よって、Bluetooth越しにファイルを転送したい場合は、{{Pkg|bluez-obex}}をインストールし、ユーザーサービス {{ic|obex.service}} を有効化する必要があります。}}

=== フロントエンド ===

==== コンソール ====

* {{App|bluetoothctl|シェルからデバイスをペアリングすることは、最も単純で信頼性の高いオプションの一つです。|http://www.bluez.org/|{{Pkg|bluez-utils}}}}
* {{App|bluetuith|ターミナルユーザインターフェイスによる Bluetooth マネージャを提供します。OBEX ファイル転送とマウスのサポート付きで、デバイス/アダプタを簡単に管理できます。|https://www.github.com/darkhz/bluetuith|{{AUR|bluetuith}}}}

{{Tip|bluetoothctl コマンドを自動化するには、{{ic|echo -e "''command1''\n''command2''\n" {{!}} bluetoothctl}} または {{ic|bluetoothctl -- ''command''}} を使用します。}}

==== グラフィカル ====

以下のパッケージでは、Bluetooth をカスタマイズするためのグラフィカルインターフェイスが利用可能です。

* {{App|GNOME Bluetooth|[[GNOME]] の Bluetooth ツール。
** {{Pkg|gnome-bluetooth-3.0}} バックエンドを提供 ({{Pkg|gnome-bluetooth}} はレガシーです)
** {{Pkg|gnome-shell}} ステータスモニターアプレットを提供
** {{Pkg|gnome-control-center}} は設定用のフロントエンド GUI を提供しており、アクティビティ概要で Bluetooth と入力するか、 {{ic|gnome-control-center bluetooth}} コマンドでアクセスすることができます。
** また、{{ic|bluetooth-sendto}} コマンドを直接起動して、リモートデバイスにファイルを送信することも可能です。
** {{AUR|nautilus-bluetooth}} は Nautilus の右クリックメニューに "Bluetoothで送信" エントリを追加します。
** ファイルを受信するには、Bluetooth 設定パネルを開きます。Bluetooth パネルが開いている間のみ受信できます。
** Thunar のファイルプロパティメニューの ''送信先'' メニューに Bluetooth エントリを追加するには、説明 [https://docs.xfce.org/xfce/thunar/send-to ここ] を参照してください。(設定が必要なコマンドは {{ic|bluetooth-sendto %F}} です)
|https://wiki.gnome.org/Projects/GnomeBluetooth|}}
* {{App|Bluedevil|[[KDE]] の Bluetooth ツール。 Dolphin やシステムトレイに Bluetooth のアイコンが表示されていない場合は、システムトレイオプションで有効にするか、ウィジェットを追加してください。アイコンをクリックすることで、Bluedevil の設定や Bluetooth デバイスの検出が可能です。KDE システム設定からもインターフェースが利用できます。|https://invent.kde.org/plasma/bluedevil|{{Pkg|bluedevil}}}}
* {{App|Blueberry|GNOME Bluetooth から Linux Mint でスピンオフした ''Blueberry'' は全てのデスクトップ環境で動作します。Obex Object Push によるファイル受信をサポートしていません。|https://github.com/linuxmint/blueberry|{{Pkg|blueberry}}}}
* {{App|[[Blueman]]|フル機能の Bluetooth マネージャー|https://github.com/blueman-project/blueman|{{Pkg|blueman}}}}
* {{App|[[ObexFTP]]|OBEX 対応のデバイスとの間でファイルを転送するツール。|http://dev.zuckschwerdt.org/openobex/wiki/ObexFtp|{{AUR|obexftp}}}}

== ペアリング ==

{{Note|Bluetooth デバイスを使用する前に、[[rfkill]] でブロックされていないことを確認してください。}}

このセクションでは、''bluetoothctl'' CLI を使って ''bluez5'' を直接設定する方法を説明しています。これは、代替のフロントエンドツール(例えば GNOME Bluetooth)を使用している場合は必要ないかもしれません。

正確な手順は、利用するデバイスとその入力機能によります。以下は {{ic|bluetoothctl}} を使ってデバイスをペアリングする一般的な説明です。

{{ic|bluetoothctl}} 対話コマンドを実行してください。{{ic|help}} と入力することで利用できるコマンドのリストを表示できます。

# (任意) {{ic|select ''MAC Address''}} と入力してデフォルトのコントローラを選択してください。
# (任意) デバイスがオフになっている場合、{{ic|power on}} と入力してコントローラへの電源供給をオンにしてください。デバイスはデフォルトでオンになっています ([[#アダプタのデフォルト電源状態]])。
# {{ic|devices}} と入力して、ペアリングしたいデバイスの MAC アドレスを取得してください。
# デバイスが表示されないときは {{ic|scan on}} コマンドでデバイス検出モードにしてください。
# {{ic|agent on}} でエージェントをオンにするか、特定のエージェントを選択してください: {{ic|agent}} の後にタブキーを2回押すと、利用可能なエージェントのリストが表示されるはずです。Bluetooth エージェントとは、Bluetooth の 'ペアリングコード' を管理するもののことです。エージェントは、'ペアリングコード'の受信に応答したり、'ペアリングコード'を送信したりできます。ほとんどの場合、{{ic|default-agent}} を使うのが適切なはずです。[https://askubuntu.com/questions/763939/bluetoothctl-what-is-a-bluetooth-agent]
# {{ic|pair ''MAC Address''}} と入力することでペアリングを実行します (タブ補完が使えます)。
# PIN がないデバイスを使う場合は、手動でデバイスを信頼する必要があるかもしれません。{{ic|trust ''MAC Address''}} と入力してこれを行なって下さい。デバイスを信頼するには {{ic|trust ''MAC_address''}} と入力してください。
# {{ic|connect ''MAC_address''}} を使って接続を確立してください。

セッションの例は以下のようになります:

{{hc|$ bluetoothctl|
[NEW] Controller 00:10:20:30:40:50 ''hostname'' [default]
[bluetooth]# agent KeyboardOnly
Agent registered

[bluetooth]# default-agent
Default agent request successful

[bluetooth]# power on
Changing power on succeeded
[CHG] Controller 00:10:20:30:40:50 Powered: yes

[bluetooth]# scan on
Discovery started
[CHG] Controller 00:10:20:30:40:50 Discovering: yes
[NEW] Device 00:12:34:56:78:90 ''device name''
[CHG] Device 00:12:34:56:78:90 LegacyPairing: yes

[bluetooth]# pair 00:12:34:56:78:90
Attempting to pair with 00:12:34:56:78:90
[CHG] Device 00:12:34:56:78:90 Connected: yes
[CHG] Device 00:12:34:56:78:90 Connected: no
[CHG] Device 00:12:34:56:78:90 Connected: yes
Request PIN code
[agent] Enter PIN code: 1234
[CHG] Device 00:12:34:56:78:90 Paired: yes
Pairing successful
[CHG] Device 00:12:34:56:78:90 Connected: no

[bluetooth]# connect 00:12:34:56:78:90
Attempting to connect to 00:12:34:56:78:90
[CHG] Device 00:12:34:56:78:90 Connected: yes
Connection successful
}}

=== デュアルブートペアリング ===

デュアルブート環境でデバイスをペアリングするには、Linux の方でペアリングキーを変更して Windows または macOS で使用されているペアリングキーと同じにする必要があります。

このページでは、これを手動で行う方法のみを説明しています。この手順を自動化するには、[https://github.com/x2es/bt-dualboot bt-dualboot プロジェクト]や関連するリポジトリを参照してください。

==== 設定方法 ====

これを行うには、まず Arch Linux 上でデバイスのペアリングを行います。その後、もう一方の OS を再起動し、デバイスをペアリングします。ここでペアリング・キーを取り出す必要がありますが、まず Bluetooth デバイスの電源を切り、接続を試みないようにします。

{{Note|([[Logitech MX Master]] や Logitech 604 Lightspeed などの) 一部の Logitech デバイスは、デバイスが新しいシステムとペアリングするたびに MAC アドレスの値を1つ増加させます。プロセスの最後にこれに対処するために、このケースに該当するかどうかを確認する必要があります。}}

==== Windows の場合 ====

===== Windows での展開 =====

まず、Windows を起動してください。

リンクキーを含むレジストリキーは、[https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts#system SYSTEM アカウント]でしかアクセスできないため、ログインすることができません。そのため、{{ic|regedit.exe}} を {{ic|SYSTEM}} として実行するには、Windows Sysinternals 公式サイトにある Microsoft の [https://docs.microsoft.com/en-us/sysinternals/downloads/psexec PsExec] ツールが必要になります。

[https://download.sysinternals.com/files/PSTools.zip PsTools] をダウンロードし、{{ic|PsExec64.exe}} を解凍します。

[https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/windows-commands#command-shell-overview コマンドシェル] の管理者インスタンスで、解凍した EXE の場所からレジストリエディタを起動してください:

.\PsExec64.exe -s -i regedit.exe

レジストリエディタで、以下のレジストリキーに移動します:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys

このキーの中に各 Bluetooth アダプターの MAC アドレス別のキーがあります。複数のキーがあり、どれを使えばいいかわからない場合は、[https://www.addictivetips.com/windows-tips/find-bluetooth-mac-address-windows-10/ このガイド]に従って、目的の Bluetooth アダプタの MAC アドレスを検索してください。

目的のデバイスアダプタキーの中に、ペアリングされたデバイスのそれぞれに対してキーが、MAC アドレスと関連付けられて存在しています。

インストール間で共有したい各ペアデバイスについて、キー全体を右クリックし、''.reg'' ファイルとしてエクスポートしてください。これはテキストファイルで、このファイルからキーをコピーできます。

このファイルにバイナリキーが1つだけ存在する場合、Bluetooth 5.1 デバイスではなく、そのペアリングキーが必要なもの全てであるということになります。

ペアリングしたデバイスに複数のキー ({{ic|LTK}} や {{ic|IRK}} など) が存在する場合、これは Bluetooth 5.1 デバイスで''ある''ということになります。これらのキーを使う方法は [[#Bluetooth 5.1 キーの準備]] を見てください。

最後に、キーを Linux 環境にインポートするために、Linux を起動して [[#終わりに]] へ進んでください。

===== Linux での展開 =====

{{Note|Windows パーティションが Bitlocker で暗号化されている場合、Linux から chntpw を使ってアクセスすることはできません。}}

Arch をリブートしてください。{{Pkg|chntpw}} をインストールして、Windows システムドライブをマウントします。

$ cd ''/path/to/windows/system''/Windows/System32/config
$ chntpw -e SYSTEM
{{Note|CurrentControlSet の代わりに ControlSet00X（X は任意の数字）と表示されることがあります。ls コマンドで確認してください。}}
{{ic|chntpw}} 環境の中で以下を実行します。

> cd CurrentControlSet\Services\BTHPORT\Parameters\Keys
もしくは
> cd ControlSet00X\Services\BTHPORT\Parameters\Keys

次に、Bluetooth アダプタの MAC アドレスを取得し、そのフォルダを入力します。

> ls
> cd ''your-device's-mac-address''

ペアリングしているデバイスにも同じことをします。Bluetooth 5.1 デバイスで''ない''場合、ペアリングキーしか表示されません:

{{hc|> ls|
Node has 0 subkeys and 1 values
size type value name [value if type DWORD]
16 REG_BINARY <123456789876>
}}

Bluetooth 5.1 デバイスである場合、{{ic|hex}} を通して、デバイスのキーを取得します。

{{hc|> hex 123456789876|
:00000 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX (いくつかの他の文字)
}}

”XX" はペアリング・キーです。どのキーがどの MAC アドレスにマッピングされているか、メモしておいてください。

Bluetooth 5.1 デバイスで''ある''場合、1つのデバイスに対応するキーが複数表示されます。

{{bc|
Node has 0 subkeys and 8 values
size type value name [value if type DWORD]
16 3 REG_BINARY <LTK>
4 4 REG_DWORD <KeyLength> 16 [0x10]
8 b REG_QWORD <ERand>
4 4 REG_DWORD <EDIV> 37520 [0x9290]
16 3 REG_BINARY <IRK>
8 b REG_QWORD <Address>
4 4 REG_DWORD <AddressType> 1 [0x1]
4 4 REG_DWORD <AuthReq> 45 [0x2d]
}}

これらのキーを使う方法は [[#Bluetooth 5.1 キーの準備]] を見てください。必要な値を得るには {{ic|hex ''value_name''}} を使います。

最後に、キーを Linux 環境にインポートするために [[#終わりに]] へ進んでください。

==== macOS の場合 ====

macOS を起動し:

* macOS Monterey 及びそれ以降の場合:
*# Keychain Access を開き、Bluetooth と検索してください。
*# 日付順でソートしてください。
*# 対象のデバイスを最近取り除いて再接続した場合、キーを変更日時順でソートして、最新のものを選べばよいです。キーはおそらく MobileBluetooth (古い Bluetooth デバイスの場合) という名前か、UUID (Bluetooth 5.1 以降) だけです。
*# 対象のエントリをダブルクリックしてください。Account フィールドの MAC アドレスが対象デバイスの MAC アドレスと一致することを確認してください。
*# "Show password" チェックボックスをクリックしてください。ここで、パスワードを2回入力する必要があります。
*# パスワードフィールド内のテキストをコピーしてください ({{ic|⌘+a}} {{ic|⌘+c}})。これは実際には XML ファイルです。
#* テキストをホームディレクトリ内の {{ic|bt_keys.txt}} ファイルにペーストしてください。
* High Sierra 及びそれ以降の場合、次のコマンドをターミナルで実行してください: {{bc|# defaults read /private/var/root/Library/Preferences/com.apple.bluetoothd.plist LinkKeys > ~/bt_keys.txt}}
* Sierra 及びそれ以前の場合、次のコマンドをターミナルで実行してください: {{bc|# defaults read /private/var/root/Library/Preferences/blued.plist LinkKeys > ~/bt_keys.txt}}

すると、{{ic|~/.bt_keys.txt}} ファイルには、確立された Bluetooth キーが含まれています。古いバージョンの macOS (High Sierra 及びそれ以前) では、先に進む前にキーの並びを逆にする必要があります。例えば、{{ic|98 54 2f aa bb cc dd ee ff gg hh ii jj kk ll mm}} は {{ic|MM LL KK JJ GG FF EE DD CC BB AA 2F 54 98}} になります。

{{Note|キーの並びを逆にするには、以下の [[Python]] コードを使用できます:
{{bc|1=
>>> key = "98 54 2f aa bb cc dd ee ff gg hh ii jj kk ll mm"
>>> " ".join(reversed(key.strip().split()))
}}
}}

Bluetooth 5.1 デバイスの場合、1つのデバイスに対して複数のキーが関連付けられています。それらのキーを使用する方法については [[#Bluetooth 5.1 キーの準備]] を見てください。

最後に、キーを Linux 環境にインポートするために、Linux を起動し、[[#終わりに]] へ進んでください。

==== Bluetooth 5.1 キーの準備 ====

[[#Windows の場合]] や [[#macOS の場合]] の章に従っていて Bluetooth 5.1 キーが存在していた場合、それらのキーを Linux にインポートする前に特定の変換をかける必要があります。[[#終わりに]] の章で使うために、要求されたファイルを適切に作成してください。この手順は対象デバイスによって異なり、キーの一部を操作する必要があります。これを行うためのユーティリティは以下で挙げられています。

{| class="wikitable"
! デバイス !! 元のキー及び変換 (Windows) !! 元のキー及び変換 (macOS) || キーの保存先ファイル
|-
|rowspan="3"|
* Logitech MX Master 3
* Xbox One S Wireless Controller
|
* {{ic|IRK}} をコピー。
* 16進数の桁間のスペースを除去。
| {{Grey|?}}
| {{ic|IdentityResolvingKey.Key}}
|-
|
* {{ic|LTK}} をコピー。
* 16進数の桁間のスペースを除去。
| {{Grey|?}}
| {{ic|SlaveLongTermKey.Key}} と {{ic|PeripheralLongTermKey.Key}}
|-
|{{ic|ERand}} と {{ic|EDIV}} は {{ic|0}} にする必要あり。
|''Random Number'' と ''Encrypted Diversifier'' は {{ic|0}} にする必要あり。
| {{-}}
|-
|rowspan="4"|
* ThinkPad TrackPoint Keyboard II
* Pebble M350 マウス
* Logitech G604 Lightspeed マウス
|
* {{ic|IRK}} をコピー
* バイトの順番を逆に。
|
* ''Remote IRK'' をコピー。
* Base64 から16進数に変換。
| {{ic|IdentityResolvingKey.Key}}
|-
|
* {{ic|LTK}} をコピー。
* 16進数の桁間のスペースを除去。
|
* ''Remote Encryption'' を ''Long-term Key'' にコピー。
* Base64 から16進数に変換。
| {{ic|LongTermKey.Key}}
|-
|
* {{ic|ERand}} をコピー。
* バイトの順番を逆に。
* 数値全体を10進数に変換。
|
* ''Remote Encryption'' を ''Random Number'' にコピー
* Base64 をリトルエンディアンの10進数に変換 (以下の Python コードを参照)。
| {{ic|LongTermKey.Rand}}
|-
|
* {{ic|EDIV}} をコピー。
* バイトの順番を逆に。
* 数値全体を10進数に変換。
|
* ''Remote Encryption'' を ''Encrypted Diversifier'' にコピー。
* Base64 からリトルエンディアンの10進数に変換 (以下の Python コードを参照)。
| {{ic|LongTermKey.EDiv}}
|-
|rowspan="3"|他のデバイス
|
* {{ic|LTK}} をコピー。
* 16進数の桁間のスペースを除去。
|
* ''Remote IRK'' をコピー。
* Base64 から16進数に変換。
| {{ic|LongTermKey.Key}}
|-
|
* {{ic|ERand}} をコピー。
* バイトの順番を逆に。
* 数値全体を10進数に変換。
|
* ''Remote Encryption'' を ''Long-term Key'' にコピー。
* Base64 から16進数に変換。
| {{ic|LongTermKey.Rand}}
|-
|
* {{ic|EDIV}} をコピー。
* 16進数の桁間のスペースを除去。
|
* ''Remote Encryption'' を ''Encrypted Diversifier'' にコピー。
* Base64 から16進数に変換。
* バイトの順番を逆に。
| {{ic|LongTermKey.EDiv}}
|-
|rowspan="1"|Xbox ワイヤレスコントローラ
|
* {{ic|LTK}} をコピー。
* 16進数の桁間のスペースを除去。
| {{Grey|?}}
| {{ic|SlaveLongTermKey.Key}}
|}

{{Note|
* 値からスペースを取り除くには、[https://www.browserling.com/tools/remove-all-whitespace このオンラインツール]や以下の [[Python]] コードを使用できます:
>>> "''key_value''".replace(" ", "")
* 以下の Python コードはバイトの順番を逆にするだけです:
{{bc|1=
>>> ERand=" 63 02 84 B8 5D 40 44 DF "
>>> ERand=list(reversed(ERand.strip().split()))
}}
* 以下の Python コードは、一部で必要となる追加の10進数変換を行います:
{{bc|1=
>>> int("".join(ERand), 16)
16088054540146049635
}}
* 以下の Python コードは base64 から16進数への変換を行います:
binascii.hexlify(base64.decodebytes(b'...')).upper()
* 以下の Python コードは完全な macOS Encrypted Diversifier の変換を行います:
struct.unpack('<H', base64.decodebytes(b'...'))
* 以下の Python コードは完全な macOS Random Number の変換を行います:
struct.unpack('<Q', base64.decodebytes(b'...'))
}}

一般的なケースの例としては:
* {{ic|LTK}} の値 {{ic|48 4D AF CD 0F 92 22 88 0A 52 9A F4 76 DA 8B 94}} は、{{ic|LongTermKey.Key}} の値 {{ic|484DAFCD0F9222880A529AF476DA8B94}} となります。
* {{ic|ERand}} の値 {{ic|63 02 84 B8 5D 40 44 DF}} は、{{ic|Rand}} の値 {{ic|16088054540146049635}} となります。
* {{ic|EDIV}} の値 {{ic|37520}} は、{{ic|EDiv}} の値 {{ic|37520}} となります。

==== 設定の保存 ====

キーを手に入れたら、ユーザーを root に変更し、以下を実行してください:

{{bc|# cd /var/lib/bluetooth/''BT-Adapter-MAC-address''}}

ここには、ペアリングした Bluetooth 機器ごとのフォルダがあります。Arch とデュアルブートでペアリングしたい各デバイスについて、以下を実行します:

{{bc|# cd ''device-MAC-address''}}

{{Note|この時点で、ペアリング時に MAC アドレスの値を増加させるデバイスを使用している場合、MAC アドレスのディレクトリを、値を増加させたパスへ移動させる必要があります。Windows から MAC アドレスをコピーするか、あるいは、各オクテットが2桁の[[Wikipedia:Hexadecimal|16進数]]であることに注意しながら自分で値を増加させてください。}}

ペアリングキーを持っている場合 (つまり、これは Bluetooth 5.1 デバイスでない)、{{ic|info}} ファイルを編集し、{{ic|[LinkKey]}} 以下のキーを変更します。例えば:

{{hc|1=info|2=
[LinkKey]
Key=XXXXXXXXXXXXXXX
}}

{{Note|すべての文字が大文字であることを確認する必要があります。スペースはすべて削除してください。}}

複数のキーが存在する場合 (Bluetooth 5.1 の場合)、以下の {{ic|info}} ファイルを編集して、全てのキーをそれぞれの値で置き換えてください。例えば、Xbox One S Wireless Controller の場合:

{{hc|1=info|2=
[IdentityResolvingKey]
Key=<IdentityResolvingKey.Key>

[PeripheralLongTermKey]
Key=<PeripheralLongTermKey.Key>

[SlaveLongTermKey]
Key=<SlaveLongTermKey.Key>
}}

次に、{{ic|bluetooth.service}} と {{ic|pulseaudio}} を[[再起動]]してください。({{ic|pulseaudio -k && pulseaudio --start}} を使ってください。)

これで、デバイスに接続できるはずです。

{{Note|Bluetooth マネージャによっては、デバイスに再接続するために完全な再起動が必要な場合があります。}}

== 設定 ==

=== アダプタのデフォルト電源状態 ===

{{Pkg|bluez}} 5.65 以降、BlueZ はデフォルトで、サービスの起動時やサスペンドからの復帰時にすべての Bluetooth アダプタをオンにします。[https://github.com/bluez/bluez/commit/180cf09933b2d8eb03972c8638063429fe5fece5]

アダプタを自動で有効化させたくない場合(例えば、ポータブルデバイスなどでバッテリを節約したい場合)、{{ic|/etc/bluetooth/main.conf}} の {{ic|[Policy]}} セクションで {{ic|1=AutoEnable=false}} を設定してください:

{{hc|1=/etc/bluetooth/main.conf|2=
[Policy]
AutoEnable=false
}}

この設定を行っても、[[#ペアリング]] で説明されているように {{ic|power on}} を実行すれば、アダプタを手動でオンにできます。

=== 起動時に発見可能にする ===

デバイスが常に見えていて、かつ直接接続できる必要がある場合:

{{hc|1=/etc/bluetooth/main.conf|2=
[General]
DiscoverableTimeout = 0
}}

=== サスペンドからの復帰 ===

Bluetooth キーボードやマウスなどをサスペンドから起動できるようにする。まず、bios の設定を確認し、サスペンドからの復帰が無効になっていないことを確認します。多くの場合、マザーボードからの Bluetooth は USB デバイスです。

bluetooth アダプターのベンダーコードとデバイス ID を確認してください:

{{hc|$ lsusb {{!}} grep bluetooth -i|
Bus 001 Device 002: ID 8087:0039 Intel Corp. AX200 Bluetooth
}}

サスペンドからの復帰を有効にするために、ベンダコードとデバイス ID の新しい udev ルールを追加してください:

{{hc|/etc/udev/rules.d/91-keyboard-mouse-wakeup.rules|2=
SUBSYSTEM=="usb", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="0039" RUN+="/bin/sh -c 'echo enabled > /sys$env{DEVPATH}/../power/wakeup;'"
}}

復帰後に Bluetooth キーボードを自動的に再設定して、例えば異なるキーマップやキーのリピート速度をもたせたりする(詳細は [[Xorg でのキーボード設定#typematic delay と rate の調整]] と [[xmodmap]])には、[[実行可能属性|実行可能]]なスクリプトを作成してください。

{{hc|configure_keyboard.sh|2=
#!/bin/sh
export DISPLAY=:0
xset r rate 220 30
xmodmap /''your''/''path''/''to''/.Xmodmap
}}

そして、上記のような追加の udev ルールを作成してください。

{{hc|/etc/udev/rules.d/92-keyboard-reconfiguration-wakeup.rules|2=
SUBSYSTEM=="usb", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="0039" RUN+="/''your''/''path''/''to''/configure_keyboard.sh"
}}

=== 実験的な機能を有効化する ===

Bluez スタックは、バグがあるかもしれない新しい機能を D-Bus 実験的オプションおよびカーネル実験的オプションに留めます。実験的な機能は最終的に、安定していると判断され、もはやオプションを必要としなくなるので、どのような実験的な機能が存在するかはバージョンによって異なります (例えば、現在 D-Bus の実験的なインターフェイスを有効化すると、古いヘッドセットのバッテリーレベルを報告できるようになります)。実験的な機能を有効化するには、設定の対応する行をアンコメントしてください:

{{hc|/etc/bluetooth/main.conf|2=
...

# Enables D-Bus experimental interfaces
# Possible values: true or false
'''#Experimental = true'''

# Enables kernel experimental features, alternatively a list of UUIDs
# can be given.
# Possible values: true,false,<UUID List>
# Possible UUIDS:
...
# Defaults to false.
'''#KernelExperimental = true'''
}}

あるいは、{{ic|bluetooth.service}} を[[編集]]して、{{ic|--experimental}} フラグあるいは {{ic|--kernel}} フラグを追加してください。例えば、以下の[[ドロップインファイル]]のように:

{{hc|/etc/systemd/system/bluetooth.service.d/override.conf|2=
[Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/bluetoothd --experimental
}}

いずれの場合でも、{{ic|bluetooth.service}} を[[再起動]]する必要があります。

== オーディオ ==

通常は、オーディオサーバーと Bluetooth を統合するために追加の手順を実行する必要があります。これについては、以下のセクションで説明します。

Bluetooth オーディオや Bluetooth ヘッドセットなどの情報については [[Bluetooth ヘッドセット]] のページを見てください。

=== PulseAudio ===

Bluetooth ヘッドフォンやスピーカーのようなオーディオ機器を使うには {{Pkg|pulseaudio-bluetooth}} パッケージのインストールが必要です。インストールを反映させるために、pulseaudio を再起動してください: {{ic|pulseaudio -k}}。デフォルトの Pulseaudio インストールでは (具体的には、パッケージングされているデフォルトの {{ic|default.pa}} でユーザインスタンスを使用している場合)、即座に Bluetooth デバイスからスピーカーにオーディオをストリーミングできるはずです。[https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/stable-16.x/src/daemon/default.pa.in#L84-93]

システム全体の PulseAudio 設定がある場合は、デーモンを実行しているユーザー（通常は {{ic|pulse}}) が {{ic|lp}} グループに属しており、PulseAudio 設定に Bluetooth モジュールをロードしていることを確認します:

{{hc|/etc/pulse/system.pa|2=
...
load-module module-bluetooth-policy
load-module module-bluetooth-discover
...
}}

これは任意ですが、Bluetooth デバイスの接続時にすべてのオーディオをそのデバイスに自動で切り替えたい場合、{{ic|load-module module-switch-on-connect}} を追加してください。

=== PipeWire ===

v0.3.19 以降の PipeWire はデフォルトで Bluetooth をサポートしています。

=== ALSA ===

{{Note|Bluez5 は [[ALSA]] の直接統合を中止し、 [[PulseAudio]] のみをサポートします。 PulseAudio を使用できない場合、または使用しない場合は、次の手順に従ってください。}}

まず、 Bluetooth オーディオデバイスが正しくペアリングされ、システムに接続されていることを確認します。

次に、 {{AUR|bluez-alsa-git}} をインストールし、 {{ic|bluealsa}} サービスを開始(そして、有効に) し、ユーザーを {{ic|audio}} グループに追加します。

次のコマンドを実行して、すべてが意図したとおりに動作しているかどうかを確認します({{ic|''XX:XX:XX:XX:XX:XX''}} と {{ic|''FILE.wav''}} の部分は置き換えてください):

$ aplay -D bluealsa:SRV=org.bluealsa,DEV=''XX:XX:XX:XX:XX:XX'',PROFILE=a2dp ''FILE.wav''

最後に、 {{ic|~/.asoundrc}} に次の行を追加します。

{{hc|~/.asoundrc|
defaults.bluealsa {
service "org.bluealsa"
device "XX:XX:XX:XX:XX:XX"
profile "a2dp"
}
}}

これで、 {{ic|bluealsa}} デバイスを使って Bluetooth オーディオデバイスに接続できるようになります。ボリューム管理は {{ic|alsamixer}} とオプション {{ic|-D bluealsa}} を使って通常行われます。

== Bluetooth シリアル ==

Bluetooth-to-Serial modules (HC-05、HC-06) で Bluetooth シリアル通信が機能するようにするには、次の手順に従います:

[[#ペアリング|上記]]で説明したように、 {{ic|bluetoothctl}} を使って Bluetooth デバイスを'''ペアリング'''します。

{{Pkg|bluez-deprecated-tools}} をインストールします。新しいツールにはない機能があります。

ペアになっているデバイスの MAC アドレスを tty 端末にバインドします:

# rfcomm bind rfcomm0 ''MAC_address_of_Bluetooth_device''

これで、シリアル通信用に {{ic|/dev/rfcomm0}} を開くことができます:

$ picocom /dev/rfcomm0 -b 115200

== トラブルシューティング ==

{{Out of date|Replace hciconfig with newer commands.}}

=== 一般的なトラブルシューティング ===

==== デバッグ ====

デバッグするには、最初に {{ic|bluetooth.service}} を[[停止]]します。

そして {{ic|-d}} パラメーターを付けて開始します。

# /usr/lib/bluetooth/bluetoothd -n -d

別のオプションとして、 {{ic|btmon}} ツールが有ります。

==== 非推奨の BlueZ ツール ====

8つの BlueZ ツールは[https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=b1eb2c4cd057624312e0412f6c4be000f7fc3617 非推奨となり]、{{Pkg|bluez-utils}} から削除されましたが、それらのすべてが新しいツールに取って代わられたわけではありません。{{Pkg|bluez-deprecated-tools}} パッケージが非推奨となったツールを提供します。

{| class="wikitable"
|-
! 非推奨のツール
! あり得る代替
|-
| [https://manpages.debian.org/latest/bluez/gatttool.1.en.html gatttool] || btgatt-client, [https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/gatt-api.txt D-Bus Gatt API]{{Dead link|2023|10|29|status=404}}
|-
| [https://manpages.debian.org/latest/bluez/hciattach.1.en.html hciattach] || btattach
|-
| [https://manpages.debian.org/latest/bluez/hciconfig.1.en.html hciconfig] || btmgmt (そして bluetoothctl?)
|-
| [https://manpages.debian.org/latest/bluez-hcidump/hcidump.1.en.html hcidump] || btmon (そして btsnoop)
|-
| [https://manpages.debian.org/latest/bluez/hcitool.1.en.html hcitool] || なし、[https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/device-api.txt D-Bus Device API]{{Dead link|2023|10|29|status=404}} が利用可能
|-
| [https://manpages.debian.org/latest/bluez/rfcomm.1.en.html rfcomm]
| rowspan="2" | なし、[https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/profile-api.txt D-Bus Profile1 API]{{Dead link|2023|10|29|status=404}} の実装?
|-
| [https://manpages.debian.org/latest/bluez/ciptool.1.en.html ciptool]
|-
|[https://manpages.debian.org/latest/bluez/sdptool.1.en.html sdptool]
| なし、機能が、異なる D-Bus オブジェクトに散らばっている模様: [https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/profile-api.txt Profile]{{Dead link|2023|10|29|status=404}}、[https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/advertising-api.txt Advertising]{{Dead link|2023|10|29|status=404}}、そして [https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/device-api.txt device]{{Dead link|2023|10|29|status=404}} と [https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/adapter-api.txt adapter]{{Dead link|2023|10|29|status=404}} の UUID の配列。
|}

=== サービスの問題 ===

==== systemd: Condition check resulted in Bluetooth service being skipped ====

{{ic|bluetooth.service}} は {{ic|/sys/class/bluetooth}} ディレクトリが存在することのみを要求します。このディレクトリは {{ic|bluetooth}} カーネルモジュールによって作成されるはずです。このカーネルモジュールは、{{ic|systemd-udev}} が動作している Bluetooth ハードウェアデバイスを発見した場合にのみ、{{ic|systemd-udev}} により自動的にロードされます。

{{ic|/sys/class/bluetooth}} が存在しない場合、{{ic|lsmod}} コマンドを使って、Bluetooth カーネルモジュールがロードされているかどうかを確認してください。Bluetooth デバイスがあるにも関わらずロードされていない場合、[[カーネルモジュール#手動でモジュールを扱う|Bluetooth モジュールをロード]]し、{{ic|bluetooth.service}} を[[再起動]]することで、手動で起動できます。

また、{{ic|bluetooth}} モジュールをロードする際に、対応するカーネル Bluetooth ドライバもロードする必要があります。{{ic|btusb}} が最も可能性がありますが、{{ic|btrtl,btintel,btbcm,bnep,btusb}} などの可能性もあります。

{{ic|bluetooth.service}} の[[ユニットステータス]]を確認して、このサービスが起動しているかどうかを確認してください。

[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853207 Debian Bug report logs - #853207] も参照してください。

{{ic|bluetooth.service}} の起動に成功したが、まだ Bluetooth を使えないことがあります (例: {{ic|scan on}} の時に {{ic|bluetoothctl}} が {{ic|org.Bluez.Error.NotReady}} のようなメッセージを発する)。この場合、コンピュータを再起動し、次のことをダブルチェックしてください: {{ic|/sys/class/bluetooth}} ディレクトリが存在するか; {{ic|lsmod}} の出力に正しい Bluetooth モジュールが含まれているか; [[journal]] のログを確認するなど。{{ic|systemd-udev}} は、また手動の変更をせずとも Bluetooth ハードウェアを自動的に認識するはずです。

==== Bluetooth が suspend-to-idle 中のデバイスを即座に立ち上げてしまう ====

[[サスペンドとハイバネート|suspend-to-idle/S2idle/S0ix/Modern Standby]] する能力のあるシステムにおいては、Bluetooth コントローラがスリープ中も有効化されたままになります。通常、これにより、Bluetooth デバイスが接続されていると、システムが[https://bugzilla.kernel.org/show_bug.cgi?id=200039 スリープに移行した直後にスリープが解除されてしまいます]。

これを防ぐには、スリープに移行する前に Bluetooth を完全に無効化できます。{{Pkg|bluez-utils}} をインストールし、以下のファイルを作成してください:

{{hc|/etc/systemd/system/bluetooth-disable-before-sleep.service|2=
[Unit]
Description=Disable Bluetooth before going to sleep
Before=sleep.target
Before=suspend.target
Before=hybrid-sleep.target
Before=suspend-then-hibernate.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStart=/usr/bin/bluetoothctl power off
ExecStop=/usr/bin/bluetoothctl power on

[Install]
WantedBy=sleep.target
WantedBy=suspend.target
WantedBy=hybrid-sleep.target
WantedBy=suspend-then-hibernate.target
}}

このサービスを[[有効化]]し、スリープに移行した時に Bluetooth デバイスが切断されることや、スリープからの復帰時に Bluetooth が再び接続されることを確認してください。

この回避策を使用すると、[[#サスペンドからの復帰|Bluetooth マウス/キーボードを使ってシステムをスリープから復帰させること]]ができなくなります。

==== ヘッドレス/サーバのシステムでログアウト後に Bluetooth がオフになる ====

様々な原因が考えられます:

* [[PulseAudio]] と [[PipeWire]] は両方ともデフォルトでユーザサービスとして動作します。よって、最後のセッションが終了するとこれらのサービスは終了されます。この問題を解決するには、対象のユーザに対して [[systemd/ユーザー#systemd のユーザーインスタンスを自動起動|Lingering (残留)]] を有効化してください。
* さらに、[[WirePlumber]] を [[PipeWire]] と共に実行している場合 (これはよくある環境です)、WirePlumber は "logind-monitor" を実行します。これは、Bluetooth をログイン時に有効化し、ログアウト時に無効化します。問題の解決方法は [[WirePlumber#ログアウト後も Bluetooth を実行し続ける/ヘッドレス Bluetooth]] を見てください。

=== アダプタの問題 ===

==== hcitool scan: Device not found ====

* 一部のラップトップ (例: Dell Studio 15、Lenovo Thinkpad X1) では、Bluetooth モードを HID から HCI に切り替える必要があります。{{Pkg|bluez-hid2hci}} パッケージをインストールすれば、[[udev]] が自動的に切り替えを行うはずです。また、次のコマンドを実行して手動で HCI に切り替えることもできます:

# /usr/lib/udev/hid2hci

* デバイスが表示されず、かつマシンに Windows オペレーティングシステムがある場合、Windows から bluetooth アダプターを有効にして見てください。

* 場合によっては次のコマンドで問題が解決するかもしれません:

# bluetoothctl power on

==== bluetoothctl: No default controller available ====

一部のマザーボード Bluetooth コントローラにはバグがあります。バグがこの問題の原因であるか調べるには、{{ic|journalctl {{!}} grep hci}} を実行してください。このコマンドの出力に "command tx timeout" や "Reading Intel version command failed" のようなエントリが存在する場合、PC の電源を切り、電源ケーブルを物理的に外して数秒間放置してください。これにより、コントローラにファームウェアを再ロードさせます (通常の再起動では再ロードしません)。[https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1859592 こちら]のバグレポートを参照してください。

デバイスが [[rfkill]] によってブロックされていないことを確認してください。

また、一部の Intel カード (8260 など) は Bluetooth サービスによって正しく認識されないかもしれません。{{Pkg|bluez-utils}} の代わりに非推奨の {{Pkg|bluez-deprecated-tools}} を使うことでこの問題が解決したというケースが報告されています。

また、これは省電力機能が原因かもしれません。その場合、{{ic|1=btusb.enable_autosuspend=n}} [[カーネルパラメータ#設定|カーネルパラメータ]]により解決できる可能性があります。[https://bugzilla.redhat.com/show_bug.cgi?id=1573562 Red Hat Bugzilla – Bug 1573562] も参照してください。

時々、{{ic|btusb}} をオプション無しでアンロード・ロードすればコントローラを元に戻せることがあります:

# modprobe -r btusb
# modprobe btusb

また、ドングルが [[#CSR ドングル 0a12:0001|CSR クローン]]である場合にもこの問題が発生することがあります。

==== rfkill unblock: Do not unblock ====

デバイスがソフトブロックされていて [[ConnMan]] を動作させている場合、次を試してみて下さい:

$ connmanctl enable bluetooth

==== Bluetooth USB ドングル ====

USB ドングルを使う場合は、Bluetooth ドングルが認識されているか確認してください。USB ドングルを挿入する時に {{ic|journalctl -f}} を root として実行する(もしくは {{ic|/var/log/messages.log}} を調査する)ことで、そのことを確認できます。以下のような見た目であるはずです(hci を見てください)。

{{bc|
Feb 20 15:00:24 hostname kernel: [ 2661.349823] usb 4-1: new full-speed USB device number 3 using uhci_hcd
Feb 20 15:00:24 hostname bluetoothd[4568]: HCI dev 0 registered
Feb 20 15:00:24 hostname bluetoothd[4568]: Listening for HCI events on hci0
Feb 20 15:00:25 hostname bluetoothd[4568]: HCI dev 0 up
Feb 20 15:00:25 hostname bluetoothd[4568]: Adapter /org/bluez/4568/hci0 has been enabled
}}

最初の2行しか表示されていなかった場合、デバイスは見つかっていますが、そのデバイスを立ち上げる必要があります。
例:

{{hc|# btmgmt|
[mgmt]# info
Index list with 1 item
hci0: Primary controller
addr 00:1A:7D:DA:71:10 version 6 manufacturer 10 class 0x000000
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr
'''current settings:''' connectable discoverable bondable ssp br/edr le secure-conn
name Mozart
short name

[mgmt]# select hci0
Selected index 0

[hci0]# power up
hci0 Set Powered complete, settings: '''powered''' connectable discoverable bondable ssp br/edr le secure-conn

[hci0]# info
hci0: Primary controller
addr 00:1A:7D:DA:71:10 version 6 manufacturer 10 class 0x1c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr
'''current settings: powered''' connectable discoverable bondable ssp br/edr le secure-conn
}}

または

{{hc|# bluetoothctl|
[bluetooth]# show
Controller 00:1A:7D:DA:71:10 (public)
Name: Mozart
Alias: Mozart
Class: 0x0000095c
'''Powered: no'''
Discoverable: yes
Pairable: yes

[bluetooth]# power on
[CHG] Controller 00:1A:7D:DA:71:10 Class: 0x001c0104
Changing power on succeeded
[CHG] Controller 00:1A:7D:DA:71:10 '''Powered: yes'''

[bluetooth]# show
Controller 00:1A:7D:DA:71:10 (public)
Name: Mozart
Alias: Mozart
Class: 0x001c0104
'''Powered: yes'''
Discoverable: yes
Pairable: yes
}}

[https://www.bluetooth.com/specifications/assigned-numbers/host-controller-interface/ 公式の仕様表]に従って、Bluetooth のバージョンが HCI のバージョンにマップされていることを確認できます。例えば、先の出力では、HCI '''version 6''' が Bluetooth version 4.0 です。

デバイスが検出されているか確認するために {{ic|bluez-utils}} に含まれている {{ic|hcitool}} を使うことができます。次のコマンドで利用可能なデバイスとその識別子・MAC アドレスのリストを表示することが可能です:

{{hc|$ btmgmt info|
Index list with 1 item
hci0: Primary controller
addr 00:1A:7D:DA:71:10 '''version 6''' manufacturer 10 class 0x1c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr
current settings: powered connectable discoverable bondable ssp br/edr le secure-conn
}}

デバイスに関するもっと詳細な情報は、非推奨の {{ic|hciconfig}} を使うことで取得できます。({{AUR|bluez-utils-compat}})

{{hc|$ hciconfig -a hci0|
hci0: Type: USB
BD Address: 00:1B:DC:0F:DB:40 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:1226 acl:0 sco:0 events:27 errors:0
TX bytes:351 acl:0 sco:0 commands:26 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'BlueZ (0)'
Class: 0x000100
Service Classes: Unspecified
Device Class: Computer, Uncategorized
HCI Ver: 2.0 (0x3) HCI Rev: 0xc5c LMP Ver: 2.0 (0x3) LMP Subver: 0xc5c
Manufacturer: Cambridge Silicon Radio (10)
}}

===== ドングルから短距離にいるときにオーディオデバイスがおかしくなる =====

他のデバイスと同一の USB ホストを共有している場合、[https://bbs.archlinux.org/viewtopic.php?pid=1440161#p1440161 オーディオデバイスとの通信に干渉] する可能性があります。オーディオデバイスがバスに接続されている唯一のデバイスであることを確認してください。例:

{{hc|$ lsusb|
Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 048d:1345 Integrated Technology Express, Inc. Multi Cardreader
Bus 001 Device 003: ID 0424:a700 Standard Microsystems Corp. 2 Port Hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
}}

===== CSR ドングル 0a12:0001 =====

デバイス {{ic|ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)}} にはリグレッションのバグがあり、現在、カーネルバージョン 5.17 及び < 6.0 でしか動作しません。詳細は、[https://bugzilla.kernel.org/show_bug.cgi?id=60824 Kernel Bug 60824] を参照してください。

==== Logitech Bluetooth USB ドングル ====

Logitech のドングルには Embedded と HCI という二つのモードで動作するものがあります (例: Logitech MX5000)。embedded モードではドングルは USB デバイスをエミュレートするので PC は普通の USB マウス・キーボードを使っていると認識します。

USB BT ミニレシーバの小さな赤いボタンを押すと他のモードが有効になります。BT ドングルの赤いボタンを押しながらコンピュータに接続してください。ボタンを押して3-5秒で、Bluetooth アイコンがシステムトレイに表示されます ([https://ubuntuforums.org/showthread.php?t=1332197 議論])。

また、{{Pkg|bluez-hid2hci}} パッケージをインストールすることもできます。Logitech のドングルを接続すると自動的に切り替えます。

==== Foxconn / Hon Hai / Lite-On の Broadcom デバイス ====

一部のデバイスでは、起動時にファームウェアを書き込む必要があります。

一部のファームウェアは、[[AUR]] で [https://aur.archlinux.org/packages?K=broadcom broadcom] と検索すると入手できます。特出すべきパッケージは {{AUR|broadcom-bt-firmware}} です。これは、[https://github.com/winterheart/broadcom-bt-firmware/blob/master/DEVICES.md 様々なカード]用のファイルを提供します。

または、[https://github.com/jessesung/hex2hcd hex2hcd] ({{Pkg|bluez-utils}} でインストールされます) を使ってファームウェアを Microsoft Windows の ''.hex'' ファイルから ''.hcd'' ファイルに変換することもできます。

正しい ''.hex'' ファイルを取得するために、''lsusb'' でデバイスの vendor:product コードを検索してください。例:

Bus 002 Device 004: ID '''04ca:2006''' Lite-On Technology Corp. Broadcom BCM43142A0 Bluetooth Device

または:

Bus 004 Device 004: Id '''0489:e031''' Foxconn / Hon Hai

もしくは、Windows (仮想マシンでもかまいません) を起動して Device Manager ユーティリティからファームウェアの名前を取得してください。デバイスのモデルを知りたいのに ''lsusb'' で表示されない場合、''lsusb -v'' の {{ic|iProduct}} でわかることがあります。

''.hex'' ファイルはダウンロードした Windows ドライバーから抽出することができます。Windows を実行する必要はありません。適切なドライバーをダウンロードしてください (例えば、[http://www.fujitsupc.com/downloads/mobile/BLUETOOTH_WIDCOMM_V6.5.0.3100_WIN7-32_FPC46-1771-01.EXE Bluetooth Widcomm]{{Dead link|2023|09|16|status=domain name not resolved}})。フォーマットにも依りますが、ファイルの展開には{{Pkg|unrar}} か {{Pkg|cabextract}} が必要である場合があります。多数の ''.hex'' ファイルの中から必要なファイルを見つけるには、{{ic|Win32/bcbtums-win7x86-brcm.inf}} ファイルの中身を確認して {{ic|[RAMUSB'''E031'''.CopyList]}} を検索してください。{{ic|E031}} はあなたの使っているデバイスの product コード (大文字) に置き換えて下さい (''lsusb'' で確認できる2番目の16進数)。その下に、必要な ''.hex'' ファイルの名前が書かれているはずです。

''.hcd'' ファイルを手に入れたら、{{ic|/lib/firmware/brcm/BCM.hcd}} にコピーしてください - このファイル名は [[dmesg]] からわかります。あなたのマシンでは異なっている可能性があるため ''dmesg'' の出力で確認してください。そして ''btusb'' モジュールをリロードしてください:

# rmmod btusb
# modprobe btusb

これでデバイスが使えるようになるはずです。以上の設定を永続化させる方法は [https://bbs.archlinux.org/viewtopic.php?id=162688 BBS#162688] を参照。

==== Intel の複合 WiFi と Bluetooth カード ====

[[ネットワーク設定/ワイヤレス#Bluetooth の共存]] を見てください。

==== Windows とのデュアルブート環境における Mediatek MT7921 や MT7961 ====

デュアルブートシステムでは、Bluetooth のファームウェアバージョンが Windows と Linux とで異なる場合、Windows を起動した後に Bluetooth アダプタが動作しなくなります。

これを防ぐ最も良い方法は、各 OS 用の Bluetooth ドライバ (特にファームウェア) を最新にすることです。

Windows 用の最新バージョンのドライバ (またはファームウェア) を見つけられない場合、最新のファームウェアファイル {{ic|/usr/lib/firmware/mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin.xz}} を Arch Linux からコピーし、Windows へ展開することができます (例えば、{{ic|C:\WINDOWS\system32\DRIVERS\}}。Windows でのファームウェアファイルへのパスはデバイスマネージャから確認できます)。

==== サスペンド/復帰後にアダプタが消える ====

まず、アダプタのベンダーと製品 ID を見つけてください。例:

First, find vendor and product ID of the adapter. For example:

{{hc|$ lsusb -tv|<nowiki>
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
...
|__ Port 3: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
ID 8087:0025 Intel Corp.
|__ Port 3: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
ID 8087:0025 Intel Corp.
...
</nowiki>}}

この場合、ベンダー ID は 8087 で、製品 ID は 0025 です。

次に、 {{pkg|usb_modeswitch}} を使用してアダプタをリセットします:

# usb_modeswitch -R -v ''vendor_ID'' -p ''product_ID''

=== ペアリングと接続の問題 ===

==== コンピュータが表示されない ====

携帯からコンピュータが表示されないときは、discoverable モードを有効にしてください:

# bluetoothctl discoverable on

discoverable モードがオンになっていることを確認してください:

{{hc|# bluetoothctl show|
Powered: yes
Discoverable: yes
Pairable: yes
}}

{{Note|{{ic|/etc/bluetooth/main.conf}} の {{ic|PairableTimeout}} と {{ic|DiscoverableTimeout}} を確認してください。}}

まだコンピュータが表示されない場合、以下のように {{ic|/etc/bluetooth/main.conf}} 内のデバイスクラスを変更してみて下さい:

# Default device class. Only the major and minor device class bits are
# considered.
#Class = 0x000100 # Computer Type (from default config)
Class = 0x100100 # (Object-Transfer Service & Computer Type)

{{Note|場合によっては、{{ic|main.conf}} 内の {{ic|Class}} はデバイスの初期化後に上書きされます。なので、{{ic|hciconfig hci0 class 100100}} のようにクラスを直接設定してください。}}

あるユーザは、携帯からコンピュータを見られるようにするためにはこうするしか無いと報告しています。LG TV(そして、一部の他の機器)はオーディオデバイスから発見可能です。なので、{{ic|000414}} (soundbar クラス)を使用することでそのようなデバイスを発見できるようにできます。

Bluetooth デバイス/サービスのクラスを生成するには https://bluetooth-pentest.narod.ru/software/bluetooth_class_of_device-service_generator.html を見てください。

==== デバイスを接続した数秒後に切断してしまう ====

デバイスを接続したすぐ後に切断が発生し、ジャーナルの出力に以下のようなメッセージが確認できる場合:

bluetoothd: Unable to get connect data for Headset Voice gateway: getpeername: Transport endpoint is not connected (107)
bluetoothd: connect error: Connection refused (111)

おそらく別のオペレーティングシステムで同一の Bluetooth アダプタを使ってデバイスがペアリングされていることが原因です (例: デュアルブート)。一部のデバイスは同一の MAC アドレス (例: Bluetooth アダプタ) に対して複数のペアリングを関連付けた場合に対処できません。この問題を解決するには [[#デュアルブートペアリング]] の指示に従ってください。

==== スキャンしてもデバイスが表示されない ====

Bluetooth Low Energy を使用しているデバイスは bluetoothctl でスキャンしても表示されないことがあります (例: [[Logitech MX Master]])。{{ic|transport le}} を使ってスキャンすることができます。

{{hc|# bluetoothctl|
[bluetooth]# menu scan
[bluetooth]# transport le
[bluetooth]# back
[bluetooth]# scan on
[bluetooth]# devices
...
Device XX:XX:XX:XX:XX:XX DA V2 X <---- 低消費電力なデバイス
}}

もう一つの方法は、{{aur|bluez-utils-compat}} をインストールし、{{ic|bluetooth.service}} を[[開始]]し、以下を実行することです:

{{hc|# bluetoothctl|
[NEW] Controller (MAC) myhostname [default]

[bluetooth]# power on
[CHG] Controller (MAC) Class: 0x0c010c
Changing power on succeeded
[CHG] Controller (MAC) Powered: yes

[bluetooth]# scan on
Discovery started
[CHG] Controller (MAC) Discovering: yes
}}

他のターミナルで:

# hcitool lescan

デバイスが表示されるまで待機してから hcitool を {{ic|Ctrl+c}} で閉じてください。bluetoothctl からデバイスが認識されたら通常通りにペアリングできます。

==== Intel Corp. AX200 Bluetooth で BLE デバイスが見つからない ====

どうやら、このデバイスでは BLE のパッシブスキャンが壊れているようです。詳細は[https://community.intel.com/t5/Wireless/AX200-Passive-BLE-scan-linux/m-p/1227456 上流のバグレポート]を見てください。

==== スリープ後に再接続できない ====

スリープ後や、コンピュータがスリープから復帰した後に、デバイスが自動的に再接続されないことがあります。

この時、ログに以下のエラーが記録されます:

{{bc|
bluetoothd[487]: Authentication attempt without agent
bluetoothd[487]: Access denied: org.bluez.Error.Rejected
}}

これは、デバイスが ''trusted'' としてマークされていないことが原因です。[[#ペアリング]] を参照してください。

=== デバイス固有の問題 ===

==== Bluetooth マウスのラグ / 接続断 / 応答なし ====

[[Bluetooth マウス#トラブルシューティング]] を参照してください。

==== オーディオデバイスが br-connection-profile-unavailable で接続に失敗する ====

PipeWire (pulseaudio-bluetooth ではない) が使用されているが、PipeWire のインスタンスが実行されていない場合、bluetooth オーディオデバイスは接続に失敗します。PipeWire デーモンを開始するには、{{ic|pipewire.service}} [[ユーザーユニット]]を[[開始]]するか、何らかの音声を再生してください。その後、オーディオデバイスをもう一度接続してみてください。

==== ヘッドホンとマウスの干渉 ====

Bluetooth マウスとキーボードを同時に使用しているときに音声が途切れる場合は #23 https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/424215 で参照されているように、次を試してくみてださい:

# hciconfig hci0 lm ACCEPT,MASTER
# hciconfig hci0 lp HOLD,SNIFF,PARK

==== TP-LINK UB400 と Xbox のコントローラが接続/切断を繰り返す ====

以下の設定を使用してください:

{{hc|/etc/bluetooth/main.conf|2=
...
[General]
JustWorksRepairing = always
FastConnectable = true
Class = 0x000100
...
[GATT]
ReconnectIntervals=1,1,2,3,5,8,13,21,34,55
AutoEnable=true
...
}}

そして、{{ic|bluetooth.service}} を[[再起動]]してください。

関連する [https://github.com/atar-axis/xpadneo/issues/166 xpadneo に関する議論]を見ることができますが、xpadneo のドライバは必要ありません。

=== ファイル転送の問題 ===

==== gnome-bluetooth ====

bluetooth-properties でファイルの受信を有効にしようとしたときに以下のメッセージが表示される場合:

Bluetooth OBEX start failed: Invalid path
Bluetooth FTP start failed: Invalid path

[[XDG ユーザーディレクトリ]]が存在することを確認してください。

==== シンボリックリンクのせいで、転送されたファイルを受信できない ====

有効な Bluetooth 接続でファイルの受信に失敗する場合、問題はファイルの転送パス内のシンボリックリンクである場合があります。ジャーナルに以下のようなログが現れます:

Jun 18 11:18:13 ember obexd[3338969]: open(/home/me/.cache/obexd/MOC740): Operation not permitted (1)

エラーメッセージに表示されれたパス内にシンボリックリンクが含まれている場合、obexd はデフォルトで[https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/plugins/filesystem.c#n90 それを拒否します]。この挙動は、[[ドロップインファイル]]を {{ic|obex.service}} [[systemd/ユーザー|ユーザサービス]]に対して使うことにより初期化時に上書きできます:

{{hc|~/.config/systemd/user/obex.service.d/10-symlink.conf|2=
[Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/obexd --symlinks
}}

その後、ユーザの ''systemd'' マネージャの設定を[[リロード]]し、{{ic|obex.service}} ユーザユニットを[[再起動]]してください。

== 参照 ==

* [https://averylarsen.com/2019/12/20/keeping-bluetooth-devices-paired-between-linux-and-windows/ Keeping Bluetooth devices paired between Linux and Windows]
* [https://nullroute.eu.org/~grawity/bluetooth-key-sharing.html Bluetooth link keys on dual-boot systems]

{{TranslationStatus|Bluetooth|2023-11-03|791392}}

Vulkan

2025-12-04T08:58:17Z

[[Category:グラフィックス]]
[[Category:開発]]
[[en:Vulkan]]
[[pt:Vulkan]]
[[ru:Vulkan]]
[[zh-hans:Vulkan]]
[[Wikipedia:ja:Vulkan]] より:
:Vulkanは、低オーバーヘッドのクロスプラットフォーム3DグラフィックスおよびコンピュートAPIです。2016年に初めてリリースされ、[[OpenGL]] の後継として登場しました。

詳しくは [https://www.khronos.org/vulkan/ Khronos] のウェブサイトを参照してください。

== インストール ==

{{Note|[[ハイブリッドグラフィック]] ([[NVIDIA Optimus]]/AMD Dynamic Switchable Graphics) の場合:
* Vulkan は [[Bumblebee]] で公式ではサポートされていません。[https://github.com/Bumblebee-Project/Bumblebee/issues/769] を見てください。しかし、{{Pkg|primus_vk}} により動作します。
* Radeon の Vulkan ドライバーは [[PRIME]] をサポートしています。[https://www.phoronix.com/scan.php?page=news_item&px=RADV-PRIME-Lands] を参照。
}}

Vulkan アプリを実行するには {{pkg|vulkan-icd-loader}} と (32ビットのアプリケーションを実行したい場合は {{pkg|lib32-vulkan-icd-loader}} も)、使用しているグラフィックカードの Vulkan ドライバーを[[インストール]]する必要があります:

* [[AMD]]: {{Pkg|vulkan-radeon}} (または {{Pkg|lib32-vulkan-radeon}})
* [[Intel]]: {{Pkg|vulkan-intel}} (または {{Pkg|lib32-vulkan-intel}})
* [[NVIDIA]]: 二種類の実装があります:
** {{Pkg|nvidia-utils}}(または {{Pkg|lib32-nvidia-utils}}) - NVIDIA製(プロプライエタリ)
** {{Pkg|vulkan-nouveau}}(または {{Pkg|lib32-vulkan-nouveau}}) - NVK(Mesaプロジェクトの一部){{Note|NVKを有効にするには、追加のシステム設定が必要です。詳細については、[[Nouveau#Using the Mesa NVK Vulkan Driver]] をご覧ください。}}

以下はソフトウェアラスタライザーで、Vulkanサポートを提供しないデバイスで使用することができます。

* '''Lavapipe''': {{Pkg|vulkan-swrast}}(または {{Pkg|lib32-vulkan-swrast}})
* '''SwiftShader''': {{AUR|swiftshader-git}}

Vulkan アプリケーション開発には、{{Pkg|vulkan-headers}} を[[インストール]]し、オプションで {{Pkg|vulkan-validation-layers}}、{{AUR|vulkan-man-pages}}、および {{Pkg|vulkan-tools}} をインストールできます(vulkaninfo や vkcube ツールが含まれています)

== 検証 ==

システムに現在インストールされている Vulkan 実装を確認するには、次のコマンドを使用します。

$ ls /usr/share/vulkan/icd.d/

Vulkan がハードウェアで動作していることを確認するには、{{Pkg|vulkan-tools}} を[[インストール]]し、{{ic|vulkaninfo}} を使って関連情報をシステムから抜き出します。グラフックスカードの情報を手に入れれば、Vulkan が動作していることを知ることができます。

$ vulkaninfo

さらなる情報は https://linuxconfig.org/install-and-test-vulkan-on-linux で見ることができます。

== 切り替え ==

=== デバイス間の切り替え ===

複数の GPU を搭載したシステムでは、特定の GPU の使用を強制する必要がある場合があります。これを動作させるには、{{Pkg|vulkan-mesa-layers}} が必要です。{{ic|MESA_VK_DEVICE_SELECT}} を {{ic|''vendorID:deviceID''}} に設定することで、希望する GPU を選択できます。

候補を一覧表示するには、以下のコマンドを使用します:

$ MESA_VK_DEVICE_SELECT=list vulkaninfo

指定した値の末尾に {{ic|!}} を付けることで、この動作を強制することができます。詳細については、[https://docs.mesa3d.org/envvars.html#vulkan-mesa-device-select-layer-environment-variables Vulkan mesa device select layer environment variables] を参照してください。

=== AMD ドライバを切り替える ===

AMD のシステム上では、一度に複数の Vulkan ドライバをインストールすることができます。なので、それらを切り替えたい場合があります。

==== 環境変数で選択する ====

{{Note|この方法は AMDVLK クローズドドライバの選択をサポートしません。}}

{{Pkg|amdvlk}} 2021.Q3.4 以降、新しい切り替えロジックが実装されました。これにより、AMDVLK がデフォルトとなり、以下のいずれかを行う必要があります:

* {{ic|1=AMD_VULKAN_ICD=RADV}} を設定し、AMDVLK のデフォルトから他のものに切り替える。
* あるいは、グローバルに {{ic|1=DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1=1}} を設定し、以下の ICD ローダの方法を再有効化する。

{{ic|1=DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1=1}} が設定されると、{{ic|VK_ICD_FILENAMES}} 環境変数を設定することによりドライバを選択することができます。例えば、[[Steam]] を RADV ドライバで実行するようにするには:

$ VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.i686.json:/usr/share/vulkan/icd.d/radeon_icd.x86_64.json steam

32 ビットのゲームのクラッシュを回避するために、32 ビット版と 64 ビットを環境変数に割り当てることができます。

==== AMD Vulkan Prefixes で選択する ====

[https://gitlab.com/AndrewShark/amd-vulkan-prefixes AMD Vulkan Prefixes] は3つの Vulkan 実装を切り替えるためのスクリプトです。{{AUR|amd-vulkan-prefixes}} を[[インストール]]し、アプリケーションの前にお望みの接頭辞を付けてください。提供される実行ファイルは {{ic|vk_radv}}、{{ic|vk_amdvlk}}、そして {{ic|vk_pro}} です。例えば、AMDVLK クローズドドライバを使用するには:

$ vk_pro ''command''

== ソフトウェアレンダリング ==

ソフトウェア Vulkan ラスタライザーとして知られる lavapipe をインストールすることができます。例えば、ハードウェアの問題をデバッグするために使用します: {{Pkg|vulkan-swrast}} (または32ビット版の {{Pkg|lib32-vulkan-swrast}})

以下の例は、必要な環境変数を設定して、Vulkan と [[OpenGL#Mesa|OpenGL]] の完全なソフトウェアレンダリングを強制するために ''vulkaninfo'' を実行する方法を示しています ({{ic|1=__GLX_VENDOR_LIBRARY_NAME=mesa}} により、コマンドが [[PRIME]] ユーザーにも動作するようになります):

$ LIBGL_ALWAYS_SOFTWARE=1 __GLX_VENDOR_LIBRARY_NAME=mesa VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.i686.json:/usr/share/vulkan/icd.d/lvp_icd.x86_64.json vulkaninfo

== Vulkan ハードウェアデータベース ==

[https://vulkan.gpuinfo.org/ Vulkan Hardware Database] には、ユーザーが報告した GPU/ドライバーの組み合わせが提供されています。独自の情報を指定するには、{{AUR|vulkan-caps-viewer-wayland}} または {{AUR|vulkan-caps-viewer-x11}} を使用します。

== トラブルシューティング ==

=== NVIDIA - vulkanが動作しない、または初期化できない ===

==== 環境変数 ====

無効または矛盾する[[環境変数]]の値が原因で、Vulkan が失敗することがあります。不適切な値は、複数の GPU が搭載されたマシンで意図した GPU ではなく別の GPU を使用する原因となることもあります。環境変数を適切に設定することで、[https://bbs.archlinux.org/viewtopic.php?pid=2152232#p2152232 必要ないときにセカンダリ GPU を電源オフにする]のにも役立ちます。

==== GPU の切り替え ====

マシンに複数の GPU が搭載されていて、Vulkan がそのうちの1つを認識できない場合、その GPU が BIOS/UEFI やカーネルで無効にされていないことを確認してください。GPU 間の切り替え方法の概要については [[NVIDIA Optimus]] を参照してください。

現在の状態を確認するための例コマンド({{aur|optimus-manager-git}} を使用):

{{hc|$ optimus-manager --status|
Optimus Manager (Client) version 1.4

Current GPU mode : nvidia
GPU mode requested for next login : no change
GPU at startup : integrated
Temporary config path: no
}}

==== GSPファームウェア ====

[https://download.nvidia.com/XFree86/Linux-x86_64/555.42.02/README/gsp.html GSP ファームウェア]は、2024年6月にリリースされた NVIDIA ドライバのバージョン555以降、デフォルトで有効になっており、[https://bbs.archlinux.org/viewtopic.php?pid=2181317 Vulkan の失敗やシステムクラッシュを含むさまざまな問題]の原因として知られています。

これを無効にするには、{{ic|1=NVreg_EnableGpuFirmware=0}} [[モジュールパラメータ]]を{{ic|nvidia}}カーネルモジュールに設定します。これは独自の NVIDIA ドライバでのみ機能します:オープンソースドライバから切り替える場合は[[NVIDIA#インストール]] を参照してください。

必要に応じて [[initramfs の再生成]] を行うことを忘れないでください。この新しいカーネルモジュールオプションを有効にするには、再起動が必要です。

=== No device for the display GPU found. Are the intel-mesa drivers installed? ===

環境変数 VK_ICD_FILENAMES に intel_icd と primus_vk_wrapper の両方のセットしてみてください。

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_icd.x86_64.json:/usr/share/vulkan/icd.d/primus_vk_wrapper.json

=== AMDGPU - vulkaninfo 後に ERROR_INITIALIZATION_FAILED ===

GCN1 または GCN2 ファミリの AMD カードで {{ic|vulkaninfo}} を実行した後、次のようなエラーメッセージが表示された場合:
{{bc|ERROR at /build/vulkan-tools/src/Vulkan-Tools-1.2.135/vulkaninfo/vulkaninfo.h:240:vkEnumerateInstanceExtensionProperties failed with ERROR_INITIALIZATION_FAILED}}
次に、このモデルのグラフィックスカードのサポートが正しく有効になっているかどうかを確認します ([[AMDGPU#Southern Islands (SI) と Sea Islands (CIK) のサポートを有効化]])

GPU ドライバーが正しくロードされているかどうかを確認する方法の 1 つは、{{ic|lspci -k}} です。このコマンドを実行した後、GPU のカーネルドライバーを確認してください。{{ic|amdgpu}} である必要があります。

{{hc|$ lspci -k|
...
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM]
Subsystem: Gigabyte Technology Co., Ltd Device 226c
Kernel driver in use: amdgpu
Kernel modules: radeon, amdgpu
...
}}

この問題に関するいくつかのフォーラムスレッド: [https://bbs.archlinux.org/viewtopic.php?id=254015] [https://bbs.archlinux.org/viewtopic.php?id=253843]

=== AMDGPU - DirectX Vulkan ゲームのプレイ中にがハングする ===

DirectX Vulkan を使用して一部のゲームをプレイすると、Radeon-Vulkan がドライバーや GPU のハングを引き起こすようです。

{{bc|
kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!
kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled ..., emitted ...
kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process ... pid ... thread dxvk-submit pid
...
}}

AMDVLK に切り替えるか有効にすると、問題が解決されるようです。

=== AMDGPU - DirectX Vulkan ゲームでクラッシュする ===

AMDVLK は複数のユーザーによるクラッシュを引き起こすと報告されています ([https://bbs.archlinux.org/viewtopic.php?id=284118 BBS#284118]、[https://bbs.archlinux.org/viewtopic.php? id=283008 BBS#283008]、[https://bbs.archlinux.org/viewtopic.php?id=274737 BBS#274737]): Radeon-Vulkan ドライバーに切り替えるか有効にすると、問題が解決します。

=== AMDGPU - Vulkan アプリケーションの起動が遅い ===

{{Pkg|cuda}} をインストールすると、例えば Chromium などの Vulkan アプリケーションの起動が遅いことがあります。これは、{{Pkg|nvidia-utils}} が Vulkan ドライバを提供しており、Vulkan が最初に nvidia ドライバを試み、その後に radeon ドライバを試すためです。これを解決するには、[[環境変数]] {{ic|VK_DRIVER_FILES}} を {{ic|/usr/share/vulkan/icd.d/radeon_icd.i686.json:/usr/share/vulkan/icd.d/radeon_icd.x86_64.json}} に設定します。

=== AMDGPU - Found no drivers! ===

{{ic|Found no drivers!}} に遭遇した場合:

{{hc|$ vulkaninfo|
WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Failed to CreateInstance in ICD 0. Skipping ICD.
ERROR: [Loader Message] Code 0 : terminator_CreateInstance: Found no drivers!
Cannot create Vulkan instance.
This problem is often caused by a faulty installation of the Vulkan driver or attempting to use a GPU that does not support Vulkan.
ERROR at /usr/src/debug/vulkan-tools/Vulkan-Tools-1.3.269/vulkaninfo/./vulkaninfo.h:688:vkCreateInstance failed with ERROR_INCOMPATIBLE_DRIVER
}}

AMD は定期的に [https://www.phoronix.com/news/AMDVLK-2021.Q2.6 pre-Polaris] および [https://www.phoronix.com/news/Mesa-24.0-Faster-RADV-Vega Vega] のサポートを終了しています。もしあなたの GPU のサポートが{{Pkg|amdvlk}} から削除された場合は、[[アンインストール]] して、{{Pkg|vulkan-radeon}} を[[インストール]]してください。

=== Bcachefs ルートで32ビットアプリケーションがドライバを見つけられない ===

Bcachefs には32ビットプログラムとの互換性の問題があり、このファイルシステムをルートとして使用している場合、Vulkan ICD ローダーがドライバを見つけることができなくなります([[Bcachefs#32-bit programs cannot see directory contents]])

この問題は、検索されるパスの1つに別のファイルシステムをマウントし、そのデータをコピーすることで回避できます。

{{Warning|マウントされたファイルシステムはそのディレクトリをオーバーレイし、元の内容を Pacman やあなたが読み書きできないようにします。{{ic|/usr/share/vulkan}} 上にマウントしないでください。パッケージの変更や更新はマウントされたファイルシステム内のファイルのみを変更するため、アンマウント時に破損を引き起こす可能性があります。}}

# mkdir -p /usr/local/share/vulkan
# mount -t tmpfs foo /usr/local/share/vulkan
# cp -r /usr/share/vulkan/* /usr/local/share/vulkan

Vulkan

2025-12-04T08:57:07Z

N: /* インストール */

[[Category:グラフィックス]]
[[Category:開発]]
[[en:Vulkan]]
[[pt:Vulkan]]
[[ru:Vulkan]]
[[zh-hans:Vulkan]]
[[Wikipedia:ja:Vulkan]] より:
:Vulkanは、低オーバーヘッドのクロスプラットフォーム3DグラフィックスおよびコンピュートAPIです。2016年に初めてリリースされ、[[OpenGL]] の後継として登場しました。

詳しくは [https://www.khronos.org/vulkan/ Khronos] のウェブサイトを参照してください。

== インストール ==

{{Note|[[ハイブリッドグラフィック]] ([[NVIDIA Optimus]]/AMD Dynamic Switchable Graphics) の場合:
* Vulkan は [[Bumblebee]] で公式ではサポートされていません。[https://github.com/Bumblebee-Project/Bumblebee/issues/769] を見てください。しかし、{{Pkg|primus_vk}} により動作します。
* Radeon の Vulkan ドライバーは [[PRIME]] をサポートしています。[https://www.phoronix.com/scan.php?page=news_item&px=RADV-PRIME-Lands] を参照。
}}

Vulkan アプリを実行するには {{pkg|vulkan-icd-loader}} と (32ビットのアプリケーションを実行したい場合は {{pkg|lib32-vulkan-icd-loader}} も)、使用しているグラフィックカードの Vulkan ドライバーを[[インストール]]する必要があります:

* [[AMD]]: {{Pkg|vulkan-radeon}} (または {{Pkg|lib32-vulkan-radeon}})
* [[Intel]]: {{Pkg|vulkan-intel}} (または {{Pkg|lib32-vulkan-intel}})
* [[NVIDIA]]: 二種類の実装があります。
** {{Pkg|nvidia-utils}}(または {{Pkg|lib32-nvidia-utils}}) - NVIDIA製(プロプライエタリ)
** {{Pkg|vulkan-nouveau}}(または {{Pkg|lib32-vulkan-nouveau}}) - NVK(Mesaプロジェクトの一部){{Note|NVKを有効にするには、追加のシステム設定が必要です。詳細については、[[Nouveau#Using the Mesa NVK Vulkan Driver]] をご覧ください。}}

以下はソフトウェアラスタライザーで、Vulkanサポートを提供しないデバイスで使用することができます。

* '''Lavapipe''': {{Pkg|vulkan-swrast}}(または {{Pkg|lib32-vulkan-swrast}})
* '''SwiftShader''': {{AUR|swiftshader-git}}

Vulkan アプリケーション開発には、{{Pkg|vulkan-headers}} を[[インストール]]し、オプションで {{Pkg|vulkan-validation-layers}}、{{AUR|vulkan-man-pages}}、および {{Pkg|vulkan-tools}} をインストールできます(vulkaninfo や vkcube ツールが含まれています)

== 検証 ==

システムに現在インストールされている Vulkan 実装を確認するには、次のコマンドを使用します。

$ ls /usr/share/vulkan/icd.d/

Vulkan がハードウェアで動作していることを確認するには、{{Pkg|vulkan-tools}} を[[インストール]]し、{{ic|vulkaninfo}} を使って関連情報をシステムから抜き出します。グラフックスカードの情報を手に入れれば、Vulkan が動作していることを知ることができます。

$ vulkaninfo

さらなる情報は https://linuxconfig.org/install-and-test-vulkan-on-linux で見ることができます。

== 切り替え ==

=== デバイス間の切り替え ===

複数の GPU を搭載したシステムでは、特定の GPU の使用を強制する必要がある場合があります。これを動作させるには、{{Pkg|vulkan-mesa-layers}} が必要です。{{ic|MESA_VK_DEVICE_SELECT}} を {{ic|''vendorID:deviceID''}} に設定することで、希望する GPU を選択できます。

候補を一覧表示するには、以下のコマンドを使用します:

$ MESA_VK_DEVICE_SELECT=list vulkaninfo

指定した値の末尾に {{ic|!}} を付けることで、この動作を強制することができます。詳細については、[https://docs.mesa3d.org/envvars.html#vulkan-mesa-device-select-layer-environment-variables Vulkan mesa device select layer environment variables] を参照してください。

=== AMD ドライバを切り替える ===

AMD のシステム上では、一度に複数の Vulkan ドライバをインストールすることができます。なので、それらを切り替えたい場合があります。

==== 環境変数で選択する ====

{{Note|この方法は AMDVLK クローズドドライバの選択をサポートしません。}}

{{Pkg|amdvlk}} 2021.Q3.4 以降、新しい切り替えロジックが実装されました。これにより、AMDVLK がデフォルトとなり、以下のいずれかを行う必要があります:

* {{ic|1=AMD_VULKAN_ICD=RADV}} を設定し、AMDVLK のデフォルトから他のものに切り替える。
* あるいは、グローバルに {{ic|1=DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1=1}} を設定し、以下の ICD ローダの方法を再有効化する。

{{ic|1=DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1=1}} が設定されると、{{ic|VK_ICD_FILENAMES}} 環境変数を設定することによりドライバを選択することができます。例えば、[[Steam]] を RADV ドライバで実行するようにするには:

$ VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.i686.json:/usr/share/vulkan/icd.d/radeon_icd.x86_64.json steam

32 ビットのゲームのクラッシュを回避するために、32 ビット版と 64 ビットを環境変数に割り当てることができます。

==== AMD Vulkan Prefixes で選択する ====

[https://gitlab.com/AndrewShark/amd-vulkan-prefixes AMD Vulkan Prefixes] は3つの Vulkan 実装を切り替えるためのスクリプトです。{{AUR|amd-vulkan-prefixes}} を[[インストール]]し、アプリケーションの前にお望みの接頭辞を付けてください。提供される実行ファイルは {{ic|vk_radv}}、{{ic|vk_amdvlk}}、そして {{ic|vk_pro}} です。例えば、AMDVLK クローズドドライバを使用するには:

$ vk_pro ''command''

== ソフトウェアレンダリング ==

ソフトウェア Vulkan ラスタライザーとして知られる lavapipe をインストールすることができます。例えば、ハードウェアの問題をデバッグするために使用します: {{Pkg|vulkan-swrast}} (または32ビット版の {{Pkg|lib32-vulkan-swrast}})

以下の例は、必要な環境変数を設定して、Vulkan と [[OpenGL#Mesa|OpenGL]] の完全なソフトウェアレンダリングを強制するために ''vulkaninfo'' を実行する方法を示しています ({{ic|1=__GLX_VENDOR_LIBRARY_NAME=mesa}} により、コマンドが [[PRIME]] ユーザーにも動作するようになります):

$ LIBGL_ALWAYS_SOFTWARE=1 __GLX_VENDOR_LIBRARY_NAME=mesa VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.i686.json:/usr/share/vulkan/icd.d/lvp_icd.x86_64.json vulkaninfo

== Vulkan ハードウェアデータベース ==

[https://vulkan.gpuinfo.org/ Vulkan Hardware Database] には、ユーザーが報告した GPU/ドライバーの組み合わせが提供されています。独自の情報を指定するには、{{AUR|vulkan-caps-viewer-wayland}} または {{AUR|vulkan-caps-viewer-x11}} を使用します。

== トラブルシューティング ==

=== NVIDIA - vulkanが動作しない、または初期化できない ===

==== 環境変数 ====

無効または矛盾する[[環境変数]]の値が原因で、Vulkan が失敗することがあります。不適切な値は、複数の GPU が搭載されたマシンで意図した GPU ではなく別の GPU を使用する原因となることもあります。環境変数を適切に設定することで、[https://bbs.archlinux.org/viewtopic.php?pid=2152232#p2152232 必要ないときにセカンダリ GPU を電源オフにする]のにも役立ちます。

==== GPU の切り替え ====

マシンに複数の GPU が搭載されていて、Vulkan がそのうちの1つを認識できない場合、その GPU が BIOS/UEFI やカーネルで無効にされていないことを確認してください。GPU 間の切り替え方法の概要については [[NVIDIA Optimus]] を参照してください。

現在の状態を確認するための例コマンド({{aur|optimus-manager-git}} を使用):

{{hc|$ optimus-manager --status|
Optimus Manager (Client) version 1.4

Current GPU mode : nvidia
GPU mode requested for next login : no change
GPU at startup : integrated
Temporary config path: no
}}

==== GSPファームウェア ====

[https://download.nvidia.com/XFree86/Linux-x86_64/555.42.02/README/gsp.html GSP ファームウェア]は、2024年6月にリリースされた NVIDIA ドライバのバージョン555以降、デフォルトで有効になっており、[https://bbs.archlinux.org/viewtopic.php?pid=2181317 Vulkan の失敗やシステムクラッシュを含むさまざまな問題]の原因として知られています。

これを無効にするには、{{ic|1=NVreg_EnableGpuFirmware=0}} [[モジュールパラメータ]]を{{ic|nvidia}}カーネルモジュールに設定します。これは独自の NVIDIA ドライバでのみ機能します:オープンソースドライバから切り替える場合は[[NVIDIA#インストール]] を参照してください。

必要に応じて [[initramfs の再生成]] を行うことを忘れないでください。この新しいカーネルモジュールオプションを有効にするには、再起動が必要です。

=== No device for the display GPU found. Are the intel-mesa drivers installed? ===

環境変数 VK_ICD_FILENAMES に intel_icd と primus_vk_wrapper の両方のセットしてみてください。

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_icd.x86_64.json:/usr/share/vulkan/icd.d/primus_vk_wrapper.json

=== AMDGPU - vulkaninfo 後に ERROR_INITIALIZATION_FAILED ===

GCN1 または GCN2 ファミリの AMD カードで {{ic|vulkaninfo}} を実行した後、次のようなエラーメッセージが表示された場合:
{{bc|ERROR at /build/vulkan-tools/src/Vulkan-Tools-1.2.135/vulkaninfo/vulkaninfo.h:240:vkEnumerateInstanceExtensionProperties failed with ERROR_INITIALIZATION_FAILED}}
次に、このモデルのグラフィックスカードのサポートが正しく有効になっているかどうかを確認します ([[AMDGPU#Southern Islands (SI) と Sea Islands (CIK) のサポートを有効化]])

GPU ドライバーが正しくロードされているかどうかを確認する方法の 1 つは、{{ic|lspci -k}} です。このコマンドを実行した後、GPU のカーネルドライバーを確認してください。{{ic|amdgpu}} である必要があります。

{{hc|$ lspci -k|
...
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM]
Subsystem: Gigabyte Technology Co., Ltd Device 226c
Kernel driver in use: amdgpu
Kernel modules: radeon, amdgpu
...
}}

この問題に関するいくつかのフォーラムスレッド: [https://bbs.archlinux.org/viewtopic.php?id=254015] [https://bbs.archlinux.org/viewtopic.php?id=253843]

=== AMDGPU - DirectX Vulkan ゲームのプレイ中にがハングする ===

DirectX Vulkan を使用して一部のゲームをプレイすると、Radeon-Vulkan がドライバーや GPU のハングを引き起こすようです。

{{bc|
kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!
kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled ..., emitted ...
kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process ... pid ... thread dxvk-submit pid
...
}}

AMDVLK に切り替えるか有効にすると、問題が解決されるようです。

=== AMDGPU - DirectX Vulkan ゲームでクラッシュする ===

AMDVLK は複数のユーザーによるクラッシュを引き起こすと報告されています ([https://bbs.archlinux.org/viewtopic.php?id=284118 BBS#284118]、[https://bbs.archlinux.org/viewtopic.php? id=283008 BBS#283008]、[https://bbs.archlinux.org/viewtopic.php?id=274737 BBS#274737]): Radeon-Vulkan ドライバーに切り替えるか有効にすると、問題が解決します。

=== AMDGPU - Vulkan アプリケーションの起動が遅い ===

{{Pkg|cuda}} をインストールすると、例えば Chromium などの Vulkan アプリケーションの起動が遅いことがあります。これは、{{Pkg|nvidia-utils}} が Vulkan ドライバを提供しており、Vulkan が最初に nvidia ドライバを試み、その後に radeon ドライバを試すためです。これを解決するには、[[環境変数]] {{ic|VK_DRIVER_FILES}} を {{ic|/usr/share/vulkan/icd.d/radeon_icd.i686.json:/usr/share/vulkan/icd.d/radeon_icd.x86_64.json}} に設定します。

=== AMDGPU - Found no drivers! ===

{{ic|Found no drivers!}} に遭遇した場合:

{{hc|$ vulkaninfo|
WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Failed to CreateInstance in ICD 0. Skipping ICD.
ERROR: [Loader Message] Code 0 : terminator_CreateInstance: Found no drivers!
Cannot create Vulkan instance.
This problem is often caused by a faulty installation of the Vulkan driver or attempting to use a GPU that does not support Vulkan.
ERROR at /usr/src/debug/vulkan-tools/Vulkan-Tools-1.3.269/vulkaninfo/./vulkaninfo.h:688:vkCreateInstance failed with ERROR_INCOMPATIBLE_DRIVER
}}

AMD は定期的に [https://www.phoronix.com/news/AMDVLK-2021.Q2.6 pre-Polaris] および [https://www.phoronix.com/news/Mesa-24.0-Faster-RADV-Vega Vega] のサポートを終了しています。もしあなたの GPU のサポートが{{Pkg|amdvlk}} から削除された場合は、[[アンインストール]] して、{{Pkg|vulkan-radeon}} を[[インストール]]してください。

=== Bcachefs ルートで32ビットアプリケーションがドライバを見つけられない ===

Bcachefs には32ビットプログラムとの互換性の問題があり、このファイルシステムをルートとして使用している場合、Vulkan ICD ローダーがドライバを見つけることができなくなります([[Bcachefs#32-bit programs cannot see directory contents]])

この問題は、検索されるパスの1つに別のファイルシステムをマウントし、そのデータをコピーすることで回避できます。

{{Warning|マウントされたファイルシステムはそのディレクトリをオーバーレイし、元の内容を Pacman やあなたが読み書きできないようにします。{{ic|/usr/share/vulkan}} 上にマウントしないでください。パッケージの変更や更新はマウントされたファイルシステム内のファイルのみを変更するため、アンマウント時に破損を引き起こす可能性があります。}}

# mkdir -p /usr/local/share/vulkan
# mount -t tmpfs foo /usr/local/share/vulkan
# cp -r /usr/share/vulkan/* /usr/local/share/vulkan

AMDGPU

2025-11-30T09:15:14Z

N: /* インストール */

[[Category:グラフィックス]]
[[Category:X サーバー]]
[[de:AMDGPU]]
[[en:AMDGPU]]
[[zh-hans:AMDGPU]]
{{Related articles start}}
{{Related|ATI}}
{{Related|Xorg}}
{{Related|Vulkan}}
{{Related|AMDGPU PRO}}
{{Related articles end}}

[[Wikipedia:AMDGPU|AMDGPU]] は [[wikipedia:ja:Graphics_Core_Next|Graphics Core Next]] ファミリの AMD Radeon グラフィックカード向けのオープンソースグラフィックドライバです。

== 適切なドライバーの選択 ==

お持ちのカードに応じて、[[Xorg#AMD]] で適切なドライバーを見つけてください。このドライバは [https://www.x.org/wiki/RadeonFeature/ Southern Islands] (GCN 1。2012年リリース。) 及びそれ以降のカードをサポートしています。AMD には GCN より前の GPU をサポートする計画はありません。

サポートされない GPU については、オープンソースの [[ATI]] ドライバを使用できます。

== インストール ==

{{Pkg|mesa}} パッケージを[[インストール]]してください。これには、3D アクセラレーションのための DRI ドライバーと、[[#ビデオアクセラレーション|動画デコードのアクセラレーション]]のための VA-API/VDPAU ドライバの両方が含まれています。

* 32ビットアプリケーションのサポートに関しては、[[multilib]] リポジトリから {{Pkg|lib32-mesa}} パッケージもインストールしてください。
* ([[Xorg]] での 2D アクセラレーションを提供する) DDX ドライバに関しては、{{Pkg|xf86-video-amdgpu}} パッケージをインストールすることで利用可能です。デフォルトの modesetting ドライバが存在するため、このパッケージは必要ありません。
* [[Vulkan]]をサポートするには、{{Pkg|vulkan-radeon}} (32ビットアプリケーションの場合は {{Pkg|lib32-vulkan-radeon}}) をインストールしてください。

=== 試験的 ===

一部のユーザーにとっては、mesa の上流の試験的ビルドを使用する価値があるかもしれません。

{{AUR|mesa-git}} パッケージをインストールしてください。これは 3D アクセラレーション用の DRI ドライバーを提供します。

* 32 ビットアプリケーションのサポートに関しては、''mesa-git'' リポジトリ、または [[AUR]] から {{AUR|lib32-mesa-git}} もインストールしてください。
* ([[Xorg]] で 2D アクセラレーションを提供する) DDX ドライバに関しては、{{AUR|xf86-video-amdgpu-git}} パッケージをインストールしてください。
* ''mesa-git'' リポジトリを使用する [[Vulkan]] サポートに関しては、''vulkan-radeon-git'' パッケージをインストールしてください。任意で、32 ビットアプリケーションをサポートするために ''lib32-vulkan-radeon-git'' パッケージもインストールしてください。AUR から {{AUR|mesa-git}} をビルドする場合、これは必要ないはずです。

{{Tip|{{AUR|mesa-git}} パッケージのコンパイルを行いたくない場合は、[[非公式ユーザーリポジトリ#mesa-git|mesa-git]] 非公式リポジトリを使用できます。}}

=== Southern Islands (SI) と Sea Islands (CIK) のサポートを有効化 ===

[[カーネル#公式サポートカーネル|公式サポートカーネル]]では、Southern Islands (GCN 1。2012年リリース。) 及び Sea Islands (GCN 2。2013年リリース。) のカードの AMDGPU サポートが有効化されています。{{ic|amdgpu}} カーネルドライバは [[ATI|radeon]] ドライバより前にロードされる必要があります。どのカーネルドライバがロードされているかは {{ic|lspci -k}} で確認できます。以下のように出力されるはずです:

{{hc|$ lspci -k -d ::03xx|
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM]
Subsystem: Gigabyte Technology Co., Ltd Device 226c
Kernel driver in use: amdgpu
Kernel modules: radeon, amdgpu
}}

{{ic|amdgpu}} ドライバが使用されていない場合、次のセクションの指示に従ってください。

==== amdgpu ドライバをロード ====

{{ic|amdgpu}} モジュールと {{ic|radeon}} モジュールの両方の[[モジュールパラメータ]]は {{ic|1=cik_support=}} と {{ic|1=si_support=}} です。

これらは、カーネルパラメータまたは ''modprobe'' 設定ファイルで設定する必要があり、カードの GCN バージョンによって異なります。

どのカーネルカードを使用しているか不確かな場合は、両方のパラメータを使うことができます。

{{Tip|[[dmesg]] は、使用すべき正しい方のカーネルパラメータを示してくれる場合があります: {{ic|1=[..] amdgpu 0000:01:00.0: Use radeon.cik_support=0 amdgpu.cik_support=1 to override}}}}

===== カーネルコマンドラインでモジュールパラメータを設定 =====

次のいずれかの[[カーネルパラメータ]]を設定してください:

* Southern Islands (SI): {{ic|1=radeon.si_support=0 amdgpu.si_support=1}}
* Sea Islands (CIK): {{ic|1=radeon.cik_support=0 amdgpu.cik_support=1}}

さらに、統合 Sea Island (GCN 1.1) カードと AMD A10 APU を使用する場合、正しくブートさせるには Radeon Dynamic Power Management を無効化しておく必要がある場合があります。この機能には、グラフィックコアのクロックを動的に調整することで、APU の温度を下げ、静音性を高める目的があります。しかし、この機能のせいで再起動の無限ループに陥ることがあります。無効化するには、上記の手順に従い、{{ic|1=radeon.dpm=0}} をブートオプションに追加してください。

==== 正しいモジュール順序を指定 ====

{{ic|amdgpu}} が [[Mkinitcpio#MODULES]] 配列の1番目のモジュールとして設定されていることを確認してください。例えば、{{ic|1=MODULES=(amdgpu radeon)}}。

===== カーネルモジュールパラメータを設定 =====

Southern Islands (SI) の場合は {{ic|1=si_support=1}} [[カーネルモジュールパラメータ]]を、Sea Islands (CIK) の場合は {{ic|1=cik_support=1}} を使用してください:

{{hc|/etc/modprobe.d/amdgpu.conf|2=
options amdgpu si_support=1
options amdgpu cik_support=1
}}

{{hc|/etc/modprobe.d/radeon.conf|2=
options radeon si_support=0
options radeon cik_support=0
}}

{{ic|modconf}} が {{ic|/etc/mkinitcpio.conf}} の {{ic|HOOKS}} 配列にあることを確認し、[[Initramfs を再生成する|initramfs を再生成]]してください。

===== amdgpu ドライバをサポートするカーネルをコンパイル =====

[[カーネル]]をビルド/コンパイルする場合、{{ic|1=CONFIG_DRM_AMDGPU_SI=Y}} と {{ic|1=CONFIG_DRM_AMDGPU_CIK=Y}} の一方/両方を config で設定する必要があります。

=== ACO コンパイラ ===

[https://steamcommunity.com/games/221410/announcements/detail/1602634609636894200 ACO コンパイラ]はオープンソースのシェーダコンパイラであり、[https://llvm.org/ LLVM コンパイラ]や [https://github.com/GPUOpen-Drivers/AMDVLK AMDVLK ドライバ]、[[wikipedia:ja:Microsoft Windows 10|Windows 10]] に直接対抗するために [[wikipedia:ja:Valve Corporation|Valve Corporation]] によって作成・開発されています。LLVM と AMDVLK よりも短いコンパイル時間と、ゲームでのより良いパフォーマンスを提供します。

いくつかのベンチマークは [https://gist.github.com/pendingchaos/aba1e4c238cf039d17089f29a8c6aa63 GitHub] や Phoronix [https://www.phoronix.com/scan.php?page=article&item=radv-aco-llvm&num=1 (1)] [https://www.phoronix.com/scan.php?page=article&item=radv-aco-gcn10&num=1 (2)] [https://www.phoronix.com/scan.php?page=article&item=mesa20radv-aco-amdvlk&num=1 (3)] で見られます。

{{Pkg|mesa}} バージョン [https://docs.mesa3d.org/relnotes/20.2.0.html#new-features 20.2] から、ACO はデフォルトのシェーダコンパイラとなっています。

== ロード ==

{{ic|amdgpu}} カーネルモジュールはシステムの起動時に自動的にロードされることになっています。

ロードされない場合:

* 必要な場合は [[#Southern Islands (SI) と Sea Islands (CIK) のサポートを有効化]]していることを確認してください。
* 最新の {{Pkg|linux-firmware-amdgpu}} パッケージがインストールされていることを確認してください。このドライバは、正しくブートするために各モデルの最新のファームウェアを必要とします。
* [[カーネルパラメータ]]に {{ic|nomodeset}} や {{ic|1=vga=}} を指定して'''いない'''ことを確認してください。{{ic|amdgpu}} は [[KMS]] を必要とするからです。
* [[カーネルモジュール#ブラックリスト|カーネルモジュールのブラックリスト]]で {{ic|amdgpu}} が無効になっていないことを確認してください。

読み込むことはできるが、X サーバが必要とする時よりも後になってしまう場合、[[カーネルモード設定#KMS の早期開始]] を見てください。

== Xorg の設定 ==

[[Xorg]] は自動的にドライバをロードし、モニタの EDID を使ってネイティブの解像度を設定してくれます。設定が必要になるのは、ドライバをチューニングする場合のみです。

手動で設定したい場合、{{ic|/etc/X11/xorg.conf.d/20-amdgpu.conf}} を作成して、以下を記述してください:

{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|2=
Section "OutputClass"
Identifier "AMD"
MatchDriver "amdgpu"
Driver "amdgpu"
EndSection
}}

このセクションを使って、機能を有効化したりドライバの設定を調整したりできます。ドライバオプションを設定する前に、まず {{man|4|amdgpu}} を見てください。

=== TearFree レンダリング ===

''TearFree'' は、ハードウェアのページフリッピング機構を使ってティアリング防止を制御します。デフォルトでは、TearFree は、回転された出力、RandR 変換が適用された出力、RandR 1.4 スレーブ出力に対してオンになり、それら以外ではオフになります。{{ic|true}} か {{ic|false}} を指定することで、常にオンにしたり、常にオフにしたりもできます。

Option "TearFree" "true"

[[xrandr]] を使用して TearFree を一時的に有効にすることもできます:

$ xrandr --output ''output'' --set TearFree on

{{ic|''output''}} は {{ic|DisplayPort-0}} や {{ic|HDMI-A-0}} のような形式である必要があります。この値は {{ic|xrandr -q}} で取得できます。

=== DRI レベル ===

''DRI'' は、有効にする DRI の最大レベルを設定します。有効な値は、DRI2 の場合は ''2''、 DRI3 の場合は ''3'' です。 [[Xorg]] バージョンが 1.18.3 以降の場合、DRI3 のデフォルトは ''3'' です。それ以外の場合、 DRI2 が使用されます:

Option "DRI" "3"

=== 可変リフレッシュレート ===

[[可変リフレッシュレート]] を参照してください。

=== 10 ビットカラー ===

{{Warning|10 ビットカラーを有効化すると、多くのアプリケーションでグラフィックの乱れやクラッシュを引き起こす場合があります。これには特に [[Steam/トラブルシューティング#Steam: An X Error occurred|Steam]] が含まれ、X Error によりクラッシュします。}}

新しい AMD カードは 10bpc カラーをサポートしていますが、デフォルトは 24 ビットカラーであり、30 ビットカラーは明示的に有効にする必要があります。アプリケーションがこれもサポートしている場合、これを有効にすると、グラデーションの目に見えるバンディング/グラフィックの乱れを減らすことができます。モニターがサポートしているかどうかを確認するには、[[Xorg#一般|Xorg ログファイル]]で ''EDID'' を検索してください (例:{{ic|/var/log/Xorg.0.log}} または {{ic|~/.local/share/xorg/Xorg.0.log}}):

[ 336.695] (II) AMDGPU(0): EDID for output DisplayPort-0
[ 336.695] (II) AMDGPU(0): EDID for output DisplayPort-1
[ 336.695] (II) AMDGPU(0): Manufacturer: DEL Model: a0ec Serial#: 123456789
[ 336.695] (II) AMDGPU(0): Year: 2018 Week: 23
[ 336.695] (II) AMDGPU(0): EDID Version: 1.4
[ 336.695] (II) AMDGPU(0): Digital Display Input
'''[ 336.695] (II) AMDGPU(0): 10 bits per channel'''

現在有効になっているかどうかを確認するには、''Depth'' を検索してください:

[ 336.618] (**) AMDGPU(0): Depth 30, (--) framebuffer bpp 32
[ 336.618] (II) AMDGPU(0): Pixel depth = 30 bits stored in 4 bytes (32 bpp pixmaps)

デフォルトの設定では、24 であると表示されます (24 ビットが 4 バイトに格納されている)。

10ビットが機能するかどうかを確認するには、Xorg を実行している場合は終了し、白黒の縞模様を表示する {{ic|Xorg -retro}} を実行し、{{ic|Ctrl-Alt-F1}} と {{ic|Ctrl-C}} を押して X を終了し、{{ic|Xorg -depth 30 -retro}} を実行してください。これが正常に機能する場合は、10ビットが機能しています。

{{ic|startx}} を介して10ビットで起動するには、{{ic|startx -- -depth 30}} を使用してください。永続的に有効にするには、以下を作成または追加してください:

{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|2=
Section "Screen"
Identifier "asdf"
DefaultDepth 30
EndSection
}}

=== 出力のレイテンシを減らす ===

レイテンシを最小化したい場合、ページフリッピングや TearFree を無効化できます:

{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|2=
Section "OutputClass"
Identifier "AMD"
MatchDriver "amdgpu"
Driver "amdgpu"
Option "EnablePageFlip" "off"
Option "TearFree" "false"
EndSection
}}

レイテンシを更に減らしたい場合は [[ゲーム#DRI の遅延を軽減する]] を見てください。

{{Note|これらのオプションを設定すると、ティアリングや短時間のアーティファクトが発生する場合があります。}}

== 機能 ==

=== ビデオアクセラレーション ===

[[ハードウェアビデオアクセラレーション#AMD/ATI]] を見てください。

=== モニタリング ===

GPU の温度や P-state を確認したい場合に GPU のモニタリングはしばしば行われます。

==== CLI ====

* {{App|amdgpu_top|AMDGPU の使用率を表示するツール|https://github.com/Umio-Yasuno/amdgpu_top|{{Pkg|amdgpu_top}}}}
* {{App|nvtop|AMD、Intel、NVIDIA で GPU プロセスをモニタリングします。|https://github.com/Syllo/nvtop|{{Pkg|nvtop}}}}
* {{App|radeontop|合計のアクティビティ率と個々のブロック両方の GPU 使用率ビュアー。|https://github.com/clbr/radeontop|{{Pkg|radeontop}}}}

==== GUI ====

* {{App|amdgpu_top|AMDGPU の使用率を表示するツール|https://github.com/Umio-Yasuno/amdgpu_top|{{Pkg|amdgpu_top}}}}
* {{App|AmdGuid|完全に Rust で書かれた、基本的なファンコントロール GUI。|https://github.com/Eraden/amdgpud|{{AUR|amdguid-wayland-bin}}, {{AUR|amdguid-glow-bin}}}}
* {{App|Radeon Profile|AMD Radeon カードの現在のクロックを読み込んだり変更したりする Qt5 ツール。|https://github.com/emerge-e-world/radeon-profile|{{AUR|radeon-profile-git}}}}
* {{App|TuxClocker|Qt5 のモニタリング・オーバークロックツール。|https://github.com/Lurkki14/tuxclocker|{{AUR|tuxclocker}}}}

==== 手動 ====

GPU の P-state を確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/pp_od_clk_voltage

GPU をモニタリングするには、以下を実行:

# watch -n 0.5 cat /sys/kernel/debug/dri/0/amdgpu_pm_info

GPU 使用率を確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/gpu_busy_percent

GPU のクロックを確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/pp_dpm_sclk

GPU 温度を確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/hwmon/hwmon*/temp1_input

VRAM のクロックを確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/pp_dpm_mclk

VRAM の使用率を確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/mem_info_vram_used

VRAM のサイズを確認するには、以下を実行:

$ cat /sys/class/drm/card0/device/mem_info_vram_total

=== オーバークロック ===

Linux 4.17 以降、以下の機能をブート時に有効化すると、{{Ic|1=/sys/class/drm/card0/device/pp_od_clk_voltage}} を介してグラフィックカードのクロックと電圧を調整できるようになります。

==== ブートパラメータ ====

{{Ic|1=amdgpu.ppfeaturemask=0xffffffff}} [[カーネルパラメータ]] を追加して、sysfs でクロックと電圧を調整するアクセスをアンロックする必要があります。

すべてのビットが定義されているわけではありません。今後、新しい機能が追加されるかもしれません。32ビットすべてを設定すると、不安定な機能が有効化され、画面のチラツキやサスペンドからの復帰に失敗するなどの問題が発生する場合があります。デフォルトの ppfeaturemask と共に PP_OVERDRIVE_MASK ビット (0x4000) を設定すれば十分なはずです。あなたのシステムにおいて適切なパラメータを計算するには、以下を実行してください:

$ printf 'amdgpu.ppfeaturemask=0x%x\n' "$(($(cat /sys/module/amdgpu/parameters/ppfeaturemask) | 0x4000))"

==== 手動 ====

{{Note|sysfs では、{{ic|/sys/class/drm/...}} のようなパスはただのシンボリックリンクで、起動するごとに変化するかもしれません。永続的なパスは {{ic|/sys/devices/}} にあります (例: {{ic|/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/}})。信頼性の高い結果を得るには、コマンドを適宜調整してください。}}

利用可能なオプションに関する詳細は、カーネルドキュメントの [https://docs.kernel.org/gpu/amdgpu/thermal.html#pp-od-clk-voltage amdgpu サーマルコントロール]に関する部分を読んでください。

手動オーバークロックを有効にするには、[[#パフォーマンスレベル]] で説明されているように {{ic|manual}} パフォーマンスレベルを選択してください。

例えば、Polaris GPU で最大 P-state 7 で GPU クロックを 1209MHz、電圧を 900mV に設定するには、以下を実行してください:

# echo "s 7 1209 900" > /sys/class/drm/card0/device/pp_od_clk_voltage

同じ手順を VRAM に対しても適用できます (例えば、Polaris 5xx シリーズカードでの最大 P-state 2):

# echo "m 2 1850 850" > /sys/class/drm/card0/device/pp_od_clk_voltage

{{Warning|入力した値をダブルチェックしてください。間違うと即座にハードウェアに深刻なダメージを引き起こすかもしれません!}}

適用するには:

# echo "c" > /sys/class/drm/card0/device/pp_od_clk_voltage

機能していることを確認するには、3D の負荷をかけている状態で、クロックと電圧を見てください:

# watch -n 0.5 cat /sys/kernel/debug/dri/0/amdgpu_pm_info

以下でデフォルトの値にリセットできます:

# echo "r" > /sys/class/drm/card0/device/pp_od_clk_voltage

例えば、超省電力 P-state における (画面のちらつきやカクつきなどの) 問題を回避した場合などは、ドライバが特定の P-state へ切り替えるのを禁止することも可能です。最も高い VRAM P-state を強制し、GPU 自体は引き続き低いクロックで動作できるようにするには、まず利用可能な最も高い P-state を調べ、それを設定してください:

{{hc|$ cat /sys/class/drm/card0/device/pp_dpm_mclk|
0: 96Mhz *
1: 456Mhz
2: 675Mhz
3: 1000Mhz
}}

# echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level
# echo "3" > /sys/class/drm/card0/device/pp_dpm_mclk

上位3つの GPU P-state のみを許可するには:

# echo "5 6 7" > /sys/class/drm/card0/device/pp_dpm_sclk

GPU の最大電力消費量を設定するには (例えば 50 ワット):

# echo '''50'''000000 > /sys/class/drm/card0/device/hwmon/hwmon0/power1_cap

{{Note|上記の手順は Polaris RX 560 カードでテストされました。別の GPU では、異なる挙動やバグが存在するかもしれません。}}

==== アシスト付き ====

GPU を手動でオーバークロックしたくない場合、AMD GPU のオーバークロックやモニタリングをアシストするいくつかのツールがコミュニティによって提供されています。

===== CLI ツール =====

* {{App|amdgpu-clocks|AMD GPU のモニタリングやカスタムの P-state を設定するために使用できるスクリプト。起動時に自動的に設定を適用する systemd サービスもあります。|https://github.com/sibradzic/amdgpu-clocks|{{AUR|amdgpu-clocks-git}}}}
* {{App|ruby-amdgpu_fan|amdgpu Linux ドライバと対話するための Ruby で書かれた CLI ツール|https://github.com/HarlemSquirrel/amdgpu-fan-rb|{{AUR|ruby-amdgpu_fan}}}}

===== GUI ツール =====

* {{App|TuxClocker|Qt5 のモニタリング・オーバークロックツール|https://github.com/Lurkki14/tuxclocker|{{AUR|tuxclocker}}}}
* {{App|CoreCtrl|アプリケーション毎のプロファイルをサポートする、WattMan ライクな UI の GUI オーバークロックツール。|https://gitlab.com/corectrl/corectrl|{{Pkg|corectrl}}}}
* {{App|LACT|AMD GPU の情報を見るための GTK ツール。{{Pkg|power-profiles-daemon}} と競合します。競合を防ぐには {{ic|amdgpu_dpm}} を後で無効化してください。[https://github.com/ilya-zlobintsev/LACT?tabreadme-ov-file#power-profiles-daemon-note]|https://github.com/ilya-zlobintsev/LACT|{{Pkg|lact}}}}
* {{App|Radeon Profile|AMD Radeon カードの現在のクロックを読み込んだり変更したりする Qt5 ツール。|https://github.com/emerge-e-world/radeon-profile|{{AUR|radeon-profile-git}}}}

==== ブート時のスタートアップ ====

方法としては、一つは systemd ユニットを使うことです。起動時に設定を自動的に適用したい場合、起動時に設定を構成・適用することに関するこの [https://www.reddit.com/r/Amd/comments/agwroj/how_to_overclock_your_amd_gpu_on_linux/ Reddit スレッド]を見てみることを検討してください。

もう一つの方法は udev ルールです。例えば、パフォーマンスレベルを落とす値を設定して電力消費量を削減するには:

{{hc|/etc/udev/rules.d/30-amdgpu-low-power.rules|2=
ACTION=="add", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="low"
}}

=== パフォーマンスレベル ===

AMDGPU にはいくつかのパフォーマンスレベルがあります。このレベルは power_dpm_force_performance_level ファイルで調整/確認することができます。以下のレベルから選択できます:

* '''auto''': 現在の条件に合わせて、ドライバー内で最適な電源プロファイルを動的に選択します。
* '''low''': クロック数は最低のパワーステートに強制されます。
* '''high''': クロック数は最高のパワーステートに強制されます。
* '''manual''': ユーザーは、各クロックドメインに対してどのパワーステートを有効化するかを手動で選択することができます ([[#電源プロファイル]]を設定する際に使用します)。
* '''profile_standard'''、'''profile_min_sclk'''、'''profile_min_mclk'''、'''profile_peak''': クロックとパワーのゲーティングが無効化され、クロックはそれぞれのプロファイルに応じて設定されます。このモードは、特定のワークロードに対してプロファイルする際に推奨されます。

以下のコマンドを実行すると、AMDGPU デバイスをパフォーマンスレベル low に設定します:

# echo "low" > /sys/class/drm/card0/device/power_dpm_force_performance_level

{{Note|パフォーマンスレベルは起動のたびに再設定する必要があります。設定を自動化する方法は [[#ブート時のスタートアップ]] を見てください。}}

=== 電源プロファイル ===

AMDGPU は電源プロファイルによるいくつかの最適化を提供します。最も一般的に使用されるのは、OpenCL を多用するアプリケーションのためのコンピュートモードです。利用可能な電源プロファイルは以下のように一覧表示できます:

{{hc|$ cat /sys/class/drm/card0/device/pp_power_profile_mode|
NUM MODE_NAME SCLK_UP_HYST SCLK_DOWN_HYST SCLK_ACTIVE_LEVEL MCLK_UP_HYST MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL
0 BOOTUP_DEFAULT: - - - - - -
1 3D_FULL_SCREEN: 0 100 30 0 100 10
2 POWER_SAVING: 10 0 30 - - -
3 VIDEO: - - - 10 16 31
4 VR: 0 11 50 0 100 10
5 COMPUTE *: 0 5 30 10 60 25
6 CUSTOM: - - - - - -
}}

{{Note|{{ic|card0}} はマシンの特定の GPU を示します。複数の GPU が搭載されている場合、正しい GPU を選ぶように気をつけてください。}}

特定の電源プロファイルを使用するには、まず GPU のマニュアルコントロールを有効化する必要があります:

# echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level

その後、電源プロファイルを選択するには、そのプロファイルと関連付けられた NUM の値を書き込みます。例えば、COMPUTE を有効化するには:

# echo "5" > /sys/class/drm/card0/device/pp_power_profile_mode

{{Note|電源プロファイルの変更は起動するたびに適用する必要があります。これを自動化するには [[#ブート時のスタートアップ]] を見てください。}}

=== GPU ディスプレイスケーリングを有効化 ===

モニタのネイティブ解像度を使用しない場合、ディスプレイに内蔵されているスケーラを用いずに、GPU 自体のスケーラを使うには、以下を実行してください:
$ xrandr --output ''output'' --set "scaling mode" ''scaling_mode''

{{ic|"scaling mode"}} に利用できる値は: {{ic|None}}, {{ic|Full}}, {{ic|Center}}, {{ic|Full aspect}}。

* 利用可能な出力と設定を表示するには: {{bc|$ xrandr --prop}}
* 利用可能な全ての出力に {{ic|1=scaling mode = Full aspect}} を設定するには: {{bc|$ for output in $(xrandr --prop {{!}} grep -E -o -i "^[A-Z\-]+-[0-9]+"); do xrandr --output "$output" --set "scaling mode" "Full aspect"; done}}

=== ヘッドレス環境での仮想ディスプレイ ===

AMDGPU はヘッドレス環境向けに、ダミープラグを使用しない、GPU アクセラレートされた仮想モニターを提供しています。これは RDP や {{AUR|sunshine}} といったゲームストリーミングソフトウェアで便利です。

使用する AMD GPU を選択してください:

{{hc|$ lspci -Dd ::03xx|
'''1234:56:78.9''' VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] ''CommercialModelName''
}}

{{ic|amdgpu}} に対して {{ic|1=virtual_display=''1234:56:78.9'',''x''}} [[カーネルモジュールパラメータ]]を追加してください。{{ic|''1234:56:78.9''}} の部分は GPU の PCI アドレスで、{{ic|''x''}} は公開する crtc (仮想モニター) の番号です。このパラメータを使用すると物理出力は無効化されます。[https://bugzilla.kernel.org/show_bug.cgi?id=203339]

以下のように PCI アドレスをセミコロンで区切ることで、複数の GPU を使用することも可能です:

amdgpu.virtual_display=1234:56:78.9,''x'';9876:54:32.1,''y''

== トラブルシューティング ==

=== モジュールパラメータ ===

amdgpu モジュールは、いくつかの設定パラメータ ({{ic|modinfo amdgpu {{!}} grep mask}}) を[https://raw.githubusercontent.com/torvalds/linux/master/drivers/gpu/drm/amd/include/amd_shared.h カーネルのソースコード]でしかドキュメント化していないマスク内に隠しています。

=== Xorg やアプリケーションが起動しない ===

* ''glxgears'' を開いた後に "(EE) AMDGPU(0): [DRI2] DRI2SwapBuffers: drawable has no back or front?" エラー。Xorg サーバを開くことはできるが、OpenGL アプリケーションはクラッシュする。
* "(EE) AMDGPU(0): Given depth (32) is not supported by amdgpu driver" エラー。Xorg が起動しない。

Xorg でスクリーンの色深度を 16 か 32 に設定すると問題/クラッシュを引き起こします。これを防ぐには、"screen" セクションに以下を追加して標準的なスクリーン色深度である 24 を使う必要があります:

{{hc|/etc/X11/xorg.conf.d/10-screen.conf|
Section "Screen"
Identifier "Screen"
DefaultDepth 24
SubSection "Display"
Depth 24
EndSubSection
EndSection
}}

=== スクリーンのアーティファクトと周波数の問題 ===

[[ATI#動的電源管理|動的電源管理]]は、(60Hz以上の) 高いリフレッシュレートでモニタを表示させた際にスクリーンのアーティファクトを発生させる場合があります。GPU のクロック速度の管理法に問題があるためです [https://bugs.freedesktop.org/show_bug.cgi?id=96868][https://gitlab.freedesktop.org/drm/amd/-/issues/234]。

回避策[https://bugs.freedesktop.org/show_bug.cgi?id=96868#c13]は、[[#パフォーマンスレベル]] で説明されているようにパフォーマンスレベルを {{ic|high}} あるいは {{ic|low}} に設定することです。

カーネルのバージョンを変更することでもこの問題を解決できる場合があります。例えば、バージョン 6.12.9 では問題は解決されているようです。

==== Chromium でアーティファクト ====

[[Chromium]] でアーティファクトが現れる場合、vulkan ベースのバックエンドの使用を強制すると解決するかもしれません。{{ic|chrome://flags}} を開き、{{ic|#ignore-gpu-blocklist}} と {{ic|#enable-vulkan}} を ''enable'' にしてください。

=== R9 390 シリーズで悪いパフォーマンス/不安定 ===

AMD R9 390 シリーズのグラフィックカードで問題[https://gitlab.freedesktop.org/mesa/mesa/-/issues/1222]が発生する場合、次の[[カーネルパラメータ]]を設定して、radeon ではなく amdgpu ドライバの使用を強制してください: {{ic|1=radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1 amdgpu.dc=1}}

これがうまく行かない場合、DPM を無効化すると解決するかもしれません。次を[[カーネルパラメータ]]に追加してください: {{ic|1=radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1}}

=== "[drm] IP block:gmc_v8_0 is hung!" カーネルエラーでフリーズ ===

GPU が大量の処理を行っている最中にフリーズやカーネルのクラッシュが発生して、"[drm] IP block:gmc_v8_0 is hung!" カーネルエラーが発生する場合 [https://gitlab.freedesktop.org/drm/amd/issues/226]、回避策は [[カーネルパラメータ]] {{ic|1=amdgpu.vm_update_mode=3}} を設定して GPUVM ページテーブルの更新を CPU を用いて行うように強制することです。デメリットはここにリストされています: [https://gitlab.freedesktop.org/drm/amd/-/issues/226#note_308665]。

=== 画面が白く/灰色に点滅する ===

解像度を変更したり外部モニタに接続したりしたときに、画面がちらつく、あるいは白くなったままになる場合、[[カーネルパラメータ]] {{ic|1=amdgpu.sg_display=0}} を追加してください。

=== Vega カード上でのゲーム中にシステムのフリーズ/クラッシュ ===

[[ATI#動的電源管理|動的電源管理]]は、ゲーム中にシステムの完全なフリーズを発生させる場合があります。GPU のクロック速度の管理法に問題があるためです [https://gitlab.freedesktop.org/drm/amd/-/issues/716]。回避策は、[[#パフォーマンスレベル]] で説明されているようにパフォーマンスレベルを {{ic|high}} に設定することです。。

=== WebRenderer (Firefox) の破損 ===

[[:en:Firefox/Tweaks#WebRender|WebRenderer]] がユーザによって強制的に有効化されている場合、アーティファクトやその他の異常が発生する場合があります(例: 拡張機能のオプションを選択できないなど)。回避策は OpenGL コンポジットにフォールバックすることです。

=== 4K@60Hz のデバイスが接続されると音声の速度が2倍になる/音が高くなる/無音 ===

これは、AMDGPU デバイスと、HDMI で接続された 4K ディスプレイとの間の通信の問題により時々発生します。利用可能な回避策は、ディスプレイの組み込み設定から HDR か "Ultra HD Deep Color" を有効化することです。多くの Android ベースのテレビでは、これは "Optimal" ではなく "Standard" を設定することを意味します。

=== ディスクリート amdgpu グラフィックカードにおける電源管理/動的再アクティブ化の問題 ===

カーネルドライバはロードされたが、ゲームでディスクリートグラフィックカードを利用できない、または使用中に無効化されてしまう問題が発生する場合 ([https://gitlab.freedesktop.org/drm/amd/-/issues/1820] に似た問題)、[[カーネルパラメータ]] {{ic|1=amdgpu.runpm=0}} を設定することでこの問題を回避できます。このカーネルパラメータは、dGPU が実行時に動的にオフになることを防止します。

=== ディスプレイが固まる、または応答しなくなる (flip_done timed out) ===

amdgpu ドライバのバグにより、ディスプレイが更新されなくなることがあります[https://gitlab.freedesktop.org/drm/amd/-/issues/4141]。回避策として、{{ic|1=amdgpu.dcdebugmask=0x10}} か {{ic|1=amdgpu.dcdebugmask=0x12}} [[カーネルパラメータ]]を追加することが提案されています。

=== kfd: amdgpu: TOPAZ not supported in kfd ===

システムのジャーナルやカーネルメッセージキーリングに以下の critical レベルのエラーメッセージが出力される場合があります:

kfd: amdgpu: TOPAZ not supported in kfd

[[GPGPU#ROCm|Radeon Open Compute]] を使用するつもりでないならば、これは安全に無視できます。古い GPU であるため、TOPAZ ではサポートされていません。[https://github.com/RadeonOpenCompute/ROCm/issues/1148#issuecomment-747849592] [https://www.reddit.com/r/linuxquestions/comments/yhbbiz/kfd_kfd_amdgpu_topaz_not_supported_in_kfd/]

=== MCLK が MAX (1000Mhz) に固定されてアイドル時に高い電力消費、または MIN (96MHz) に固定されてゲームのパフォーマンスが悪化 (カーネル 6.4) ===

高解像度かつ高リフレッシュレートの場合、MCLK (vram / メモリのクロック) が最も高いクロックレート (1000MHz) に固定されてしまい [https://gitlab.freedesktop.org/drm/amd/-/issues/1403] [https://gitlab.freedesktop.org/drm/amd/-/issues/2646]、アイドル時に GPU の電力消費が増加してしまう場合があります。Linux カーネル 6.4.x では、MCLK クロックが最低値 (96MHz) になって、ゲームのパフォーマンスが低下してしまいます [https://gitlab.freedesktop.org/drm/amd/-/issues/2657] [https://gitlab.freedesktop.org/drm/amd/-/issues/2611]。

これは、モニタが Coordinated Video Timings (CVT) を使用しておらず、影響を受ける解像度とリフレッシュレートに対する V-Blank 値が低いことが原因である可能性があります。回避策は[https://gist.github.com/Rend0e/3bddac4285dc1f4fbe303f326f36f6cc この gist] を見てください。

=== Suspend to RAM に失敗する ===

十分にリフレッシュされない VRAM のデータ消失を防ぐために、{{ic|amdgpu}} カーネルモジュールはシステムが S3 スリープに入るときに VRAM の内容を RAM 内に保存します。

大量の VRAM を使用していて RAM に十分な空き容量がない場合、たとえ十分なスワップメモリが存在していたとしても、[https://gitlab.freedesktop.org/drm/amd/-/issues/2125 このプロセスが失敗する可能性があります] (IO サブシステムがすでにサスペンドされているかもしれないため)。

このとき、以下のようなメッセージが出力されます:

kernel: systemd-sleep: page allocation failure: order:0, mode:0x100c02(GFP_NOIO|__GFP_HIGHMEM|__GFP_HARDWALL), nodemask=(null),cpuset=/,mems_allowed=0
kernel: Call Trace:
kernel: <TASK>
kernel: dump_stack_lvl+0x47/0x60
kernel: warn_alloc+0x165/0x1e0
kernel: __alloc_pages_slowpath.constprop.0+0xd7d/0xde0
kernel: __alloc_pages+0x32d/0x350
kernel: ttm_pool_alloc+0x19f/0x600 [ttm 0bd92a9d9dccc3a4f19554535860aaeda76eb4f4]

回避策としては、システムがサスペンドする前に十分な RAM 領域をスワップアウトして VRAM を格納できるのに十分な空き領域を RAM に確保しておく[https://git.dolansoft.org/lorenz/memreserver ユーザー空間のサービス]を使うというものがります。

=== シャットダウンとサスペンドに失敗する ===

カーネルモジュールの ''hid_sensor_*_3d'' グループは、ブート時、シャットダウン時、サスペンド時にシステムがフリーズする問題を引き起こすことがあります。プロセスリストには複数の {{ic|udev-worker}} インスタンスが現れ、システムのスリープ時にフリーズしてしまいます。

このとき、以下のように出力されます:

kernel: PM: suspend entry (deep)
kernel: Filesystems sync: 0.002 seconds
kernel: Freezing user space processes
kernel: Freezing user space processes failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
kernel: task:(udev-worker) state:D stack:0 pid:479 tgid:479 ppid:422 flags:0x00004006
kernel: Call Trace:
kernel: <TASK>
kernel: __schedule+0x3db/0x1520
kernel: ? srso_alias_return_thunk+0x5/0xfbef5
kernel: ? __wake_up_common+0x78/0xa0
kernel: ? srso_alias_return_thunk+0x5/0xfbef5

この問題の回避策は、例えば以下のような {{ic|/etc/modprobe.d/blacklist-hid_sensors.conf}} を作成するなどして、問題のあるモジュールをブラックリスト化することです:

blacklist hid_sensor_accel_3d
blacklist hid_sensor_gyro_3d
blacklist hid_sensor_magn_3d

== 参照 ==

* [[Gentoo:AMDGPU]]
* [https://gitlab.freedesktop.org/drm/amd AMDGPU イシュートラッカー]

{{TranslationStatus|AMDGPU|2025-06-11|838762}}

Btrfs

2025-11-01T00:52:52Z

N: /* 重複排除 */

[[Category:ファイルシステム]]
[[de:Arch auf BtrFS]]
[[en:Btrfs]]
[[es:Btrfs]]
[[pt:Btrfs]]
[[ru:Btrfs]]
[[zh-hans:Btrfs]]
{{Related articles start}}
{{Related|ファイルシステム}}
{{Related|Snapper}}
{{Related|Yabsnap}}
{{Related articles end}}

[https://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs Wiki] より:

:Btrfs は、耐障害性、修復、および簡単な管理に重点を置きながら、高度な機能を実装することを目的とした Linux 用の最新のコピーオンライト(CoW)ファイルシステムです。複数の企業で共同開発された Btrfs は、GPL に基づいてライセンスされており、誰からの寄付も受け付けています。

{{Note|他のファイルシステムと同様に、Btrfs は継続的に開発中です。これは、特定の機能がまだ日常的に使用できる状態になっていない可能性があります。使用事例が影響を受ける可能性があるかどうかを確認するには、Btrfs ドキュメントの [https://btrfs.readthedocs.io/en/latest/Status.html Status] とこの記事の [[Btrfs#既知の問題|既知の問題]] セクションを確認してください。}}

== 準備 ==

ユーザースペースのユーティリティについては、基本的な操作に必要な {{Pkg|btrfs-progs}} パッケージを [[インストール]] してください。

Btrfs ファイルシステムから起動する必要がある場合 (つまり、カーネルと initramfs が Btrfs パーティションにある場合)、あなたの [[ブートローダー]] が Btrfs をサポートしているか確認してください。

== ファイルシステムの作成 ==

以下は、新しい Btrfs [[ファイルシステム]] を作成する方法を示しています。ext3/4 パーティションを Btrfs に変換するには、[[Btrfs#Ext3/4 から Btrfs への変換|Ext3/4 から Btrfs への変換]] を見て下さい。パーティションレスなセットアップを使うには、[[Btrfs#パーティションレス Btrfs ディスク|パーティションレス Btrfs ディスク]] を見て下さい。

詳しくは {{man|8|mkfs.btrfs}} を見て下さい。

=== 単一デバイス上のファイルシステム ===

パーティション {{ic|/dev/''partition''}} に Btrfs ファイルシステムを作るには、次のようにします。

# mkfs.btrfs -L ''mylabel'' /dev/''partition''

メタデータの Btrfs のデフォルトのノードサイズは 16KB ですが、データのデフォルトのセクターサイズはページサイズと同じで、自動検出されます。メタデータに大きなノードサイズを使用するには(セクターサイズの倍数である必要があり、最大 64KB が許可されます)、この例に示すように、{{ic|-n}} スイッチを介して {{ic|nodesize}} の値を指定します 32KB ブロックの使用例:

# mkfs.btrfs -L ''mylabel'' -n 32k /dev/''partition''

{{Note|{{man|8|mkfs.btrfs|OPTIONS}} によると、"[a]ノードサイズが小さいほど断片化は増加しますが、bツリーが高くなり、ロックの競合が少なくなります。ノードサイズが大きいほど、メタデータブロックを更新する際のメモリ操作のコストが高くなりますが、パッキングが向上し、断片化が少なくなります"}}

=== マルチデバイス対応ファイルシステム ===

{{Warning|
* Btrfs の RAID 5 と RAID 6 モードには致命的な欠陥があり、"捨てデータでのテスト以外" には使用しないでください。[https://lore.kernel.org/linux-btrfs/20200627032414.GX10769@hungrycats.org/ 既知の問題と部分的な回避策のリスト]。状況の更新については [https://man.archlinux.org/man/btrfs.5#RAID56_STATUS_AND_RECOMMENDED_PRACTICES the Btrfs page on RAID5 and RAID6] を見て下さい。
* デフォルトでは、[[systemd]] は {{ic|/var/log/journal}} に対して [[#コピーオンライト (CoW)|CoW]] を無効にしていますが、これが原因で RAID 1 上でデータ破損が発生することがあります ([[#CoW の無効化]] を参照) これを防ぐために、{{ic|/usr/lib/tmpfiles.d/journal-nocow.conf}} を上書きするための空のファイル {{ic|/etc/tmpfiles.d/journal-nocow.conf}} を作成してください({{man|5|tmpfiles.d|CONFIGURATION DIRECTORIES AND PRECEDENCE}} を参照)
}}

複数のデバイスを使用して RAID を作成することができます。サポートされている RAID レベルは RAID 0, RAID 1, RAID 10, RAID 5, RAID 6 です。カーネル 5.5 からは RAID1c3 と RAID1c4 で RAID1 レベルの 3-コピーと 4-コピーが可能です。RAIDレベルは、データ用とメタデータ用にそれぞれ {{ic|-d}} と {{ic|-m}} オプションを使って別々に設定することができます。デフォルトでは、データは1つのコピー ({{ic|single}}) で、メタデータはミラーリング ({{ic|raid1}}) された状態になっています。これは
[[W:JBOD|JBOD configuration]] を作成すると、ディスクは1つのファイルシステムとして認識されますが、ファイルは複製されません。Btrfs RAID ボリュームを作成する方法についての詳しい情報は [https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices Using Btrfs with Multiple Devices] を見て下さい。

# mkfs.btrfs -d single -m raid1 /dev/''part1'' /dev/''part2'' ...

プールで複数の Btrfs デバイスを使うには {{ic|udev}} フックか {{ic|btrfs}} フックを {{ic|/etc/mkinitcpio.conf}} に記述する必要があります。詳しくは [[Mkinitcpio#HOOKS]] の記事を見て下さい。

{{Note|
* マルチデバイスファイルシステムに後からデバイスを追加することも可能です。詳しくは [https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices Btrfs wiki article] を見て下さい。
* デバイスは異なるサイズにすることができます。しかし、RAID 構成の1つのドライブが他のドライブより大きい場合、この余分なスペースは使用されません。
* [[Syslinux]] などのいくつかの [[ブートローダー]] はマルチデバイスファイルシステムをサポートしません。
* Btrfs は自動的に最速のデバイスから読み込むわけではないので、異なる種類のディスクを混在させるとパフォーマンスに一貫性がなくなります。詳しくは [https://stackoverflow.com/a/55408367] を見て下さい。
}}

マルチデバイス Btrfs ファイルシステム特有のメンテナンスに関するアドバイスは [[#RAID]] をご覧下さい。

==== プロファイル ====

Btrfs は、ミラーリング、パリティ、ストライピングを構成するために [https://btrfs.readthedocs.io/en/latest/mkfs.btrfs.html#profiles プロファイル] という概念を使用します。標準的な [[Wikipedia:RAID|RAID]] 用語では、これは ''RAID level'' と呼ばれます。Btrfs ファイルシステムでは、メタデータ({{man|8|mkfs.btrfs}} の {{ic|-m}} オプション) とデータ ({{man|8|mkfs.btrfs}} の {{ic|-d}} オプション)のプロファイルが異なる場合があります。

いくつかの注目すべきプロファイル:

; single
: ミラーリングなし、ストライピングなし、パリティなし。複数のデバイスを単一のファイルシステムにマッピングする機能を提供します。[[mdadm]] 用語では {{ic|LINEAR}} と呼ばれます。
; raid0
: ミラーリングなし、ストライピングあり、パリティなし。デバイス間の並列アクセスを可能にしますが、従来の [[mdadm]] RAID のように同じサイズのデバイスに限定されません。
; raid1
: ミラーリングあり、ストライピングなし、パリティなし。1 つのドライブ障害からの復旧を可能にします。

== ファイルシステムの構成 ==

=== コピーオンライト (CoW)===

デフォルトでは Btrfs は全てのファイルに対して常に [[Wikipedia:copy-on-write|copy-on-write]] を使用します。書き込みはその場のデータを上書きしません; 代わりに、ブロックの修正されたコピーが新しい場所に書き込まれ、メタデータは新しい場所を指すように更新されます。実装の詳細や利点と欠点については [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.29 Btrfs Sysadmin Guide セクション] を見て下さい。

==== CoW の無効化 ====

{{Warning|Btrfs で CoW を無効にすると、チェックサムも無効になります。 Btrfs は破損した {{ic|nodatacow}} ファイルを検出できません。 RAID 1 と組み合わせると、停電やその他の破損原因により、データが同期しなくなる可能性があります。}}

マウントされたサブボリュームで新しく作成されたファイルのコピーオンライトを無効にするには、{{ic|nodatacow}} マウントオプションを使用します。これは、新しく作成されたファイルにのみ影響します。コピーオンライトは、既存のファイルに対して引き続き影響します。 {{ic|nodatacow}} オプションも圧縮を無効にします。詳しくは {{man|5|btrfs}} をご覧ください。

{{Note|{{man|5|btrfs|MOUNT OPTIONS}} から:

:単一のファイルシステム内で、一部のサブボリュームを {{ic|nodatacow}} でマウントし、他のサブボリュームを {{ic|datacow}} でマウントすることはできません。最初にマウントされたサブボリュームのマウントオプションは、他のサブボリュームに適用されます。
}}

ファイルやディレクトリ単体で CoW を無効化するには、次のコマンドを使って下さい:

$ chattr +C </dir/file>

これにより、ファイルへの参照が 1つしかない操作のコピーオンライトが無効になります。複数の参照がある場合。ファイルクローン/軽量クローンまたはファイルシステムスナップショットが原因で、コピーオンライトが引き続き発生します。{{Pkg|coreutils}} 9.0 以降、{{ic|cp}} はデフォルトで軽量コピーを実行しようとすることに注意してください。詳細については、{{man|1|cp}} を参照してください。

{{Note|{{man|1|chattr}} から:

:btrfs の場合、'{{ic|C}}' フラグを新しいファイルまたは空のファイルに設定する必要があります。すでにデータブロックがあるファイルに設定されている場合、ファイルに割り当てられたブロックが完全に安定する時期は未定義です。'{{ic|C}}' フラグがディレクトリに設定されている場合、ディレクトリには影響しませんが、そのディレクトリに作成された新しいファイルには {{ic|No_COW}} 属性が含まれます。
}}

{{Tip|1=上記のメモに従い、次のトリックを使用して、ディレクトリ内の既存のファイルのコピーオンライトを無効にすることができます:

$ mv ''/path/to/dir'' ''/path/to/dir''_old
$ mkdir ''/path/to/dir''
$ chattr +C ''/path/to/dir''
$ cp -a --reflink=never ''/path/to/dir''_old/. ''/path/to/dir''
$ rm -rf ''/path/to/dir''_old

このプロセス中にデータが使用されていないことを確認してください。また、後述のように {{ic|1=--reflink=never}} を指定しない {{ic|mv}} または {{ic|cp}} は機能しないことに注意してください。
}}

===== スナップショットへの影響 =====

ファイルのコピーオンライトが無効 (NOCOW) でスナップショットが作成された場合、スナップショットは古いファイルブロックを所定の位置にロックするため、スナップショット後のファイルブロックへの最初の書き込みは [https://www.spinics.net/lists/linux-btrfs/msg33090.html COW 操作] になります。ただし、ファイルは NOCOW 属性を保持し、同じファイルブロックへの後続の書き込みは次のスナップショットまでそのまま残ります。

スナップショットを頻繁に行うと、最初の書き込みで COW が必要になるため、NOCOW の効果が低下する可能性があります。そのようなファイルのコピーオンライトを完全に避けるには、それらを別のサブボリュームに入れ、そのサブボリュームのスナップショットを作成しないでください。

=== 圧縮 ===

Btrfs は [https://btrfs.wiki.kernel.org/index.php/Compression 透過的自動圧縮] をサポートしています。これはファイルサイズを小さくするだけでなく、書き込み増幅を減らすことでフラッシュベースのメディアの寿命を大幅に延ばします。[[Fedora:Changes/BtrfsByDefault#Compression]], [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NTV77NFF6NDZM3QTPUM2TQZ5PCM6GOO2/], [https://pagure.io/fedora-btrfs/project/issue/36#comment-701551] を参照して下さい。また、[https://www.phoronix.com/scan.php?page=article&item=btrfs_compress_2635&num=1 パフォーマンスを向上させる] 場合もありますが(例:重いファイル I/O を持つシングルスレッド)、(例:大きなファイル I/O を持つマルチスレッドや CPU 集中タスク)では明らかにパフォーマンスを低下させることがあります。一般に、最速の圧縮アルゴリズムである ''zstd'' と ''lzo'' を用いると、より良いパフォーマンスが得られます。いくつかの [https://www.phoronix.com/scan.php?page=article&item=btrfs-zstd-compress benchmarks] では、詳細な比較がなされています。

ここで {{ic|''alg''}} は {{ic|zlib}}, {{ic|lzo}}, {{ic|zstd}}, あるいは {{ic|no}} のいずれかです。(圧縮しない場合) このオプションを使うと、btrfs はデータの最初の部分を圧縮することで縮小されるかどうかをチェックします。もしそうなら、そのファイルへの書き込み全体が圧縮されます。そうでない場合は、何も圧縮されません。このオプションでは、書き込みの最初の部分が縮小しない場合、残りのデータが非常に縮小しても、書き込みに圧縮は適用されません。[https://btrfs.wiki.kernel.org/index.php/Compression#What_happens_to_incompressible_files.3F] これは、書き込むべき全てのデータが btrfs に完全に与えられ圧縮されるまで、ディスクの書き込み開始を待たせるのを防ぐために行われます。

代わりに {{ic|1=compress-force=''alg''}} マウントオプションを使うと、btrfs が最初の部分を圧縮しているかどうかのチェックをスキップし、全てのファイルに対して自動的に圧縮を試行することが可能になります。最悪の場合、これは何の目的もなく CPU 使用量を (少し) 増加させる可能性があります。しかし、複数の用途が混在するシステムでの経験的なテストでは、 {{ic|1=compress-force=''zstd''}} を使うことで、ただの {{ic|1=compress=''zstd''}} に比べて約10%のディスク圧縮という大きな改善がありました、この場合も 10% のディスク圧縮でした。

マウントオプションが追加された後に作成または変更されたファイルのみが圧縮されます。

ここで {{ic|''alg''}} は {{ic|zlib}}, {{ic|lzo}}, {{ic|zstd}} のいずれかです。例えば、ファイルシステム全体を {{pkg|zstd}} で再圧縮する場合、以下のコマンドを実行します。

# btrfs filesystem defragment -r -v -czstd /

空の Btrfs パーティションに Arch をインストールするときに圧縮を有効にするには、ファイルシステムを [[マウント]] するときに {{ic|compress}} オプションを使ってください。{{ic|1=mount -o compress=zstd /dev/sd''xY'' /mnt/}} となります。設定時に、[[fstab]]でルートファイルシステムのマウントオプションに {{ic|1=compress=zstd}} を追加してください。

{{Tip|マウントオプション {{ic|compress}} を使わずにファイル単位で圧縮を有効にすることもできます; そうするためには、ファイルに {{ic|chattr +c}} を適用します。ディレクトリに適用すると、新しいファイルが来たときに自動的に圧縮されます。}}

{{Warning|
* このオプションを使うと、古いカーネルや {{ic|zstd}} をサポートしていない {{pkg|btrfs-progs}} を使っているシステムは、ファイルシステムを読んだり修復したりできない可能性があります。
* [[GRUB]] は 2.04 で ''zstd'' のサポートを導入しました。MBR/ESP にインストールされたブートローダを実際にアップグレードしたことを確認してください。BIOS/UEFI セットアップに適したオプションで {{ic|grub-install}} を実行して、{{Bug|63235}} を見て下さい。
}}

==== 圧縮の種類と比率を表示する ====

{{pkg|compsize}} はファイルのリスト (または btrfs ファイルシステム全体) を受け取り、使用された圧縮タイプと有効な圧縮率を測定します。非圧縮サイズは {{man|1|du}} のような他のプログラムによって与えられる数値と一致しないかもしれません。なぜなら、たとえ何度も再リンクされていても、たとえその一部がもうどこにも使われていないけれどゴミ収集されていないとしても、全てのエクステントは一度にカウントされるからです。これは {{ic|compsize -x /}} のような状況で便利で、btrfs でないサブディレクトリを探そうとして、実行全体が失敗するのを避けます。

=== サブボリューム ===

"btrfs サブボリュームはブロックデバイスではありません(そしてブロックデバイスとして扱えません)代わりに btrfs サブボリュームは POSIX ファイル名空間として考えることができます。このネームスペースはファイルシステムのトップレベルのサブボリュームからアクセスすることもできますし、それ自体でマウントすることもできます" [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes]

各 Btrfs ファイルシステムには ID 5 のトップレベルのサブボリュームがあります。これは {{ic|/}} としてマウントすることができます。(デフォルト) または、代わりに別のサブボリュームを [[Btrfs#サブボリュームをマウントする|マウントする]] こともできます。サブボリュームはファイルシステム内で移動することができ、パスよりもむしろその ID で識別されます。

詳細については、次のリンクを参照してください:

* [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes Btrfs Wiki SysadminGuide#Subvolumes]
* [https://btrfs.wiki.kernel.org/index.php/Getting_started#Basic_Filesystem_Commands Btrfs Wiki Getting started#Basic Filesystem Commands]
* [https://btrfs.wiki.kernel.org/index.php/Trees Btrfs Wiki Trees]

==== サブボリュームを作成する ====

サブボリュームを作成するには:
# btrfs subvolume create ''/path/to/subvolume''

==== サブボリュームを一覧する ====

現在のサブボリュームのリストを表示するには:

# btrfs subvolume list -p .

==== サブボリュームの削除 ====

サブボリュームを削除するには

# btrfs subvolume delete ''/path/to/subvolume''

Linux 4.18 以降では、通常のディレクトリのようにサブボリュームを削除することもできます ({{ic|rm -r}}, {{ic|rmdir}})

==== サブボリュームをマウントする ====

サブボリュームは {{ic|1=subvol=''/path/to/subvolume''}} や {{ic|1=subvolid=''objectid''}} マウントフラグを使うことでファイルシステムのパーティションと同じようにマウントできます。例えば、{{ic|subvol_root}} という名前のサブボリュームが存在したら {{ic|/}} にマウントすることができます。ファイルシステムのトップレベルにサブボリュームを作成して適切なマウントポイントにマウントすることで、伝統的なファイルシステムのパーティションと同じように使うことができ、[[Btrfs#スナップショット|スナップショット]] を使用してファイルシステムを前の状態に簡単に戻すことが可能です。

{{Tip|1=トップレベルのサブボリューム (ID=5) を {{ic|/}} として使用しないことでサブボリュームのレイアウトの変更を簡単にできます。サブボリュームを作成して実際のデータを保存して {{ic|/}} にマウントします。}}

{{Note|{{man|5|btrfs|MOUNT OPTIONS}} から
:ほとんどのマウントオプションは '''ファイルシステム全体''' に適用され、マウントされる最初のサブボリュームのオプションだけが有効になります。これは実装不足によるもので、将来的に変更されるかもしれません。

サブボリュームごとにどのマウントオプションが使えるかは [https://btrfs.wiki.kernel.org/index.php/FAQ#Can_I_mount_subvolumes_with_different_mount_options.3F Btrfs Wiki FAQ] を見て下さい。
}}

[[Snapper#推奨ファイルシステムレイアウト]], [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Managing_Snapshots Btrfs SysadminGuide#Managing Snapshots], [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout Btrfs SysadminGuide#Layout] などにサブボリュームを使用するファイルシステムレイアウトの例が存在します。

btrfs 固有のマウントオプションの完全なリストは {{man|5|btrfs}} を見て下さい。

==== サブボリュームをルートとしてマウントする ====

サブボリュームをルートマウントポイントとして使用するには、{{ic|1=rootflags=subvol=''/path/to/subvolume''}} を使用して [[カーネルパラメータ#設定|カーネルパラメータ]] 経由でサブボリュームを指定します。{{ic|/etc/fstab}} でルート・マウントポイントを編集し、マウント・オプションに {{ic|1=subvol=}} を指定します。または、サブボリュームの ID {{ic|1=rootflags=subvolid=''objectid''}} をカーネルパラメータとして使い、{{ic|1=subvolid=''objectid''}} を {{ic|/etc/fstab}} のマウントオプションとして指定することもできます。

==== デフォルトのサブボリュームを設定する ====

マウントオプションに {{ic|1=subvol=}} が指定されない場合、デフォルトのサブボリュームがマウントされます。デフォルトサブボリュームを変更するには、次のようにします。

# btrfs subvolume set-default ''subvolume-id'' /

ここで、''subvolume-id'' は [[Btrfs#サブボリュームを一覧する|listing]] で見つけることができます。

{{Note|1=[[GRUB]] があるシステムでデフォルトのサブボリュームを変更した後、ブートローダに変更を通知するために {{ic|grub-install}} を再度実行する必要があります。[https://bbs.archlinux.org/viewtopic.php?pid=1615373 このフォーラムのスレッド] を参照してください。}}

{{ic|btrfs subvolume set-default}} でデフォルトのサブボリュームを変更すると、ファイルシステムのトップレベルは {{ic|1=subvol=/}} や {{ic|1=subvolid=5}} マウントオプションを使ってアクセスする以外ではアクセスできなくなります [https://btrfs.wiki.kernel.org/index.php/SysadminGuide]

=== クォータ ===

{{warning|Qgroup はまだ安定状態ではなくサブボリュームのスナップショットとクォータを組み合わせると操作によってパフォーマンスに問題をきたします (スナップショットの削除など)。さらに [https://btrfs.wiki.kernel.org/index.php/Quota_support#Known_issues 既知の問題] が存在しています。}}

Btrfs におけるクォータのサポートはクォータグループ (qgroup) を利用してサブボリュームレベルで実装されています: 各サブボリュームにはデフォルトで ''0/<subvolume id>'' という形式でクォータグループが割り当てられています。必要であればクォータグループを作成することもできます。

クォータグループを使うにはまずクォータを有効にする必要があります:

# btrfs quota enable <path>

上記のコマンドを実行してから新しいサブボリュームを作成すると、グループによって制御が可能になります。既存のサブボリュームでも制御を行いたい場合、クォータを有効にしてから、''<subvolume id>'' を使ってサブボリュームごとにクォータグループを作成して再スキャンしてください:

# btrfs subvolume list <path> | cut -d' ' -f2 | xargs -I{} -n1 btrfs qgroup create 0/{} <path>
# btrfs quota rescan <path>

Btrfs のクォータグループはツリー構造になっていて、サイズ制限はクォータグループごとに設定し、ツリーに属しているサブボリュームに制限が課せられます。

クォータグループで設定できる制限は合計データ使用量・非共有のデータ使用量・圧縮データ使用量、あるいはそれらを組み合わせたものです。元のボリュームファイルを削除してコピーを残す場合、他のクォータグループの非共有制限が変わるため、ファイルのコピーや削除で制限に抵触する可能性があります。例えば、新しいスナップショットが元のサブボリュームの全てのブロックと同じデータを持っている場合、どちらかのサブボリュームだけで共通データを削除するともう片方のサブボリュームの制限に引っかかる可能性があります。

クォータグループに制限を設定するには、{{ic|btrfs qgroup limit}} コマンドを使います。合計使用量の制限や非共有制限 ({{ic|-e}}) または圧縮制限 ({{ic|-c}}) が設定できます。ファイルシステムの特定のパスにおける使用量や制限を表示するには:

# btrfs qgroup show -reF <path>

=== コミット間隔の設定 ===

データがファイルシステムに書き込まれる解像度は、Btrfs自体とシステム全体の設定によって決まります。 Btrfs のデフォルトは、新しいデータがファイルシステムにコミットされる30秒のチェックポイント間隔です。これは、btrfs パーティションの {{ic|/etc/fstab}} に {{ic|commit}} マウントオプションを追加することで変更できます。

LABEL=arch64 / btrfs defaults,compress=zstd,commit=120 0 0

システム全体の設定もコミット間隔に影響します。これらには {{ic|/proc/sys/vm/*}} の下のファイルが含まれており、このwiki記事の範囲外です。それらのカーネルドキュメントは、https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html で入手できます。

=== SSD TRIM ===

Btrfs ファイルシステムは、TRIM コマンドをサポートする SSD ドライブから未使用のブロックを解放できます。カーネルバージョン 5.6 以降、非同期破棄がサポートされ、マウントオプション {{ic|1=discard=async}} で有効になります。解放されたエクステントはすぐには破棄されませんが、グループ化され、後で別のワーカースレッドによってトリミングされるため、コミットの待ち時間が短縮されます。

TRIM の有効化と使用に関するより詳しい情報は [[ソリッドステートドライブ#TRIM]] に記載されています。

== 使い方 ==

=== スワップファイル ===

Btrfs の [[スワップファイル]] は Linux カーネル5.0 以降でサポートされています。[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed46ff3d423780fa5173b38a844bf0fdb210a2a7] スワップファイルを初期化する適切な方法は、最初にファイルをホストする非圧縮、非スナップショットのサブボリュームを作成し、そのディレクトリに ''cd'' してから、長さゼロのファイルを作成し、{{ic|No_COW}} を設定することです。属性を [https://wiki.archlinux.jp/index.php/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E3%83%91%E3%83%BC%E3%83%9F%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%A8%E5%B1%9E%E6%80%A7#chattr_.E3.81.A8_lsattr chattr] で指定し、圧縮が無効になっていることを確認します。

# cd ''/path/to/swapfile''
# truncate -s 0 ./swapfile
# chattr +C ./swapfile
# btrfs property set ./swapfile compression none

詳細な設定については、 [https://wiki.archlinux.jp/index.php/%E3%82%B9%E3%83%AF%E3%83%83%E3%83%97#.E3.82.B9.E3.83.AF.E3.83.83.E3.83.97.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.81.AE.E4.BD.9C.E6.88.90 スワップファイルの作成] を参照してください。スワップファイルへの休止状態の構成については、[https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#Hibernation_into_swap_file_on_Btrfs Hibernation into swap file on Btrfs]で説明されています。

{{Note|1=Linux カーネル5.0 以降、 Btrfs にはネイティブスワップファイルのサポートがありますが、いくつかの制限があります。
* スワップファイルをスナップショットサブボリュームに置くことはできません。適切な手順は、スワップファイルを配置する新しいサブボリュームを作成することです。
* 複数のデバイスにまたがるファイルシステム上のスワップファイルはサポートされていません。 [https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_files.3F Btrfs wiki: Does btrfs support swap files?] および [https://bbs.archlinux.org/viewtopic.php?pid=1849371#p1849371 Arch forums discussion]。
}}

=== 使用領域空き領域の表示 ===

{{man|1|df}} のような一般的な linux ユーザースペースツールは Btrfs パーティションの空き容量を不正確に報告します。Btrfs パーティションを調べるには {{ic|btrfs filesystem usage}} を使うことが推奨されます。例えば、デバイスのアロケーションと使用状況の統計の完全な内訳を見るには、{{ic|btrfs filesystem usage}} を使って下さい。

# btrfs filesystem usage /

{{Note|現在、{{ic|btrfs filesystem usage}} コマンドは {{ic|RAID5/RAID6}} では正しく動作していません。}}

あるいは、{{ic|btrfs filesystem df}} を使えば、root で実行しなくても、割り当てられた領域の使用状況を素早くチェックすることができます。

$ btrfs filesystem df /

詳しくは [https://btrfs.wiki.kernel.org/index.php/FAQ#How_much_free_space_do_I_have.3F] を参照してください。

{{man|1|du}} や {{man|1|ncdu}} のような、ファイルシステムのあるサブセットについて空間の使用状況を分析するツールにも同じ制限が適用され、これらは reflinks, snapshots, 圧縮を考慮しません。代わりに、btrfs を意識した代替手段は {{AUR|btdu}} と [[Btrfs#圧縮の種類と比率を表示する|圧縮の種類と比率を表示する]] を見て下さい。

=== デフラグメンテーション ===

{{Warning|Linux カーネルバージョン 5.16.x < 5.16.5 のメジャーレグレッションにより、一部のシステムで Btrfs デフラグが無限ループし、手動および自動デフラグの両方に影響があります。これにより、影響を受けるドライブに極端な I/O 負荷がかかり、ドライブの寿命が極端に短くなり、パフォーマンスに影響を与える可能性があります。このため、これらのバージョンで {{ic|autodefrag}} を使うことは推奨されません。むしろ {{ic|noautodefrag}} を使ってオンラインデフラグが無効になるようにすべきです。[https://www.reddit.com/r/linux/comments/sgybyr/psa_linux_516_has_major_regression_in_btrfs/] と [https://lore.kernel.org/linux-btrfs/CAEwRaO4y3PPPUdwYjNDoB9m9CLzfd3DFFk2iK1X6OyyEWG5-mg@mail.gmail.com/] を参照してください。}}

Btrfs はマウントオプション {{ic|autodefrag}} でオンラインデフラグをサポートしています、{{man|5|btrfs|MOUNT OPTIONS}} を見て下さい。手動でルートのデフラグをするには:

# btrfs filesystem defragment -r /

上記のコマンドを {{ic|-r}} スイッチなしで使用すると、ディレクトリを含むサブボリュームが保持するメタデータのみがデフラグされる結果となります。このため、パスを指定するだけで単一ファイルのデフラグが可能です。

COW コピー (スナップショットコピーまたは {{ic|cp}} や bcp で作成されたもの) を持つファイルに圧縮アルゴリズムで {{ic|-c}} スイッチを使用したデフラグを行うと、無関係の 2 つのファイルが効果的にディスク使用量を増加させる結果になることがあります。

=== RAID ===

Btrfs は [[Btrfs#マルチデバイス対応ファイルシステム|マルチデバイス対応ファイルシステム]] のためのネイティブな ''RAID'' を提供します。btrfs RAID を [[mdadm]] と区別する注目すべき機能は自己回復型の冗長アレイとオンラインバランシングです。より詳しい情報は [https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices the Btrfs wiki page] を見て下さい。Btrfs sysadmin ページにも [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#RAID_and_data_replication にセクションがありますので参照して下さい。] 技術的な背景があります。

{{Warning|Parity RAID (RAID 5/6) コードには、複数の重大なデータ損失のバグがあります。より詳細な情報は Btrfs Wiki の [https://btrfs.wiki.kernel.org/index.php/RAID56 RAID5/6 page] と [https://lore.kernel.org/linux-btrfs/8695beeb-f991-28c4-cf6b-8c92339e468f@inwind.it/ linux-btrfs mailing list] のバグレポートを見て下さい。2020年6月、誰かが [https://lore.kernel.org/linux-btrfs/20200627030614.GW10769@hungrycats.org/ 現在の問題の包括的なリスト] と [https://lore.kernel.org/linux-btrfs/20200627032414.GX10769@hungrycats.org/ 役に立つ回復ガイド] を投稿しています}}

==== Scrub ====

[https://btrfs.wiki.kernel.org/index.php/Glossary Btrfs Wiki Glossary] によると、Btrfs スクラブはオンラインファイルシステムチェックツールです。ファイルシステム上のすべてのデータとメタデータを読み取り、チェックサムと RAID ストレージからの複製コピーを使用して、破損したデータを特定して修復します。

{{Note|実行中のスクラブプロセスはシステムのサスペンドを防ぎます。詳細は [https://lore.kernel.org/linux-btrfs/20140227190656.GA28338@merlins.org/ このスレッド] を参照してください。}}

===== 手動で開始する =====

{{ic|/}} を含むファイルシステムに対して (バックグラウンド) scrub を開始する場合。

# btrfs scrub start /

実行中の scrub の状態を確認する。

# btrfs scrub status /

===== サービスまたはタイマーを使って起動する =====

{{Pkg|btrfs-progs}} パッケージは、指定したマウントポイントを毎月 scrubbing するためのユニット {{ic|btrfs-scrub@.timer}} を提供します。例えば {{ic|/}} の場合は {{ic|btrfs-scrub@-.timer}} 、{{ic|/home}} の場合は {{ic|btrfs-scrub@home.timer}} のように、エスケープしたパスでタイマーを [[有効化]] してください。パスのエスケープは {{ic|systemd-escape -p ''/path/to/mountpoint''}} で行えます、詳しくは {{man|1|systemd-escape}} を見て下さい。

scrub を実行するには {{ic|btrfs-scrub@.service}} を [[systemd#ユニットを使う|スタート]] します。(同じエンコードされたパスで) この方法の利点は {{ic|btrfs scrub}} と比べても同じです。(root ユーザーで) scrub の結果が [[systemd/ジャーナル]] に記録されることです。

冷却が不十分な大きな NVMe ドライブ (ラップトップなど) では、scrub はドライブを速く、長く読み込んで、ドライブを非常に高温にします。systemd で scrub を実行している場合、[[ドロップインファイル]] を使って {{man|5|systemd.resource-control}} にある {{ic|IOReadBandwidthMax}} オプションで簡単にスクラブ速度を制限することができます。

==== Balance ====

balance はファイルシステム上の全てのデータをアロケータに再度流し込みます。デバイスが追加されたり削除された場合にファイルシステム上のデータを再配置するために実行します。balance はデバイスが故障した場合に、冗長な RAID レベルのコピーを再生成します。

{{Pkg|btrfs-progs}}-3.12 から''バランシング''はバックグラウンドプロセスになりました - 詳しくは {{ic|man 8 btrfs-balance}} を見て下さい。

# btrfs balance start /
# btrfs balance status /

=== スナップショット ===

"スナップショットとは、btrfs の COW 機能を使って、そのデータ(とメタデータ)を他のサブボリュームと共有する、サブボリュームのことです" 詳しくは [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapshots Btrfs Wiki SysadminGuide#Snapshots] を見て下さい。

スナップショットを作成するには

# btrfs subvolume snapshot ''source'' [''dest''/]''name''

読み取り専用のスナップショットを作成するには、{{ic|-r}} フラグを追加します。readonly スナップショットの書き込み可能バージョンを作成するには、単純にそのスナップショットを作成します。

{{Note|{Note
* スナップショットを読み込み専用から書き込み専用に変換することは可能です。しかし、これは将来のインクリメンタル送受信で問題が発生するため、推奨されません[https://lore.kernel.org/linux-btrfs/06e92a0b-e71b-eb21-edb5-9d2a5513b718@gmail.com/] 新しい書き込み可能なスナップショットを作成することで、そのような問題を防ぐことができます。
* スナップショットは再帰的ではありません。ネストされたサブボリュームは、スナップショット内部では空のディレクトリになります。
}}

=== 送信/受信 ===

サブボリュームは {{ic|send}} コマンドを使って標準出力やファイルに送信することができます。Btrfs の {{ic|receive}} コマンドにパイプで渡すことで非常に便利に使うことが可能です。例えば、{{ic|/root_backup}} という名前のスナップショットを {{ic|/backup}} に送信するには以下のコマンドを実行します:

# btrfs send /root_backup | btrfs receive /backup

送信するスナップショットは読み取り専用である必要があります。上記のコマンドは外部デバイスにサブボリュームをコピーするのにも使えます (例えば上の {{ic|/backup}} を USB ディスクにマウント)。

また、スナップショットの差分だけを送信することも可能です。例えば、上記のように {{ic|root_backup}} のコピーを送信したことがある場合、{{ic|root_backup_new}} という名前の読み取り専用のスナップショットを新しく作成してから、増加差分だけを {{ic|/backup}} に送信するには:

# btrfs send -p /root_backup /root_backup_new | btrfs receive /backup

これで {{ic|root_backup_new}} という名前の新しいサブボリュームが {{ic|/backup}} に作成されます。

差分バックアップをしたり自動的にバックアップを行うツールは [https://btrfs.wiki.kernel.org/index.php/Incremental_Backup Btrfs Wiki's Incremental Backup] を見てください。

=== 重複排除 ===

コピーオンライトを使用した場合、Btrfs は実際にはデータをコピーしないでファイルやサブボリュームをコピーできます。ファイルに変更が加えられたときに新しい本当のコピーが作成されます。重複排除はさらに共通部分が存在するデータブロックを認識して、コピーオンライトと同じようにエクステントにまとめてしまいます。

Btrfs パーティションの重複排除に使用するツールには {{pkg|duperemove}}, {{pkg|bees}} などが存在します。{{aur|rmlint-git}}, {{pkg|rdfind}}, {{aur|jdupes}} あるいは {{aur|dduper-git}} などを使うことでファイルベースでデータの重複排除を行うこともできます。

これらのプログラムで利用可能な機能の概要や追加情報については [https://btrfs.readthedocs.io/en/latest/Deduplication.html upstreamの wiki ページ] を参照してください。

=== リサイズ ===

{{Warning|データの損失を防ぐために、サイズ変更作業を始める前に必ずデータをバックアップしてください}}

ファイルシステムは、デバイスで利用可能な最大のスペースまで拡大することができ、正確なサイズを指定することもできます。ファイルシステムのサイズを大きくする前に、デバイスまたは論理ボリュームのサイズを大きくすることを確認します。
ファイルシステムに正確なサイズを指定する場合、新しいサイズが次の条件を満たすことを確認します。

* 新しいサイズは既存のデータサイズより大きくなければなりません。
* ファイルシステムのサイズは、使用可能な領域を超えて拡張できないため、新しいサイズは現在のデバイスサイズと同じかそれ以下でなければなりません。

デバイス上のファイルシステムのサイズを小さくする場合は、新しいサイズが以下の条件を満たすことを確認する。

* 新しいサイズは既存のデータサイズより大きくなければなりません。
* ファイルシステムのサイズは使用可能な領域を超えて拡張できないため、新しいサイズは現在のデバイスのサイズと同じかそれ以下でなければなりません。

{{Note|ファイルシステムを保持する論理ボリュームのサイズも小さくする場合は、デバイスまたは論理ボリュームのサイズを小さくする前に、必ずファイルシステムのサイズを小さくしてください。}}

ファイルシステムのサイズをデバイスの利用可能な最大サイズに拡張するには、次のようにします。

# btrfs filesystem resize max /

ファイルシステムを特定のサイズに拡張する場合。

# btrfs filesystem resize ''size'' /

{{ic|''size''}} は、希望するサイズにバイト単位で置き換えてください。K(キロバイト)、M(メガバイト)、G(ギガバイト)など、値の単位を指定することも可能です。また、値の前にプラス (+) 記号、マイナス (-) 記号を付けることで、現在のサイズに対する増減をそれぞれ指定することも可能です。

# btrfs filesystem resize +''size'' /
# btrfs filesystem resize -''size'' /

== 既知の問題 ==

試す前に、いくつかの制限を知っておく必要があります。

=== 暗号化 ===

Btrfs には暗号化のサポートが組み込まれていませんが、この [https://lwn.net/Articles/700487/] は将来的に提供される可能性があります。ユーザーは、 {{ic|mkfs.btrfs}} を実行する前にパーティションを暗号化できます。 [https://wiki.archlinux.jp/index.php/Dm-crypt/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E5%85%A8%E4%BD%93%E3%81%AE%E6%9A%97%E5%8F%B7%E5%8C%96#Btrfs_.E3.82.B5.E3.83.96.E3.83.9C.E3.83.AA.E3.83.A5.E3.83.BC.E3.83.A0.E3.81.A8.E3.82.B9.E3.83.AF.E3.83.83.E3.83.97 dm-crypt/スワップを使用したsystem#Btrfsサブボリューム全体の暗号化] を参照してください。

既存の Btrfs ファイルシステムは [[EncFS]] や [[TrueCrypt]] のようなものを使用できますが、おそらく Btrfs の機能の一部はありません。

=== btrfs チェックの問題 ===
ツール{{ic|btrfs check}} には既知の問題があるため、セクション [[#btrfs check]] をよく参照してから実行してください。

== ヒントとテクニック ==

=== パーティションレス Btrfs ディスク ===

{{Warning|この種の構成はブートデバイスには適しておらず、代わりに Btrfs パーティションと別の [[EFI システムパーティション]] を設定することが推奨されています。さらに、GRUB はパーティションレスディスクへのインストールを強く推奨していません。
}}

Btrfs はデータストレージデバイス全体を占有し、[[MBR]] や [[GPT]] のパーティション方式を置き換えることができます。この場合、[[#サブボリューム|サブボリューム]] を使用してパーティションをシミュレートします。ただし、既存のパーティション上に [[#ファイルシステムの作成|Btrfs ファイルシステムを作成]] する場合、必ずしもパーティションレス構成にする必要はありません。パーティションレスの単一ディスク構成にはいくつかの制限があります。

* 同じディスク上の別のパーティションに他の[[ファイルシステム]]を配置することはできません。
* 前のポイントのため、このディスクに [[ESP]] を持つことは不可能です。[[Unified Extensible Firmware Interface|UEFI]] ブートには別のデバイスが必要です。

既存のパーティションテーブルを Btrfs で上書きするには、次のコマンドを実行します:

# mkfs.btrfs /dev/sd''X''

たとえば、 {{ic|/dev/sda1}} ではなく {{ic|/dev/sda}} を使用します。後者は、パーティショニングスキーム全体を置き換えるのではなく、既存のパーティションをフォーマットします。ルートパーティションは Btrfs なので、 {{ic|btrfs}} がカーネルに組み込まれていることを確認するか、{{ic|btrfs}} を [[mkinitcpio.conf#MODULES]] に入れて [mkinitcpio#イメージ作成とアクティベーション|initramfs を再生成] して下さい。

[[Arch ブートプロセス#ブートローダー|ブートローダ]] を、[[パーティショニング#Master Boot Record|マスターブートレコード]] を備えたデータ記憶装置の場合と同様にインストールします。[[Syslinux#手動インストール]] または [[GRUB/Tips and tricks#パーティションまたはパーティションレスディスクへのインストール]] を参照してください。 {{ic|Failed to mount /sysroot}} が原因でカーネルがブートしない場合は、 {{ic|/etc/default/grub}} に {{ic|1=GRUB_PRELOAD_MODULES="btrfs"}} を追加して、 grub 設定 ([[GRUB#メイン設定ファイルの生成]]) を生成してください。

=== Ext3/4 から Btrfs への変換 ===

{{Warning|btrfs メーリングリストには、不完全/破壊/破損した変換に関する多くの報告があります。失いたくないデータや ''作業中'' のバックアップがあることを確認してください。詳細については、 btrfswiki の [https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3Conversion fromExt3] を参照してください。}}

インストール CD から起動し、次の手順で変換します:

# btrfs-convert /dev/''partition''

パーティションをマウントし、ファイルを確認して変換をテストしてください。必ず {{ic|/etc/fstab}} を変更してください ({{ic|/etc/fstab}} の '''type''' を {{ic|btrfs}} に、 '''fs_passno'' をに変更すること) [最後のフィールド] を {{ic|0}} に設定します(Btrfs は起動時にファイルシステムのチェックを行わないため)また、パーティションの UUID が変更されていることに注意してください、UUID を使うときは fstab もそれに合わせて更新してください。システムに {{ic|chroot}} して、ブートローダのメニューリストを再構築します([[既存の Linux からインストール]] を参照)ルートファイルシステムを変換する場合、chroot したまま {{ic|mkinitcpio -p linux}} を実行して initramfs を再生成しないと、システムが正常に起動しません。

{{Note|新しく変換された btrfs にファイルをマウントまたは書き込みできないなどの問題がある場合は、バックアップサブボリューム {{ic|/ext2_saved}} がまだ存在する限り、常にロールバックするオプションがあります。 {{ic|btrfs-convert -r /dev/''partition''}} コマンドを使用してロールバックします。これにより、新しく変換された btrfs ファイルシステムへの変更が破棄されます。}}

問題がないことを確認したら、バックアップ {{ic|ext2_saved}} サブボリュームを削除して変換を完了します。これがないと ext3/4 に戻れないことに注意してください。

# btrfs subvolume delete /ext2_saved

最後に [[#Balance|balance]] ファイルシステムでスペースを再利用します。

以前にインストールされていたいくつかのアプリケーションは、btrfs に適合する必要があることを忘れないでください。

{{Note|Ext3/4 から Btrfs への変換は時間のかかる作業です。4 TiB のファイルシステムと通常の HDD では、最大で 10 時間かかることがあります。}}

=== ファイルシステム破損のリカバリ ===

{{Warning|{{ic|btrfs check}} ツールには既知の問題があります。セクション [[Btrfs#btrfs check|btrfs check]] を参照してください。}}

''btrfs-check'' はマウントされているファイルシステムでは使えません。ライブ USB から起動しないで ''btrfs-check'' を使えるようにするには、初期 RAM ディスクに以下のように追加してください:

{{hc|/etc/mkinitcpio.conf|output=
BINARIES=(btrfs)
}}

設定したら [[mkinitcpio]] を使って initramfs を再生成してください。

起動に問題が発生したら、ユーティリティを使って修復することができます。

{{Note|fsck でキャッシュを無効化する必要がある場合、起動後に一定時間フリーズするのは通常の動作です (btrfs-transaction がハングアップしているというメッセージがコンソールに表示されます) しばらく経てばシステムは復帰します。}}

詳しくは {{man|8|btrfs-check}} を参照。

=== スナップショットから起動する ===

スナップショットをブートするためには、セクション [[Btrfs#サブボリュームをルートとしてマウントする|サブボリュームをルートとしてマウントする]] で説明されているように、サブボリュームをルートパーティションとしてマウントする場合と同じ手順が適用されます。スナップショットはサブボリュームのようにマウントできます。

* [[GRUB]] を使用している場合、{{Pkg|grub-btrfs}} または {{AUR|grub-btrfs-git}} を使用して設定ファイルを再生成すると、自動的に btrfs スナップショットをブートメニューに取り込むことができます。
* [[rEFInd]] を使用している場合は、{{ic|refind-btrfs.service}} を [[systemd#ユニットを使う|有効]] にして開始後に、{{AUR|refind-btrfs}} を使用してブートメニューに btrfs スナップショットを自動的に取り込むことができます。
* [[Limine]] を使用する場合、{{AUR|limine-snapper-sync}} をインストールすることで、{{ic|limine-snapper-watcher.service}} を有効化した後、[[Snapper]] リストが変更されるたびにブートメニューにスナップショットエントリを自動生成できます。詳しくは [[Limine#Btrfs の Snapper スナップショットとの統合]] を参照してください。

=== systemd-nspawn で Btrfs サブボリュームを使う ===

[[Systemd-nspawn#Btrfs のサブボリュームをコンテナのルートとして使う]]や [[Systemd-nspawn#コンテナの一時的な Btrfs スナップショットを使う]]を見てください。

=== アクセス時間のメタデータ更新を削減 ===

Btrfs は書き込み時にコピーの性質を持つため、ファイルにアクセスするだけでメタデータのコピーと書き込みを開始します。アクセス時間の更新頻度を減らすと、この予期しないディスク使用がなくなり、パフォーマンスが向上する可能性があります。使用可能なオプションについては、 [[fstab#atime オプション|atime オプション]] を参照してください。

=== 外付けドライブへの増分バックアップ ===

以下のパッケージは {{ic|btrfs send}} と {{ic|btrfs receive}} を使って、外部ドライブに増分バックアップを送信します。実装や機能、要件の違いを見るにはそれぞれのドキュメントを参照してください。

* {{App|btrbk|Btrfs サブボリュームのスナップショットとリモートバックアップを作成するためのツール。|https://github.com/digint/btrbk|{{AUR|btrbk}}}}
* {{App|snap-sync|[[Snapper]] スナップショットを使用して、外付けドライブまたはリモートマシンにバックアップします。|https://github.com/wesbarnett/snap-sync.git|{{Pkg|snap-sync}}}}
* {{App|snapsync|[[Snapper]] の同期ツール。|https://github.com/doudou/snapsync|{{AUR|ruby-snapsync}}}}

以下のパッケージでは、Snapper のスナップショットを Btrfs 以外のファイルシステムへバックアップすることができます。

* {{App|snapborg|Snapper スナップショットを {{Pkg|borg}} バックアップと統合する borgmatic のようなツール。|https://github.com/enzingerm/snapborg|{{AUR|snapborg}}}}

=== 自動スナップショット ===

Btrfs スナップショットの管理および自動作成には、[[Snapper]]、[[Timeshift]]、[[Yabsnap]] などのスナップショットマネージャーを使用できます。

=== 自動通知 ===

デスクトップ通知は、重大な Btrfs の問題に即座に気付くのに役立ち、通知がまったくない場合と比較して、より良い認識を提供します。

{{AUR|btrfs-desktop-notification}} 次のイベントにデスクトップ通知を提供します:

* 読み取り専用スナップショットやシステムへのブート。
* dmesg ログに表示される Btrfs の警告、エラー、致命的なメッセージ。

詳細および設定については、https://gitlab.com/Zesko/btrfs-desktop-notification を参照してください。

== トラブルシューティング ==

一般的なトラブルシューティングについては [https://btrfs.wiki.kernel.org/index.php/Problem_FAQ Btrfs Problem FAQ] を見て下さい。

=== GRUB ===

==== パーティションオフセット ====

オフセットの問題は、パーティションのあるディスクに {{ic|core.img}} を埋め込もうとしたときに発生する可能性があります。つまり、GRUB の {{ic|core.img}} をパーティションレスディスク (例: {{ic|/dev/sd''X''}}) の Btrfs プールに直接埋め込んでも [[Special:Diff/319474|大丈夫]] です。

[[GRUB]] は Btrfs パーティションを起動できますが、モジュールが他の [[ファイルシステム]] よりも大きくなる可能性があります。また、{{ic|grub-install}} で作成した {{ic|core.img}} ファイルは、MBR と最初のパーティションの間にあるドライブの最初の 63 セクタ (31.5KiB) に収まらないかもしれません。{{ic|fdisk}} や {{ic|gdisk}} のような最新のパーティションツールは、最初のパーティションをおよそ 1MiB または 2MiB オフセットすることでこの問題を回避しています。

==== root が見つからない ====

RAID セットアップから起動した時にエラー {{ic|1=error no such device: root}} が表示される場合、{{ic|/usr/share/grub/grub-mkconfig_lib}} を編集して {{ic|1=echo " search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}"}} からクォートを削除してください。grub の設定を再生成すればエラーを出さずに起動できるはずです。

=== マウントがタイムアウト ===

特に大きな RAID1 アレイでは、ブート中にマウントがタイムアウトして、次のようなジャーナルメッセージが表示されることがあります。

{{bc|1=
Jan 25 18:05:12 host systemd[1]: storage.mount: Mounting timed out. Terminating.
Jan 25 18:05:46 host systemd[1]: storage.mount: Mount process exited, code=killed, status=15/TERM
Jan 25 18:05:46 host systemd[1]: storage.mount: Failed with result 'timeout'.
Jan 25 18:05:46 host systemd[1]: Failed to mount /storage.
Jan 25 18:05:46 host systemd[1]: Startup finished in 32.943s (firmware) + 3.097s (loader) + 7.247s (kernel)>
Jan 25 18:05:46 host kernel: BTRFS error (device sda): open_ctree failed
}}

この問題は、[[fstab]] のシステム固有のマウントオプション {{ic|x-systemd.mount-timeout}} で長いタイムアウトを指定することで簡単に回避することが可能です。例:

/dev/sda /storage btrfs rw,relatime,x-systemd.mount-timeout=5min 0 0

=== BTRFS: open_ctree failed ===

2014年11月現在、{{ic|mkinitcpio.conf}} で {{ic|btrfs}} フックを使用してマルチデバイスの Btrfs を使っている場合に以下のエラーが発生するというバグが [[systemd]] か [[mkinitcpio]] のどちらかに存在します:

{{bc|<nowiki>
BTRFS: open_ctree failed
mount: wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error

In some cases useful info is found in syslog - try dmesg|tail or so.

You are now being dropped into an emergency shell.
</nowiki>}}

{{ic|/etc/mkinitcpio.conf}} の {{ic|HOOKS}} 行から {{ic|btrfs}} を削除して代わりに {{ic|MODULES}} 行に {{ic|btrfs}} を追加することで解決します。修正を施したら {{ic|mkinitcpio -p linux}} で initramfs を再生成して (必要ならプリセットを調整します) 再起動してください。

デバイスが存在しない raid アレイをマウントしようとしたときも同じエラーが表示されます。その場合は {{ic|/etc/fstab}} に {{ic|degraded}} マウントオプションを追加してください。ルートパーティションがアレイ上にある場合、[[カーネルパラメータ]]に {{ic|1=rootflags=degraded}} を追加してください。

2016年8月現在、このバグの回避策として考えられるのは、{{ic|/etc/fstab}} で単一ドライブのみでアレイをマウントし、他のドライブは btrfs が自動的に発見して追記するようにすることです。UUID や LABEL のようなグループベースの識別子は、この不具合の原因になっているようです。例えば、'disk1' と 'disk2' からなる2デバイスの RAID1 アレイには UUID が割り当てられますが、UUID を使う代わりに {{ic|/dev/mapper/disk1}} のみを {{ic|/etc/fstab}} で使用します。より詳しい説明は、以下の [https://web.archive.org/web/20161108175034/http://blog.samcater.com/fix-for-btrfs-open_ctree-failed-when-running-root-fs-on-raid-1-or-raid10-arch-linux/ ブログ記事] を参照してください。

また、[[mkinitcpio#設定|mkinitcpio.conf]] の {{ic|udev}} フックを削除し、{{ic|systemd}} フックに置き換えることも可能な対処法です。この場合、{{ic|btrfs}} は{{ic|HOOKS}}や{{ic|MODULES}} 配列に ''not'' とする必要があります。

詳細は [https://bbs.archlinux.org/viewtopic.php?id=189845 フォーラムスレッド] や {{Bug|42884}} を見て下さい。

=== btrfs check ===

{{Warning|Btrfs はまだ開発途上であり、特に {{ic|btrfs check}} コマンドについては仕様が固まっていないので、{{ic|--repair}} スイッチを付けて {{ic|btrfs check}} を実行するときはあらかじめ Btrfs のドキュメントを読んでバックアップを作成することを強く推奨します。}}

''[https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-check btrfs check]'' コマンドを使うことでアンマウントされた Btrfs ファイルシステムをチェックしたり修復することが可能です。ただし、この修復ツールはまだ開発中であり、特定のファイルシステムエラーは修復することができません。

=== 絶え間ないドライブアクティビティ ===

[[カーネル]] バージョン 6.2 以降、{{ic|1=discard=async}} {{man|8|mount}} オプションがデフォルトで設定されています。これ [https://lore.kernel.org/linux-btrfs/Y%2F%2Bn1wS%2F4XAH7X1p@nz/#r 報告] により、廃棄キューがいっぱいになると、アイドル状態でも一部のドライブで一定のドライブアクティビティが発生し、処理されるよりも速くなります。これにより、特に NVMe ベースのドライブで電力使用量が増加する可能性があります。

回避策の 1 つは、ドライブのアクティビティが停止するまで破棄 {{ic|iops_limit}} を増やすことです。

これは、[[Wikipedia:sysfs|sysfs]] を使用して実現できます。例:

# echo 1000 > /sys/fs/btrfs/''uuid''/discard/iops_limit

ここで、{{ic|''uuid''}} は btrfs ファイルシステムの UUID です。{{ic|1000}} の制限は実験的に調整する必要があります。

起動時にパラメータを設定するには、[[systemd-tmpfiles]] を使用できます。たとえば、次のファイルを作成します。

{{hc|/etc/tmpfiles.d/btrfs-discard.conf|
w /sys/fs/btrfs/''uuid''/discard/iops_limit - - - - 1000
}}

あるいは、[[fstab]] の {{ic|nodiscard}} マウントオプションを使用してマウントし、代わりに [[ソリッドステートドライブ#定期的な TRIM|定期的な TRIM]] を使用して、非同期破棄を完全に無効にすることもできます。

=== Device total_bytes should be at most X but found Y ===

もしドライブが別のコンピュータから移動されたり、デバイスの順序が変更された場合で、報告されるサイズの差が非常に小さい(最大でも数メガバイト程度)場合、[[Wikipedia:Host protected area|HPA (Host Protected Area)]] が有効になっている可能性があります。

HPA が有効かどうかを確認するには、{{Pkg|hdparm}} を使用します:

# hdparm -N DEVICE

出力には 2 つの数字が表示されます:可視のセクタ数と実際のセクタ数です。これらが異なる場合、HPA が有効になっていることを意味します。

もしマザーボードがこれを強制的に設定し、ファームウェアにそれを無効にするオプションがない場合、唯一の選択肢は影響を受けたファイルシステムを縮小することです。これを行う最も簡単な方法は、元のコンピュータで、または HPA を適用しない任意のマシンで行うことです。

=== No space left on device ===

ブログ記事 [https://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-Btrfs-Filesystem-Full-Problems.html Fixing Btrfs Filesystem Full Problems] では、以下のチェック/手順を提案し、説明しています:

# 今すぐスペースを解放する(履歴スナップショットを削除)
# 本当にファイルシステムが満杯ですか? メタデータおよび/またはデータチャンクのバランスが崩れている({{ic|btrfs balance}} を実行)
# 本当にファイルシステムが満杯ですか? データチャンクのバランスが崩れている
# 本当にファイルシステムが満杯ですか? メタデータのバランスが崩れている
# ファイルシステムが満杯のため、バランスを実行できません({{ic|btrfs device add}} を使用して USB キーやループデバイスなどのデバイスを一時的に Btrfs ファイルシステムに追加してから、{{ic|btrfs balance}} を実行)

== 参照 ==

* '''公式サイト'''
** [https://btrfs.readthedocs.io Btrfs Documentation]
** [https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/ Archived Btrfs Wiki]
* '''パフォーマンス関連'''
** [https://superuser.com/questions/432188/should-i-put-my-multi-device-btrfs-filesystem-on-disk-partitions-or-raw-devices Btrfs on raw disks?]
** [https://lore.kernel.org/linux-btrfs/CAKcLGm_MKEdTiHFBd-b-v2sN5gJmgFRqsykzWRXTVqUw4O6Acw@mail.gmail.com/ Varying leafsize and nodesize in Btrfs]
** [https://lore.kernel.org/linux-btrfs/jgui4j$th5$1@dough.gmane.org/ Btrfs support for efficient SSD operation (data blocks alignment)]
** [https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/FAQ.html#Is_Btrfs_optimized_for_SSD.3F Is Btrfs optimized for SSDs?]
** [https://blog.erdemagaoglu.com/post/4605524309/lzo-vs-snappy-vs-lzf-vs-zlib-a-comparison-of Lzo vs. zLib]
* '''その他'''
** [[Funtoo:BTRFS Fun]]
** [https://www.phoronix.com/scan.php?page=news_item&px=MTA0ODU Avi Miller presenting Btrfs] at SCALE 10x, January 2012.
** [https://www.phoronix.com/scan.php?page=news_item&px=MTA4Mzc Summary of Chris Mason's talk] from LFCS 2012
** [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=35054394c4b3cecd52577c2662c84da1f3e73525 Btrfs: stop providing a bmap operation to avoid swapfile corruptions] 2009-01-21
** [https://marc.merlins.org/perso/btrfs/post_2014-03-22_Btrfs-Tips_-Doing-Fast-Incremental-Backups-With-Btrfs-Send-and-Receive.html Doing Fast Incremental Backups With Btrfs Send and Receive]

Dm-crypt/システム設定

2024-12-20T08:15:19Z

{{Lowercase title}}
[[Category:保存データ暗号化]]
[[en:dm-crypt/System configuration]]
[[es:Dm-crypt (Español)/System configuration]]
[[pt:Dm-crypt (Português)/System configuration]]
[[ru:Dm-crypt (Русский)/System configuration]]

{{Tip|
* ルートファイルシステムや他の初期ブートにおけるファイルシステムをリモートでアンロックする必要がある場合 (ヘッドレスマシンや遠隔地のサーバなど) は、[[dm-crypt/特記事項#root などのパーティションのリモート解除]] の指示に従ってください。
* コマンドの出力を挿入できる[[テキストエディタ]]を使用し、[[永続的なブロックデバイスの命名#永続的な命名の方法|適切な lsblk や blkid コマンド]]を使うことで、設定ファイルにおける UUID や PARTUUID などの入力作業を容易にできます (例えば、[[nano]] での {{ic|Ctrl+t}}、[[Vim]] や [[Neovim]] での {{ic|:read}}、[[mcedit]] での {{ic|Alt+u}})。あるいは、[[アプリケーション一覧/ユーティリティ#ターミナルマルチプレクサ|ターミナルマルチプレクサ]]を使用して、そのコピーペースト機能を使用することもできます。
}}

== 初期ユーザ空間でロックを解除する ==

暗号化されているルートボリュームを起動するには、初期ユーザ空間でそのボリュームのロックを解除するために必要なツールが [[initramfs]] に含まれている必要があります。ロックを解除するべきボリュームは、たいてい[[カーネルパラメータ]]で渡されます。

以下のセクションでは、mkinitcpio の設定方法と、必要なカーネルパラメータのリストを載せています。

=== mkinitcpio ===

場合にもよりますが、以下の [[mkinitcpio#HOOKS|mkinitcpio フック]]の一部は有効化しておく必要があります:

{| class="wikitable"
! busybox !! systemd !! ユースケース
|-
|style="text-align: center;white-space:nowrap;"| {{ic|encrypt}}
|style="text-align: center;white-space:nowrap;"| {{ic|sd-encrypt}}
| ルートパーティションが暗号化されている場合や、何らかの暗号化されているパーティションがルートパーティションのマウントよりも''前に''必要になる場合に必要です。その他の場合においては必要ありません。{{ic|/etc/crypttab}} などのシステム初期化スクリプトが、ルート以外のパーティションのロックを解除してくれるからです。このフックは {{ic|udev}} や {{ic|systemd}} フックよりも''後に''配置しなければなりません。
|-
|colspan="2" style="text-align: center;white-space:nowrap;"| {{ic|keyboard}}
| 初期ユーザ空間でキーボードを動作させるために必要です。

{{Tip|起動するたびにハードウェアの構成が異なるようなシステム (例えば、外部キーボードと内部キーボードのあるノート PC や[[Wikipedia:Headless computer|ヘッドレスシステム]]) では、このフックを {{ic|autodetect}} より前に配置して、全てのキーボードドライバを initramfs に含めると便利です。そうしないと、initramfs イメージの生成時に外部キーボードが接続されていなければ、そのキーボードは初期ユーザ空間では動作しなくなってしまいます。}}
|-
|style="text-align: center;white-space:nowrap;"| {{ic|keymap}}
|rowspan="2" style="text-align: center;white-space:nowrap;"| {{ic|sd-vconsole}}
| 暗号化パスワードの入力において US キーマップ以外のサポートを提供します。このフックは、{{ic|encrypt}} フックよりも''前に''配置しなければなりません。さもないと、暗号化パスワードの入力にデフォルトの US キーマップしか使えません。キーマップは {{ic|/etc/vconsole.conf}} で設定してください ([[Linux コンソール/キーボード設定#永続的な設定]] を参照してください)。
|-
|style="text-align: center;white-space:nowrap;"| {{ic|consolefont}}
| 初期ユーザ空間で代替のコンソールフォントをロードします。フォントは {{ic|/etc/vconsole.conf}} で設定してください ([[Linux コンソール/キーボード設定#永続的な設定]] を参照してください)。
|}

必要な[[mkinitcpio#通常のフック|その他のフック]]は、システムのインストールに関するその他のマニュアルから明らかなはずです。

{{Note|{{ic|/etc/mkinitcpio.conf}} に変更を加えたときは [[initramfs を再生成する]]のを忘れないでください。}}

==== 例 ====

{{ic|encrypt}} フックを使用する典型的な {{ic|/etc/mkinitcpio.conf}} の設定としては、以下のようになります:

{{hc|/etc/mkinitcpio.conf|2=
...
HOOKS=(base '''udev''' autodetect modconf kms keyboard '''keymap''' '''consolefont''' block '''encrypt''' lvm2 filesystems fsck)
...
}}

{{ic|sd-encrypt}} フックを使用する、systemd ベースの initramfs の設定は:

{{hc|/etc/mkinitcpio.conf|2=
...
HOOKS=(base '''systemd''' autodetect modconf kms keyboard '''sd-vconsole''' block '''sd-encrypt''' lvm2 filesystems fsck)
...
}}

=== カーネルパラメータ ===

必要な[[カーネルパラメータ]]は、{{ic|encrypt}} フックと {{ic|sd-encrypt}} フックのどちらを使うかによります。{{ic|root}} と {{ic|resume}} は両方において同じように指定します。

{{Tip|{{ic|sd-encrypt}} フックと [[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]]を使用する場合、これらのカーネルパラメータの指定は省略できます。[[dm-crypt/システム全体の暗号化#ブートローダーの設定]] を参照してください。}}

==== root ====

{{ic|1=root=}} パラメータでは、実際の (暗号化の解除された) ルートファイルシステムの {{ic|''device''}} を指定します:

root=''device''

* ルートファイルシステムが、暗号化の解除されたデバイスファイル上に直接フォーマットされている場合、このパラメータの引数は {{ic|/dev/mapper/''dmname''}} になります。
* 最初に LVM がアクティブ化されていて、そこに[[dm-crypt/システム全体の暗号化#LUKS on LVM|暗号化されている論理ルートボリューム]]が存在している場合、引数は上記の形式と同じになります。
* ルートファイルシステムが、完全に[[dm-crypt/システム全体の暗号化#LVM on LUKS|暗号化されている LVM]] の論理ボリューム内に存在している場合、デバイスマッパーは一般に {{ic|1=root=/dev/''volumegroup''/''logicalvolume''}} となります。

{{Tip|[[GRUB]] を使用していて、''grub-mkconfig'' で {{ic|grub.cfg}} を生成する場合は、{{ic|1=root=}} パラメータを手動で指定する必要はありません。''grub-mkconfig'' は、暗号化の解除されたルートファイルシステムの適切な UUID を検出し、その UUID を {{ic|grub.cfg}} へ自動的に追加します。}}

==== resume ====

resume=''device''

* {{ic|''device''}} は、[[電源管理/サスペンドとハイバネート#ハイバネーション|suspend to disk (ハイバネーション)]] で使用される、暗号化の解除された (スワップ) ファイルシステムのデバイスファイルです。スワップが個別のパーティション上にある場合は、{{ic|/dev/mapper/swap}} という形式になります。[[dm-crypt/スワップの暗号化]] も参照してください。

==== encrypt フックを使う ====

{{Note|[[sd-encrypt]] フックと比べて、{{ic|encrypt}} フックは以下をサポートしていません:
* [[dm-crypt/特記事項#encrypt フックと複数のディスク|複数の暗号化ディスク]]のロック解除 ({{Bug|23182}})。initramfs 内で '''一つ'''のデバイスしかロックを解除できません。
* [[dm-crypt/特記事項#リモート LUKS ヘッダーを使ってシステムを暗号化|デタッチされた LUKS ヘッダ]]の使用 ({{Bug|42851}})。
* [[#crypttab|crypttab]] によってサポートされている追加オプションの設定 (例: {{ic|sector-size}}) ({{Bug|72119}})。
}}

===== cryptdevice =====

このパラメータでは、コールドブート時に暗号化済みルートファイルシステムを含むデバイスを指定します。これは、{{ic|encrypt}} フックによってパースされ、どのデバイスに暗号化されているシステムが含まれているかを特定します:

cryptdevice=''device'':''dmname'':''options''

* {{ic|''device''}} は、暗号化されたデバイスのバッキングデバイスへのパスです。[[永続的なブロックデバイスの命名]]を使うことを強く推奨します。
* {{ic|''dmname''}} は復号後にデバイスに与えられる '''d'''evice-'''m'''apper の名前です。{{ic|/dev/mapper/''dmname''}} として使用できるようになります。
* {{ic|''options''}} (オプション) は、コンマで区切られたオプションです (TRIM サポートなど用)。オプションが必要ないのであれば、このパラメータは省略してください ({{ic|1=cryptdevice=''device'':''dmname''}})。
* LVM に[[Dm-crypt/システム全体の暗号化#LUKS on LVM|暗号化されたルート]]が含まれる場合、最初に LVM が有効になって暗号化されたルートの論理ボリュームを含むボリュームグループが ''device'' として使用できるようになります。それからボリュームグループがルートにマッピングされます。パラメータは {{ic|1=cryptdevice=''/dev/vgname/lvname'':''dmname''}} という形式になります。

{{Tip|ソリッドステートドライブ (SSD) に対しては、[[dm-crypt/特記事項#ソリッドステートドライブ (SSD) の Discard/TRIM のサポート|Discard/TRIM のサポートを有効化する]]と良いかもしれません。}}

===== cryptkey =====

{{Tip|パスフレーズを使用するのであれば、{{ic|1=cryptkey=}} パラメータを手動で指定する必要はありません。その場合、ブート時にパスフレーズを入力するためのプロンプトが表示されます。}}

このパラメータはキーファイルの場所を指定します。{{ic|''encrypt''}} フックがそのキーファイルを読み込んで {{ic|''cryptdevice''}} のロックを解除するために必要です。(鍵がデフォルトの場所にある場合を除き (以下を参照)) キーファイルが特定のデバイスにファイルとして存在するか、特定の場所から始まるビットストリームであるか、initramfs にファイルとして存在するかによって、3つのパラメータセットを持つことができます。

デバイス内のファイルの場合、形式は以下のようになります:

cryptkey=''device'':''fstype'':''path''

* {{ic|''device''}}: キーが存在する raw ブロックデバイス。[[永続的なブロックデバイスの命名]]を使うことを強く推奨します。
* {{ic|''fstype''}}: {{ic|''device''}} のファイルシステムのタイプ (auto を指定することも可)。
* {{ic|''path''}}: デバイス内のキーファイルの絶対パス。

例: {{ic|1=cryptkey=LABEL=usbstick:vfat:/secretkey}}

デバイス上のビットストリームの場合、キーの場所は次のように指定されます:

For a bitstream on a device the key's location is specified with the following:

cryptkey=''device'':''offset'':''size''

ここで、オフセットとサイズはバイト単位です。例えば、{{ic|1=cryptkey=UUID=''ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ'':0:512}} は、デバイスの先頭にある 512 バイトのキーファイルを読み込みます。

{{Tip|アクセスしたいデバイスのパスに {{ic|:}} 文字が含まれている場合、その文字をバックスラッシュ {{ic|\}} でエスケープしなければなりません。そのような場合、cryptkey パラメータは次のような見た目になります: ID {{ic|usb-123456-0:0}} の USB キーの場合、{{ic|1=cryptkey=/dev/disk/by-id/usb-123456-0\:0:0:512}}。}}

Initramfs 内に[[mkinitcpio#BINARIES と FILES|含められている]]ファイルの場合、形式は次のようになります[https://gitlab.archlinux.org/archlinux/packaging/packages/cryptsetup/-/blob/main/hooks-encrypt#L14]:

cryptkey=rootfs:''path''

例: {{ic|1=cryptkey=rootfs:/secretkey}}

また、{{ic|cryptkey}} が指定されない場合、デフォルトで (initramfs 内の) {{ic|/crypto_keyfile.bin}} が指定されたものとみなされることに注意してください。[https://gitlab.archlinux.org/archlinux/packaging/packages/cryptsetup/-/blob/main/hooks-encrypt#L8]

[[dm-crypt/デバイスの暗号化#キーファイル]] も参照してください。

===== crypto =====

これは、''dm-crypt'' プレーンモードのオプションを ''encrypt'' フックに渡すための固有のパラメータです。

以下の形式を取ります:

crypto=''hash'':''cipher'':''keysize'':''offset'':''skip''

引数は、''cryptsetup'' のオプションと直接関連します。[[Dm-crypt/デバイスの暗号化#plain モードの暗号化オプション]] を参照してください。

''plain'' のデフォルトオプションのみで暗号化されたディスクの場合、{{ic|crypto}} 引数を指定しなければなりませんが、各エントリは空白のままにすることができます:

crypto=::::

引数の具体的な例は以下の通りです:

crypto=sha512:twofish-xts-plain64:512:0:

==== systemd-cryptsetup-generator を使う ====

''systemd-cryptsetup-generator'' は、暗号化されたデバイスのロックを解除するために、[[カーネルパラメータ]]のサブセットと {{ic|/etc/crypttab}} を読み込む [[systemd]] ユニットジェネレータです。このジェネレータに関する詳細やサポートされている全オプションについては、{{man|8|systemd-cryptsetup-generator}} man ページを参照してください。

''systemd-cryptsetup-generator'' は、{{ic|sd-encrypt}} [[Mkinitcpio#HOOKS|mkinitcpio フック]]や {{ic|systemd}} [[Dracut#Dracut モジュール|dracut モジュール]]が使用される [[Arch ブートプロセス#initramfs|initramfs の段階]]で実行されます。

以下では、''systemd-cryptsetup-generator'' によって使用される[[カーネルパラメータ]]の一部を説明します。

{{Tip|
* {{ic|/etc/crypttab.initramfs}} ファイルが存在する場合、{{ic|/etc/crypttab}} として initramfs に追加されます。このファイルには、initramfs の段階でロックを解除する必要のあるデバイスを指定できます。このファイルの構文は [[#crypttab]] を参照してください。{{ic|/etc/crypttab.initramfs}} が存在しない場合、{{ic|/etc/crypttab}} は initramfs に追加されず、ロック解除可能なデバイスは以下に挙げるカーネルパラメータで指定する必要があります。
* {{ic|/etc/crypttab.initramfs}} では、{{ic|rd.luks}} のように UUID 以外も使用できます。[[永続的なブロックデバイスの命名#永続的な命名の方法|永続的なブロックデバイスの命名方法]]のうち任意のものを使用できます。
* ブート中に入力されたパスワードは {{man|8|systemd-cryptsetup}} によってカーネルのキーリングにキャッシュされます。なので、同じパスワードで複数のデバイスのロックを解除できる場合 (これには、ブート後にロックを解除される [[#crypttab|crypttab]] 内のデバイスも含まれます)、そのパスワードの入力は1度だけで済みます。
}}

{{Note|
* {{ic|rd.luks}} パラメータ群はすべて複数回指定することが可能であり、LUKS で暗号化された複数のボリュームのロックを解除できます。
* {{ic|rd.luks}} パラメータは LUKS デバイスのロック解除のみをサポートしています。Plain な dm-crypt デバイスのロックを解除するには、そのデバイスを {{ic|/etc/crypttab.initramfs}} 内で指定しなければなりません。このファイルの構文は [[#crypttab]] を参照してください。
}}

{{Warning|{{ic|/etc/crypttab}} か {{ic|/etc/crypttab.initramfs}} を使用していて、かつ {{ic|luks.*}} パラメータか {{ic|rd.luks.*}} パラメータも使用している場合、カーネルコマンドラインで指定されたデバイスしかアクティブ化されず、{{ic|Not creating device 'devicename' because it was not specified on the kernel command line.}} というメッセージが表示されます。これは、{{ic|luks.*}} パラメータや {{ic|rd.luks.*}} パラメータが、crypttab のデバイスのうちどれをアクティブ化するかを制御するからです。{{ic|/etc/crypttab}} 内の全デバイスをアクティブ化するには、{{ic|luks.*}} パラメータを使用せず、{{ic|rd.luks.*}} を使用してください。{{ic|/etc/crypttab.initramfs}} 内の全デバイスをアクティブ化するには、{{ic|luks.*}} も {{ic|rd.luks.*}} も使用しないでください。}}

===== rd.luks.uuid =====

{{Tip|{{ic|rd.luks.name}} を使用する場合、{{ic|rd.luks.uuid}} は省略できます。}}

rd.luks.uuid=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''

ブート時に復号するデバイスの [[UUID]] をこのフラグで指定します。

デフォルトでは、マッピングされたデバイスは、{{ic|/dev/mapper/luks-''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''}} に配置されます。''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'' は LUKS パーティションの UUID です。

===== rd.luks.name =====

{{Tip|このパラメータを使用する場合、{{ic|rd.luks.uuid}} は省略できます。}}

rd.luks.name=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''=''name''

LUKS パーティションが開かれたあとにマッピングされるデバイスの名前を指定します。''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'' は LUKS パーティションの UUID です。これは、{{ic|encrypt}} の {{ic|cryptdevice}} の第2パラメータと等価です。

例えば、{{ic|1=rd.luks.name=12345678-9abc-def0-1234-56789abcdef0=root}} を指定すると、UUID {{ic|12345678-9ABC-DEF0-1234-56789ABCDEF0}} のロック解除された LUKS デバイスは、{{ic|/dev/mapper/root}} に配置されます。

===== rd.luks.key =====

UUID で指定されたデバイスを復号する際に用いるパスワードファイルの場所を指定します。{{ic|encrypt}} フックの {{ic|cryptkey}} パラメータにあるようなデフォルトの場所は存在しません。

キーファイルが [[mkinitcpio#BINARIES と FILES|initramfs 内に含まれている]]場合は:

rd.luks.key=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''=''/path/to/keyfile''

あるいは

rd.luks.key=''/path/to/keyfile''

{{Tip|キーファイルが {{ic|/etc/cryptsetup-keys.d/''name''.key}} として含まれている場合、{{ic|rd.luks.key}} パラメータは完全に省略できます。}}

キーファイルが他のデバイス上に存在する場合は:

rd.luks.key=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''=''/path/to/keyfile'':UUID=''ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ''

{{ic|1=UUID=''ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ''}} の部分は、キーファイルの存在するデバイスの識別子に置き換えてください。

{{Warning|
* ファイルシステムの種類がルートファイルシステムのものと異なる場合は、[[mkinitcpio#MODULES|そのファイルシステム用のカーネルモジュールを initramfs 内に含める]]必要があります。
* {{ic|rd.luks.key}} で他のデバイス上のキーファイルを指定した場合、デバイスが利用できない場合にデフォルトではパスワードプロンプトにフォールバックしません。パスワードプロンプトにフォールバックさせるには、{{ic|rd.luks.options}} で {{ic|1=keyfile-timeout=}} を指定してください。例えば、10秒のタイムアウトを設定するには: {{bc|1=rd.luks.options=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''=keyfile-timeout=10s}}。
}}

===== rd.luks.options =====

rd.luks.options=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''=''options''

または

rd.luks.options=''options''

UUID を指定した場合、そのデバイスに対してオプションを設定します。UUID を指定しなかった場合、他の場所 (例えば crypttab) で指定しなかった全デバイスに対してオプションを設定します。

このパラメータは [[#crypttab|crypttab]] のオプションフィールドに似ています。形式は同じです。オプションはコンマで区切られ、値のあるオプションは {{ic|1=''option''=''value''}} のように指定します。これは、{{ic|encrypt}} の {{ic|cryptdevice}} の第3パラメータとほぼ等価です。

例えば:

rd.luks.options=timeout=10s,discard,password-echo=no,tries=1

====== タイムアウト ======

ブート中にパスワードを入力する際のタイムアウトを設定するオプションは2つあります:

* {{ic|1=rd.luks.options=timeout=''mytimeout''}} は、パスワードをクエリする際のタイムアウトを指定します。
* {{ic|1=rootflags=x-systemd.device-timeout=''mytimeout''}} は、rootfs デバイスが現れるまで systemd がどれだけ待つかを指定します (デフォルトは 90 秒)。

タイムアウトを両方無効化したい場合は、両方のタイムアウトをゼロに設定してください:

rd.luks.options=timeout=0 rootflags=x-systemd.device-timeout=0

====== Password echo ======

ユーザがパスワードを入力する際、''systemd-cryptsetup'' はデフォルトで、入力された各文字をアスタリスク ({{ic|*}}) として表示します。これは {{ic|encrypt}} の挙動とは異なります ({{ic|encrypt}} は何も表示しません)。何も表示させないようにするには、{{ic|1=password-echo=no}} オプションを設定してください:

rd.luks.options=password-echo=no

====== Trusted Platform Module と FIDO2 鍵 ======

あなたのシステム上で [[TPM|TPM2]] チップが利用可能である、あるいは FIDO2 互換のセキュリティキーを使用している場合、パスワードやキーファイルを使わずにボリュームのロックを自動的に解除できます。

{{ic|rd.luks.uuid}} か {{ic|rd.luks.name}} に加えて、以下を設定してください:
* TPM2 チップの場合: {{ic|1=rd.luks.options=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''=tpm2-device=auto}}
* FIDO2 鍵の場合: {{ic|1=rd.luks.options=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''=fido2-device=auto}}

あるいは、{{ic|/etc/crypttab.initramfs}} を使えば、カーネルオプションで指定する必要はありません。

{{hc|/etc/crypttab.initramfs|2=
root UUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'' none tpm2-device=auto
}}

{{Note|{{ic|/etc/crypttab.initramfs}} に変更を加えた後に [[initramfs を再生成する]]ことを忘れないでください。}}

ここでは、暗号化されたボリュームは {{ic|root}} という名前で ({{ic|/dev/mapper/root}} に) マウントされます。対象のストレージデバイスの UUID でマウントされ、パスワードは使われず、TPM2 デバイスからキーが取得されます。

TPM2 デバイスを使用するにはパスワードのフィールドに {{ic|none}} を指定しなければならないことに注意してください。さもないと、与えられた値がパスワードか鍵として使用されてしまい、それがうまくいかなかった場合に TPM2 デバイスからキーを読み込もうとせずにパスワードプロンプトが表示してしまいます。

上記のようにデバイスを UUID で指定する場合、それが基底のストレージデバイス (つまり、暗号化されているデバイス自体) の UUID であるを確認してください (他の場所でルートファイルシステムとして指定される、復号さらた後のボリュームの UUID ではありません)。

===== rd.luks.data =====

デタッチされた LUKS ヘッダを使用する場合、暗号化されたデータが含まれるブロックデバイスを指定してください。ヘッダファイルの場所は {{ic|rd.luks.options}} で指定する必要があります。

詳細や方法は [[dm-crypt/特記事項#リモート LUKS ヘッダーを使ってシステムを暗号化]] を参照してください。

== 後期ユーザ空間でロックを解除する ==

=== crypttab ===

{{ic|/etc/crypttab}} (encrypted device table) ファイルには、システムの起動時にロックを解除する暗号化デバイスのリストを記述します。[[fstab]] と似ています。このファイルを使うことで、暗号化したスワップデバイスやセカンダリファイルシステムを自動でマウントすることが可能です。

{{ic|crypttab}} は {{ic|fstab}} より''前に''読み込まれます。dm-crypt コンテナを、その内部に存在するファイルシステムよりも前にアンロックできるようにするためです。{{ic|crypttab}} は、システムの起動した''後に''読み込まれることに注意してください。よってこの方法は、[[dm-crypt/システム全体の暗号化|ルートパーティションを暗号化する]]場合のように、[[#mkinitcpio|mkinitcpio]] フックを使用して暗号化済みのパーティションのロックを解除する方法や、[[#カーネルパラメータ|カーネルパラメータを使用して設定する]]方法の代わりではありません。{{ic|crypttab}} は、{{ic|systemd-cryptsetup-generator}} によってブート時に自動的に処理されます。

詳細は {{man|5|crypttab}} を参照してください。以下にはいくつかの例を載せています。暗号化されたデバイスをマウントするために UUID を使用する方法については [[#ブート時にマウントする]] セクションを参照してください。

{{Warning|
* {{ic|nofail}} オプションが指定された場合、パスワードの入力中にパスワード入力画面が消えてしまうことがあります。なので、{{ic|nofail}} はキーファイルを使用する場合にのみ使ってください。
* [[dm-crypt/デバイスの暗号化#plain モードの暗号化オプション|dm-crypt の plain モード]]のデバイスの場合、{{ic|systemd-cryptsetup}} にそれらのデバイスを強制的に認識させるために、{{ic|plain}} オプションを明示的に設定しなければなりません。[https://github.com/systemd/systemd/issues/442 systemd issue 442] を参照してください。
}}

{{hc|/etc/crypttab|2=
# crypttab ファイルの例。フィールドは左から: 名前、バッキングデバイス、パスフレーズ、cryptsetup オプション。

# /dev/lvm/swap をマウントし、ブート毎に新しいキーで再暗号化する。
swap /dev/lvm/swap /dev/urandom swap,cipher=aes-xts-plain64,size=256

# /dev/lvm/tmp を /dev/mapper/tmp としてマウントし、plain dm-crypt でランダムなパスフレーズを使うことで、アンマウント後にコンテンツを読めなくする。
tmp /dev/lvm/tmp /dev/urandom tmp,cipher=aes-xts-plain64,size=256

# LUKS を使って /dev/lvm/home を /dev/mapper/home としてマウントする。ブート時にパスフレーズのプロンプトを表示する。
home /dev/lvm/home

# LUKS を使って /dev/sdb1 を /dev/mapper/backup としてマウントする。パスフレーズはファイルに保存してある。
backup /dev/sdb1 /home/alice/backup.key

# 唯一の利用可能な TPM を使って /dev/sdX のロックを解除し、myvolume に名称変更する。
myvolume /dev/sdX none tpm2-device=auto
}}

有効化した後にすぐ crypttab をテストするには、[[daemon-reload]] で systemd マネージャの設定を再読み込みし、新しく生成された {{ic|systemd-cryptsetup@''name''.service}} を[[開始]]してください。

{{hc|# cryptsetup status ''name''|2=
/dev/mapper/''name'' is active.
type: ...
cipher: ...
keysize: ... bits
key location: ...
device: /dev/sdxN
sector size: ...
offset: ... sectors
size: ... sectors
mode: ...
flags: ...
}}

{{ic|systemd-cryptsetup@''name''.service}} に関する他の情報は、[[#必要に応じてマウントする]] を参照してください。

{{Tip|GPT と特定のパーティションタイプ UUID を使用する場合、systemd で一部のマウントポイントに対しては crypttab と fstab を使わなくても済みます。詳細は、[[systemd#GPT パーティションの自動マウント]]。}}

==== ブート時にマウントする ====

暗号化されたドライブをブート時にマウントしたい場合、デバイスの UUID を {{ic|/etc/crypttab}} に記述してください。UUID (パーティション) を {{ic|lsblk -f}} コマンドで得て、それを {{ic|crypttab}} 内に以下の形式で追加してください:

{{hc|/etc/crypttab|2=
externaldrive UUID=2f9a8428-ac69-478a-88a2-4aa458565431 none timeout=180
}}

最初のパラメータは、暗号化されたドライブに使用するデバイスマッパーの名前です。自由に指定してください。{{ic|none}} オプションは、起動中にパーティションのロックを解除するためのパスフレーズを入力するプロンプトをトリガーします。{{ic|timeout}} オプションは、ブート時に復号パスワードを入力するタイムアウトを秒単位で定義します。

{{Tip|パスワードプロンプトに入力されたパスワードは、{{man|8|systemd-cryptsetup}} によってカーネルのキーリング内にキャッシュされます ([[#systemd-cryptsetup-generator を使う|sd-encrypt フックを使用する]]場合、initramfs の段階で入力されたパスワードも該当します)。{{ic|crypttab}} に記述されているデバイスが、以前入力したパスワードを使用する場合、3番目のパラメータは {{ic|none}} にすることができ、キャッシュされているパスワードが自動的に使用されます。}}

{{Note|{{ic|crypttab}} における {{ic|timeout}} オプションは、暗号化されたデバイスの''パスワードを入力する''ことのできる時間だけを決定することを留意しておいてください。加えて [[systemd]] には、''デバイスが利用可能になる''までの許容時間を決定するデフォルトのタイムアウト (デフォルトでは 90 秒) が存在し、これはパスワードのタイマーとは独立しています。その結果、{{ic|crypttab}} において {{ic|timeout}} オプションが 90 秒より大きい値に設定された場合 (あるいは、時間無制限を意味するデフォルトの 0 に設定した場合) でも、''systemd'' は依然として、デバイスがアンロックされるまで最大 90 秒までしか待ちません。''systemd'' がデバイスが利用可能になるまで待機する時間を変更するために、{{ic|x-systemd.device-timeout}} ({{man|5|systemd.mount}} を参照) を [[fstab]] 内で対象のデバイスに対して設定することができます。このとき、ブート時にマウントされるデバイスそれぞれに対して、{{ic|crypttab}} における {{ic|timeout}} オプションの値は、{{ic|fstab}} における {{ic|x-systemd.device-timeout}} の値と同じにすることが望ましいでしょう。}}

===== キーファイルでロックを解除する =====

セカンダリファイルシステムの[[dm-crypt/デバイスの暗号化#キーファイル|キーファイル]]が、暗号化されたルートファイルシステム内に保存されている場合、キーファイルはシステムの電源が落ちている間は安全であり、[[#crypttab|crypttab]] を使ってブート中にキーファイルを自動的に読み込んでロックを解除することができます。例えば、[[UUID]] によって指定された crypt をアンロックするには:

{{hc|/etc/crypttab|2=
home-crypt UUID=''UUID-identifier'' /etc/cryptsetup-keys.d/home-crypt.key
}}

{{Tip|
* キーファイルが指定されなかった場合、{{man|8|systemd-cryptsetup}} は自動的に {{ic|/etc/cryptsetup-keys.d/''name''.key}} と {{ic|/run/cryptsetup-keys.d/''name''.key}} から読み込もうと試みます。[https://github.com/systemd/systemd/pull/15637]
* {{ic|--plain}} モードのブロックデバイスを使用したい場合、そのデバイスのロック解除に必要な暗号化オプションは {{ic|/etc/crypttab}} 内に指定します。この場合、[[#crypttab|crypttab]] で説明した systemd の回避策を適用する必要があることに注意してください。
}}

そして、({{ic|/etc/crypttab}} で定義した) デバイスマッパーの名前を使用して {{ic|/etc/fstab}} 内にエントリを作成してください:

{{hc|/etc/fstab|
/dev/mapper/home-crypt /home ext4 defaults 0 2
}}

{{ic|/dev/mapper/externaldrive}} はユニークなパーティションマッピングによるものなので、UUID を使って指定する必要はありません。いかなる場合でも、ファイルシステムに対応するマッパーは、そのファイルシステムが存在しているパーティションとは異なる UUID を持っています。

===== スタックされたブロックデバイスをマウントする =====

また、この systemd ジェネレータは、スタックされたブロックデバイスをブート時に自動的に処理します。

例えば、[[RAID]] 環境を作成し、そこに cryptsetup を使い、暗号化されたブロックデバイス内にそれぞれのファイルシステムを持つ [[LVM]] 論理ボリュームを作成することができます:

{{hc|$ lsblk -f|
─sdXX linux_raid_member
│ └─md0 crypto_LUKS
│ └─cryptedbackup LVM2_member
│ └─vgraid-lvraid ext4 /mnt/backup
└─sdYY linux_raid_member
└─md0 crypto_LUKS
└─cryptedbackup LVM2_member
└─vgraid-lvraid ext4 /mnt/backup
}}

これは、ブート時にパスフレーズが要求し、自動的にマウントします。

対応する正しい crypttab (例えば {{ic|crypto_LUKS}} デバイスの UUID) と fstab ({{ic|/dev/vgraid/lvraid}}) エントリを指定すれば、{{ic|/etc/crypttab}} の処理はルート以外のマウントにのみ適用されるので、mkinitcpio フック/設定を追加する必要がありません。例外として、{{ic|mdadm_udev}} フックが''すでに''使われている場合 (例:ルートデバイス用) です。この場合、正しい root raid が最初に選ばれるように {{ic|/etc/madadm.conf}} と initramfs を更新する必要があります。

==== 必要に応じてマウントする ====

以下のコマンドを使用する代わりとして

# cryptsetup open UUID=... externaldrive

以下のように {{ic|/etc/crypttab}} 内にエントリが存在する場合は、{{ic|systemd-cryptsetup@externaldrive.service}} を[[開始]]することができます:

{{hc|/etc/crypttab|output=
externaldrive UUID=... none noauto
}}

この方法では、正確な crypttab オプションを覚えておく必要はありません。必要であれば、パスフレーズのプロンプトが表示されます。

対応するユニットファイルは {{man|8|systemd-cryptsetup-generator}} によって自動的に生成されます。生成されたユニットファイルは全て以下のコマンドで一覧表示できます:

$ systemctl list-unit-files | grep systemd-cryptsetup

== トラブルシューティング ==

=== システムがブート時に固まる/パスワードプロンプトが表示されない ===

[[Plymouth]] を使用する場合、適切なモジュール ([[Plymouth#mkinitcpio]] を参照) を使用するか、Plymouth を無効化してください。正しく設定しないと Plymouth によってパスワードプロンプトが隠れてしまい、システムを起動できなくなります。

=== キーボードやファイルシステム上のキーファイルをロック解除に利用できない ===

キーボードや、initramfs の生成時に存在しないファイルシステム上のキーファイルを使って LUKS デバイスのロックを解除する場合、対応するモジュールを mkinitcpio の {{ic|MODULES}} 配列に追加する必要があるかもしれません。この作業は、キーボードが USB ハブ経由で接続されている場合にも必要かもしれません。この問題に関する詳細は [[mkinitcpio#MODULES]] を参照してください。追加するべきキーボードやファイルシステムのモジュール名を探し当てる方法については [[mkinitcpio/Initramfs の最小化#モジュールの選別]] を参照してください

一般に、initramfs の生成時に PC に接続されていないキーボードに関しては、{{ic|autodetect}} フックより前に {{ic|keyboard}} を配置する必要があります。さもないと、現在接続されているハードウェアに必要なモジュールしか initramfs に追加されません。[[mkinitcpio#通常のフック]] を参照してください。

{{TranslationStatus|dm-crypt/System configuration|2023-09-04|784929}}

セキュリティ

2024-06-02T23:10:45Z

N: /* Linux Containers */

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
[[zh-hans:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事では Arch Linux システムを防御するための推奨事項とベストプラクティスを並べています。

==概念==
*セキュリティを厳しくするあまりシステムが使い物にならなくなってしまう可能性があります。うまいやり方は度を越さない程度にセキュリティを強化します。
*セキュリティを高めるために出来ることは数多く存在しますが、一番の脅威はいつだってユーザー自身です。セキュリティを考える時は、多層防御を考える必要があります。ある層が突破されたとしても、他の層が攻撃を防御しなくてはなりません。ただし全てのネットワークからマシンを切断して、金庫にしまって決して使わないかぎり、システムを100%セキュアにすることは不可能です。
*少しだけ病的なまでの心配性 (パラノイド) になりましょう。それは役に立ちます。そして疑り深くなってください。話がうますぎるように聞こえたら、おそらくその通りです。
*[[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部位は使用に必要なことにだけしかアクセスできないようにするべきで、それ以上は必要ありません。

==パスワード==
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

===強力なパスワードの選び方===

パスワードは簡単に[[Wikipedia:ja:パスワードクラック|割り出されたり]]または個人情報から類推されないようにすることが重要です。そういうわけで、辞書に載っている単語やあなたの飼っている犬の名前などは使わないようにしましょう。パスワードは出来るだけ8文字以上で、小文字と大文字を混ぜてください。さらに数字や特殊文字も1文字以上含めると良いでしょう。当たり前ですが、長くて複雑なパスワードが基本的に良いパスワードとされます。

{{Pkg|pwgen}} や {{AUR|apg}} などのツールは安全なパスワードを生成するのに役立ちます。

また、ある文章の各単語の一番最初を取ってパスワードを作ることもできます。
例えば “the girl is walking down the rainy street” なら “t6!WdtR5” とパスワードにすることができます。この方法はパスワードを覚えるのをずっと簡単にしてくれます。さらに、入力するのが面倒くさくなりますがパスワードを “The girl is walking down the rainy street" にすることも可能です。

===パスワードの管理===
強固なパスワードを選び出したら、それを安全に保管してください。[[Wikipedia:ja:ソーシャル・エンジニアリング|心理操作]]や[[Wikipedia:Shoulder surfing (computer security)|ショルダーサーフィン]]に注意したり、セキュアでないサーバーから必要以上に情報が流出するのをふせぐためにパスワードを再利用しないようにしてください。{{Pkg|pass}}, {{AUR|keepassx}}, {{Pkg|gnome-keyring}} などのツールは大量の複雑なパスワードを管理するのに役立ちます。[[Wikipedia:ja:LastPass|Lastpass]] はデバイス間で同期するためにオンラインで暗号化されたパスワードを保存するサービスですが、クローズドソースのコードと外部の企業の両方を信頼する必要があります。

概して、安全なパスワードは覚えにくいからといって安全でないパスワードを使ってはいけません。パスワードはバランスを取る必要があります。弱いパスワードをたくさん作るよりは、安全なパスワードの暗号化されたデータベースを作り、一つの強いマスターパスワードで守るほうが良いでしょう。パスワードを紙に書くのも、物理的なセキュリティを必要としますがソフトウェアの脆弱性を防ぐ点では同じくらい有効です [https://www.schneier.com/blog/archives/2005/06/write_down_your.html]。

===パスワードのハッシュ===
{{Warning|SHA512 は高速なハッシュ関数として設計されており、パスワードのハッシュ用には作られていません。bcrypt や scrypt などに比べて SHA512 によってハッシュ化されたパスワードには攻撃者は''はるかに''高速にブルートフォース攻撃をすることができます。}}

デフォルトの Arch のハッシュ [[SHA パスワードハッシュ|sha512]] はとても強固で変更する必要はありません。デフォルトでは、{{ic|/etc/shadow}} にパスワードがハッシュ化されて保存され、root にだけ読み取り許可を与え、{{ic|/etc/passwd}} にはユーザー識別子だけが保存されます。従って、[[#root の制限|root ユーザーが安全]]である限り、ファイルが外部システムにコピーされたり解読されることはありえません。

パスワードは '''passwd''' コマンドで設定され、[[Wikipedia:Key stretching|キーストレッチング]] と [[Wikipedia:Crypt (C)|crypt]] 関数を用いて、{{ic|/etc/shadow}} に保存されます。[[SHA パスワードハッシュ]]も参照してください。また、パスワードは [[Wikipedia:Salt (cryptography)|ソルティング]] されており、[[Wikipedia:Rainbow table|レインボーテーブル]] 攻撃から防御しています。

[http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)] も参照してください。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_cracklib'' は[[Wikipedia:ja:辞書攻撃|辞書攻撃]]からの防御を提供し、システム全体で強制するパスワードポリシーの設定を補助します。

{{Warning|''root'' アカウントはこのポリシーの影響を受けません。}}
{{Note|''root'' アカウントを利用することで望ましい/設定されたポリシーを迂回したユーザーのパスワードを設定することができます。これは一時的なパスワードを設定するときに便利です。}}

例えば以下のようなポリシーを強制させたい場合:
* エラー時に2回パスワードプロンプト
* 最小で10文字の長さ (minlen オプション)
* 新しくパスワードを設定する場合、少なくとも6文字は古いパスワードと異なる (difok オプション)
* 少なくとも1文字数字を含む (dcredit オプション)
* 少なくとも1文字は大文字を含む (ucredit オプション)
* 少なくとも1文字は異なる文字を含む (ocredit オプション)
* 少なくとも1文字は小文字を含む (lcredit オプション)

{{ic|/etc/pam.d/passwd}} ファイルを以下のように書き換えます:
{{bc|1=
#%PAM-1.0
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} でパスワードのプロンプトを表示するときに ''pam_unix'' モジュールではなく ''pam_cracklib'' によるプロンプトを使うようになります。

詳細な情報については pam_cracklib(8) と pam_unix(8) の man ページを参照してください。

== CPU ==

=== マイクロコード ===

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。

=== ハードウェアの脆弱性 ===

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

==== 同時マルチスレッディング (ハイパースレッディング) ====

[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

== メモリ ==

===ハード化された malloc ===

[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが（支援とプルリクエストは歓迎します）、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパースクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に[[#パスワード|強固なパスフレーズ]]による完全ディスク暗号化は、物理的なリカバリからデータを守る唯一の方法です。コンピュータの電源がオフになっていて問題のディスクがアンマウントされている時は完璧なセキュリティを提供します。

しかしながら、コンピュータの電源が入れられてドライブがマウントされると、そのデータは暗号化されていないドライブと同じように無防備になります。そのためデータが必要なくなったときはすぐにデータのパーティションをアンマウントするのが最善です。

[[Dm-crypt]] など特定のプログラムでは、ループファイルを物理ボリュームとして暗号化することができます。これはシステムの特定部分だけを守りたいときに完全なディスク暗号化の代わりの選択肢となりえます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小権限の原則に従って、パーティションは (機能性を失わない限りで) 最も制限的なマウントオプションを使ってマウントすると良いでしょう。

*{{ic|nodev}}: ファイルシステム上のキャラクタ・ブロック特殊デバイスを解釈しない。
*{{ic|nosuid}}: set-user-identifier や set-group-identifier ビットの効果を許可しない。
*{{ic|noexec}}: マウントされたファイルシステム上の全てのバイナリの直接実行を許可しない。

{{Note|データパーティションはいつでも {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}} でマウントするべきです。}}

{| class="wikitable"
| align="center" |'''パーティション'''
| align="center" |{{ic|nodev}}
| align="center" |{{ic|nosuid}}
| align="center" |{{ic|noexec}}
|-
| {{ic|/var}}||yes||yes||yes [1] [2]
|-
| {{ic|/home}}||yes||yes||yes (wine や steam を使用しない場合 [2])
|-
| {{ic|/dev/shm}}||yes||yes||yes
|-
| {{ic|/tmp}}||yes||yes||no (パッケージをコンパイルできなくなる可能性があります)
|-
| {{ic|/boot}}||yes||yes||yes
|-
|}

[1] パッケージによっては (例えば {{Pkg|nvidia-dkms}}) {{ic|/var}} で {{ic|exec}} を必要とすることがあるので注意してください。

[2] {{ic|noexec}} がパーティションに設定されている場合、Qt 5.8 以上では QML を使用するアプリケーションがクラッシュしたり機能しなくなることがあります。解決方法は [[Qt#Qt 5.8 で QML を使用するアプリケーションがクラッシュあるいは動作しない]]を参照。

===ファイルシステムのパーミッション===
デフォルトのファイルシステムのパーミッションはほぼ全ての読み取りアクセスが許可されているため、[[パーミッション]]を変更することで {{ic|http}} や {{ic|nobody}} ユーザーなど root 以外のアカウントへのアクセスを手に入れた攻撃者から重要な情報を隠すことができます。

例えば:

# chmod 700 /boot /etc/{iptables,arptables}

デフォルトの [[Umask]] を変更することで新しく作成したファイルのセキュリティを向上させることができます。[http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] はセキュリティを最大化させるために {{ic|077}} の umask を提案しています、これは新しいファイルの所有者以外のユーザーによる読み取りを出来なくします。umask を変更するには、[[Umask#マスクの値を設定]]を参照してください。

=== SUID ファイルと SGID ファイル ===

[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。これらは {{ic|/usr/bin}} 内にあり、SUID ビットが設定されていて、root によって所有されています:

* gpasswd
* pkexec
* [[sudo]]
* [[su]]
* [[passwd]]
* [[firejail]]

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}

SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:

$ find /usr/bin -perm "/u=s,g=s"

== ユーザー設定 ==

=== root アカウントを日常的に使用しない ===

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。

=== ログイン失敗後の遅延時間の設定 ===

以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。

{{hc|/etc/pam.d/system-login|2=
auth optional pam_faildelay.so delay=4000000
}}

{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。

===3回ログインを失敗したユーザーをロックアウトする===

{{Pkg|pambase}} 20200721.1-2 の時点では、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。

$ faillock --reset --user ''username''

デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。

モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。

* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)

{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

=== Wayland を使用する ===

[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

=== su の代わりに sudo を使う ===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

==== sudo を使ってファイルを編集する ====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

=== root ログインの制限 ===
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。

==== 特定のユーザーだけに許可を与える ====
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

==== ssh ログインを拒否する ====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==== access.conf で許容されるログインの組み合わせを指定する ====

誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは {{man|5|access.conf}} で確認してください。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

== カーネルの堅牢化 ==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

* {{AUR|skypeforlinux-preview-bin}}
* {{AUR|skypeforlinux-stable-bin}}
* {{pkg|throttled}}

[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。

==== ユーザー空間 ASLR の比較 ====

{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

===== 64 ビットプロセス =====

{{hc|linux-hardened 5.4.21.a-1-hardened|
Anonymous mapping randomization test : 32 quality bits (guessed)
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
Heap randomization test (PIE) : 40 quality bits (guessed)
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
Main executable randomization (PIE) : 32 quality bits (guessed)
Shared library randomization test : 32 quality bits (guessed)
VDSO randomization test : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)
}}

{{hc|linux 5.5.5-arch1-1|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
}}

{{hc|linux-lts 4.19.101-1-lts|
Anonymous mapping randomization test : 28 quality bits (guessed)
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
Heap randomization test (PIE) : 28 quality bits (guessed)
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
Main executable randomization (PIE) : 28 quality bits (guessed)
Shared library randomization test : 28 quality bits (guessed)
VDSO randomization test : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
}}

===== 32 ビットプロセス (x86_64 カーネル上) =====

{{hc|linux-hardened|
Anonymous mapping randomization test : 16 quality bits (guessed)
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
Heap randomization test (PIE) : 27 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 18 quality bits (guessed)
Shared library randomization test : 16 quality bits (guessed)
VDSO randomization test : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)
}}

{{hc|linux|
Anonymous mapping randomization test : 8 quality bits (guessed)
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
Heap randomization test (PIE) : 13 quality bits (guessed)
Main executable randomization (ET_EXEC) : No randomization
Main executable randomization (PIE) : 8 quality bits (guessed)
Shared library randomization test : 8 quality bits (guessed)
VDSO randomization test : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization
}}

=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===

{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。

{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。

{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
kernel.kptr_restrict = 1
}}

{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}

=== BPF の堅牢化 ===

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。

{{Tip|
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
}}

=== ptrace スコープ ===

{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。

{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}

デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。

=== hidepid ===

{{Warning|
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
}}

カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。

例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:

{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:

{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

=== モジュールのロードを制限する ===

デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。

=== kexec を無効にする ===

Kexec は、現在実行中のカーネルを置き換えることを可能にします。

{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
kernel.kexec_load_disabled = 1
}}

{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}

=== カーネルロックダウンモード ===

Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。

{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}

ロックダウンには2つの動作モードがあります:

* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください:

# echo ''mode'' > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:

{{Note|
* カーネルロックダウンを実行時に無効化することはできません。
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
}}

{{man|7|kernel_lockdown}} も参照してください。

=== Linux Kernel Runtime Guard (LKRG) ===

[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

== アプリケーションのサンドボックス化 ==

{{Note|標準の Arch カーネルではユーザー名前空間の {{ic|CONFIG_USER_NS}} が設定されていないため、特定のサンドボックス機能がアプリケーションから使えない場合があります。{{pkg|linux-hardened}} パッケージでは有効になっていますが、非特権での使用はデフォルトで無効になっています。{{ic|kernel.unprivileged_userns_clone}} の [[sysctl]] を {{ic|1}} に設定することで使用できるようになりますが、ローカルの権限昇格を引き起こす可能性が高くなるので注意してください。}}

{{Warning|{{Pkg|linux}} (5.1.8 およびそれ以降)、{{Pkg|linux-lts}} (4.19.55-2 およびそれ以降)、{{Pkg|linux-zen}} (5.1.14.zen1-2 およびそれ以降) においては、{{ic|kernel.unprivileged_userns_clone}} [[sysctl]] が {{ic|0}} に設定されていない限り、非特権ユーザの名前空間の利用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) がデフォルトで有効化されています。これはローカルの特権昇格の攻撃対象領域を大幅に増加させるので、これを手動で無効化するか {{Pkg|linux-hardened}} カーネルを使用することが推奨されます。詳細は {{Bug|36969}} を見てください。}}

=== Firejail ===

[[Firejail]] はアプリケーションやサーバーをサンドボックス化するためのシンプルで使いやすいツールです。Firejail はサーバーだけでなくブラウザなどのインターネットに接続するアプリケーションでも使うことができます。

=== bubblewrap ===

[[bubblewrap]] は [[Flatpak]] から開発された setuid サンドボックスアプリケーションです。Firejail よりもリソースの消費力が少なく抑えられています。ファイルパスのホワイトリストなどの機能を欠いていますが、バインドマウントやユーザー/IPC/PID/ネットワーク/cgroup 名前空間の作成ができ、簡単なサンドボックスから [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh 複雑なサンドボックス] まで自在に使うことが可能です。

=== chroot ===

手動で [[chroot]] 監獄を構築する方法もあります。

=== Linux Containers ===

他の手段 (KVM や Virtualboxのような完全仮想化を除く) よりも強力な分離が必要なときは [[Linux Containers]] を選択するのもよいでしょう。LXC は仮想ハードウェアを使って擬似的な chroot で既存のカーネル上で動作します。

=== 他の仮想化手段 ===

[[VirtualBox]], [[KVM]], [[Xen]] などの完全な仮想化マシンを使うことでもセキュリティを向上させることができます。危険なアプリケーションを実行したり危険なウェブサイトを開いたりするときに役に立つでしょう。

==ネットワークとファイアウォール==

===ファイアウォール===
標準の Arch カーネルは [[Wikipedia:ja:iptables|Netfilter]] の [[iptables]] を使用する能力がありますが、デフォルトでは有効になっていません。[[公式リポジトリ]]から {{Pkg|iptables}} をインストールして、有効にし、ファイアウォールを設定することが強く推奨されます。

*全般的な情報は [[iptables]] を見て下さい。
*iptables ファイアウォールを設定するガイドは[[シンプルなステートフルファイアウォール]]を見て下さい。
*netfilter を設定する他の方法は[[ファイアウォール]]を見て下さい。
*Bluetack などの IP アドレスのリストをブロックする方法は [[Ipset]] を見て下さい。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

2段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する2段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。

=== SSL 証明書の管理 ===

サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
# root で ''update-ca-trust'' を実行してください。

お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。

== 物理セキュリティ ==

{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐために出来ることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。

[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

=== ブートローダー ===

[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、例えば {{ic|1=init=/bin/sh}} を設定することでログインの制限を回避することができます。[[カーネルパラメータ]] でシェルに直接ブートするようにします。

==== Syslinux ====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

==== GRUB ====

[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。

=== セキュアブート ===

[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。

=== トラステッドプラットフォームモジュール（TPM） ===

[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。

=== リムーバブルフラッシュドライブ上のブートパーティション ===

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。

この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== 不正なUSBデバイスから保護する ===

[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。

=== 揮発性データの収集 ===

電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合（例:セキュリティチェックポイントを通過する時）には、コンピュータの電源を完全に切ることがベストプラクティスです。

== パッケージ ==

=== パッケージの認証 ===
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。

=== アップグレード ===

定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。

=== 脆弱性アラートの確認 ===

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

=== パッケージの再ビルド ===

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

{| class="wikitable"
! フラグ !! 目的
|-
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
|-
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
|-
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
|-
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
|-
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
|-
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
|-
| -fplugin=annobin || ハードニング品質管理用データの作成
|-
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
|-
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
|-
| -fstack-protector-strong || 同様に
|-
| -g || デバッグ情報を生成する
|-
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
|-
| -mcet -fcf-protection || 制御フローの完全性保護
|-
| -O2 || 推奨される最適化
|-
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
|-
| -Wall || 推奨されるコンパイラの警告
|-
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
|-
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
|-
| -Wl,-z,defs || アンダーリンクの検出と拒否
|-
| -Wl,-z,now || 遅延バインディングを無効にする
|-
| -Wl,-z,relro || 移設後の読み出し専用セグメント
|}

* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]

== 参照 ==

* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]