Linuxのセキュアブートを最大限に活用します

セキュアブートテクノロジーは、オペレーティングシステムの起動時に信頼できないコードの実行を防ぐことを目的としています。つまり、ブートキットやEvil Maidなどの攻撃に対する保護です。 セキュアブートデバイスには、OSローダーやドライバーなど、ダウンロードしたUEFIアプリケーションの署名を検証する不揮発性メモリ公開キーデータベースが含まれています。 信頼できるキーと正しいチェックサムで署名されたアプリケーションはダウンロードが許可され、残りはブロックされます。

セキュアブートの詳細については、 CodeRushの記事シリーズをご覧ください。

• UEFIセキュリティパート5

  
  

• UEFI SecureBootを使いこなす

  
  

セキュアブートがセキュリティを確保するために、署名されたアプリケーションは、特定の「名誉のコード」に準拠する必要があります。セキュアブートシステムおよび設定への無制限のアクセスのための抜け穴がなく、ダウンロードしたアプリケーションから同じものを必要とします。 署名されたアプリケーションが不正に直接または他のアプリケーションをダウンロードする機会を提供する場合、このアプリケーションを信頼するすべてのユーザーにとってセキュリティリスクになります。 この脅威は、Microsoftが署名したshimブートローダーとブートローダーGRUBによってもたらされます 。

これから身を守るために、LUKSとLVMに基づいてディスク全体を暗号化してUbuntuをインストールし 、1つのUEFIアプリケーションでカーネルと組み合わせてinitramfsを変更から保護し、独自のキーで署名します。

ソリューションのすぐに使える制限

Ubuntuは、他の一般的なディストリビューションと同様に、インストール中にLVMドライブ全体を暗号化するオプションを提供します。 この構成のディストリビューションは、アクティブなセキュアブートを使用してUEFIにエラーなしでインストールされます。

ただし、Canonicalは主に、セキュアブートが有効になっているデバイス上のOSの状態に関心があり、セキュリティを確保することには関心がありません 。 セキュリティツールとしてセキュアブートを使用する場合は、自分で設定してください。

Ubuntuはドライブ全体の暗号化を使用してセキュアブートへのブートをどのように実装しますか？

Red Hatは、すべてのデバイスで動作し、人類の利益に役立つようにシムブートローダーを開発し、厳格なセキュアブート標準に従い、信頼できるUEFIアプリケーションのみをダウンロードします。 Canonicalはプロキシとしてshimを使用し、その中に公開キーを埋め込み、Microsoftと署名します。 Shimは、Canonicalキーで署名されたGRUBをダウンロードし、Canonicalキーで署名されたカーネルをロードします。

• そもそも、ディスク全体が暗号化されているわけではありません-/ bootは暗号化されていないため、initramfsが含まれています。 initramfsへのアクセスは、ルートアクセスを意味します。 失敗。

  
  

• /ブーツ デフォルトのGRUBは暗号化モジュールなしではドライブを復号化できないため、暗号化されません。 何らかの理由で、署名されたGRUBに組み込まれていないもの。 GRUBが追加モジュールをセキュアブートにロードすることは禁止されています 。 ダブルフェイル¹ 。

  
  

• GRUBはブート可能なカーネルを検証し、誤って署名されたカーネルを拒否する必要があります。 彼はそれをしません 。 トリプルフェイル。

  
  

• グラブ ファイルから設定を読み込み、デフォルトでコンソールへのアクセスを提供します。 構成ファイルの信authentic性はチェックされません。それを変更するか、コンソールを使用することで、UEFIシェル、別のカーネル、initramfsをロードするか、カーネルに引数を渡してルートアクセスを取得するなど、何でもできます。 致命的なエラー² 。

  
  

これはどういう意味ですか？

システムにMicrosoft ³キーがある場合、誰でも外部デバイスから起動し、ブートキットをインストールして、デバイスを完全に制御できます。 セキュアブートを無効にする必要はありません。動作しなくなりました。

UEFIアプリケーションの署名に関するMicrosoftのポリシーによると 、GRUBのロードに使用されるすべての署名済みGRUBおよびshimブートローダーは、すでにブラックリストに登録されている必要があります。

話す 、外部デバイスからのダウンロードを無効にする必要がありますか？ これは症状との戦いです。 保護されていないGRUBがインストールされている場合、これはあなたを救いません。 Windowsがデバイスにインストールされている場合、そこからデバイスを選択して起動することができ、ファームウェアがこれを許可する可能性があります⁴ 。 それでもPXEネットワークブート 。 デバイスの電源を入れるためのパスワードのみが役立ちます。

おわりに

外部キーを拒否する必要があります。 ユーザーはセキュアブートを制御する必要があります。 ローダーはユーザーが署名する必要があり、システムブートのすべての暗号化されていない書き込み可能なアイテムを検証する必要があります。 ユーザーデータは暗号化する必要があります。 達成しようとするもの。

LUKSとLVMを使用してフルディスク暗号化でUbuntuをインストールします

LUKS -Linux Unified Key Setup- dm-crypt暗号化システムのラッパー。これにより、ファイルおよび物理ディスクに仮想暗号化デバイスを作成できます。 LUKSを使用すると、ドライブ全体のデータを暗号化できるため、OSをロードする前にパスワードを入力する必要があります。

LVM-論理ボリュームマネージャー-論理ボリュームマネージャー。暗号コンテナーをボリュームに分割します。 LVMボリュームは、暗号コンテナのパスワードを入力すると自動的にマウントされます。ボリュームごとに個別のパスワードエントリは必要ありません。

次の手順は、Ubuntuベースのディストリビューションに適用する必要があります。他のディストリビューションには調整が必要です。 [インストール前に試す]モードで、Live CDまたはインストールイメージから最初に起動します。

マークアップと暗号化

UEFIモードでディスクから起動するには、GPT形式でマークする必要があります。 KDE Partition ManagerとGPartedを使用したディスクレイアウトを検討します。 持っていない場合は、環境に合ったものをインストールしてください。

sudo apt-get install partitionmanager # KDE sudo apt-get install gparted # GNOME   

パーティションエディターを起動し、目的のドライブを選択します。通常は、システムの最初のドライブ-/ dev / sdaです。 ディスクのプロパティを確認します。

 KDE Partition Manager:     , GParted: View -> Device Information. 

パーティションテーブルの行は、使用されているパーティションテーブルを示します 。 ディスクがdos / msdos （MBR）形式でラベル付けされている場合、GPTに変換する必要があります。 データを失うことなくこれを行うことは可能ですが、ここでは説明しません。インターネットで指示を探してください。 ディスクに重要なデータがなく、GPTでフォーマットする場合は、新しいテーブルを作成します。

 KDE Partition Manager: New Partition Table — GPT GParted: Device -> Create Partition Table — gpt 

ディスクには、ブートローダーが格納される少なくとも1つのESP （EFIシステムパーティション）パーティションが必要です。 OSがUEFIモードでこのディスクにインストールされている場合、そのようなパーティションがすでに1つ存在します。 いずれにせよ、少なくとも100 MBのサイズで新しいものを作成することをお勧めします。 ESPは、FAT形式のいずれか、できればFAT32でフォーマットし、起動可能としてマークする必要があります。

 KDE Partition Manager:     -> New File system: fat32 Size: 128.00 MiB Free space before: 0.00 —    GPT OK, Apply       (Properties),   boot OK, Apply GParted:     -> New File system: fat32 New size: 128 MiB Free space preceding: 1 MiB   —    GPT Add, Apply        (Manage Flags),   boot Close 

次に、暗号化のためのセクションを作成する必要があります。 ESPと同じ方法で、フォーマットなし（フォーマットなし）、フラグおよび大きなサイズの設定のみ-システムとスワップパーティションに適合するようにします。 このセクションでは、以前にスーパーユーザーモードに切り替えた、ターミナルを介してLUKS暗号コンテナーを作成します。

 sudo -i 

最新の暗号化およびハッシュアルゴリズムを示すセクションをフォーマットします。 XTSモードでは、キーの長さを2倍に指定する必要があるため、AES-256の場合、512ビットのキーを指定する必要があります。 --iter-timeパラメーターは、PBKDF2関数を使用して入力されたパスワードからキーを生成するのに費やされる時間をミリ秒単位で設定します。 反復回数を増やすと、パスワードの検索が複雑になりますが、正しいパスワードを入力した後の待ち時間も長くなります。

 cryptsetup luksFormat --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 2000 /dev/sda2 

YESと入力してフォーマットを確認し、パスワードを入力します。 次に、cryptocontainer（sda2_crypt-マッピングの名前）を開き、同じパスワードを入力します。

 cryptsetup luksOpen /dev/sda2 sda2_crypt 

コンテナは、ブロックデバイス/ dev / mapper / sda2_cryptとして利用可能になります。 暗号コンテナー内の論理ボリュームのマークアップに移りましょう。 / dev / mapper / sda2_cryptの上にある物理LVMパーティションを初期化します。

 pvcreate /dev/mapper/sda2_crypt 

この物理パーティション内に、 ubuntuという名前のボリュームグループを作成します。

 vgcreate ubuntu /dev/mapper/sda2_crypt 

これで、このグループ内に論理ボリュームを作成できます。 まず、スワップパーティションのボリュームを作成し、初期化します。 推奨サイズは、ギガバイト単位のsqrt（RAM）から2xRAMです。

 lvcreate -n swap -L 4G ubuntu #      swap  4    ubuntu mkswap /dev/ubuntu/swap 

ルート用のボリュームを追加し、その中にext4ファイルシステムを作成します。 空き領域を残し、必要に応じてボリュームを拡張することをお勧めします。そのため、ルートに20 GBを割り当てます。 必要に応じて、空きスペースで、home、usr、varなどの追加のボリュームをパーティション化できます。 -l 100%FREEオプション-l 100%FREEを使用して、ボリュームに空き領域を割り当てます。

 lvcreate -n root -L 20G ubuntu mkfs.ext4 /dev/ubuntu/root 

マークアップが終了したら、インストールに進むことができます。

設置

ブートローダーを自分で作成する予定であり、Ubuntuインストーラーが暗号化/ブート暗号化をサポートしていないため、ブートローダーを作成せずにインストールを開始します。

 ubiquity -b 

ディスクのパーティション化ステップで、 「手動」を選択します。

ここで、マウントポイントを指定する必要があります。 / dev / mapper / ubuntu-rootを選択し、Ext4をジャーナリングファイルシステムとして使用することを指定します。 Ubiquity自体が/ dev / mapper / ubuntu-swapをスワップパーティションとして選択し、EFIシステムパーティションの1つを記憶します。 レイアウト画面は次のようになります。

インストールを完了し、再起動しません。

crypttab、fstab、およびresumeの構成

インストールされたシステムのルートを/ mntにマウントし、/ dev、/ sysおよび/ procをそれぞれ/ mnt / dev、/ mnt / sysおよび/ mnt / procにバインドし、/ etc / resolv.confを/ mnt / etc / resolvにバインドします。 confを使用すると、ネットワークにアクセスできます。 ここで、 chrootてルートディレクトリを変更します。

 mount /dev/ubuntu/root /mnt mount --bind /dev /mnt/dev mount --bind /sys /mnt/sys mount --bind /proc /mnt/proc mount --bind /etc/resolv.conf /mnt/etc/resolv.conf chroot /mnt mount -a #  ESP   /boot/efi ,      /etc/fstab 

/ etc / crypttab-ブート時にマウントされた暗号コンテナーを記述するファイルを手動で入力する必要があります。

 nano /etc/crypttab 

/ dev / mapper / sda2_cryptにマウントされた/ dev / sda2に関するエントリを追加する必要があります。 マウントは、デバイス名ではなくUUIDで構成します。 UUID / dev / sda2を見つけるには、別のターミナルを開いて次のコマンドを使用します。

 sudo blkid 

/ dev / sda2で始まる行は、そのUUIDを記録します。 コピーします（ Ctrl + Shift + C ）。 / etc / crypttabで、UUID（ Ctrl + Shift + V ）を挿入して、 mapping_name UUID = <UUID> none luksという形式のエントリを追加します。 Ctrl + XおよびYを押してnanoを閉じ、保存を確認します。

マウントされたパーティションが/ etc / fstabに正しく記述されていることと、ハイバネーションからウェイクアップするセクションが/etc/initramfs-tools/conf.d/resumeに指定されていることを確認してください。

すべての変更後、initramfsイメージをアップグレードします。

 update-initramfs -u 

ログアウトしてchrootしないでください。

ブートローダーの作成

Linuxカーネルは 、CONFIG_EFI_STUBパラメーターを使用してコンパイルされた場合、UEFIからの直接起動をサポートします。 この場合、通常initramfsはESPの近くに保存され、そのパスはカーネル引数で渡されます。

ただし、initramfsの検証がないため、悪意のあるコードをEitへの書き込みアクセス権を持って埋め込むことができます。 Teddy Reed は、カーネルにinitramfsを埋め込むことでコンパイルすることを提案しています 。

カーネルのコンパイルプロセスは非常に長く、initramfsが変更されるたびに実行する必要があります。 幸いなことに、別の方法があります。 systemdパッケージ（以前はgummiboot ）にはlinuxx64.efi.stubが含まれています。これは、カーネル、initramfs、およびカーネルに渡された引数を組み込むことができるUEFIアプリケーションスタブです。 このUEFIアプリケーションに署名することにより、カーネルとinitramfsを変更から保護します。

この操作にはbinutilsが必要です。

 sudo apt-get install binutils 

カーネルに渡される引数を/ tmp / cmdlineに書き込みます。

 echo -n "quite splash" > /tmp/cmdline 

カーネルイメージ（ vmlinuz-*-ジェネリック ）およびinitramfs（ initrd.img-*-ジェネリック ）は/ bootに保存されます。 最新バージョンを特定し、空白に埋め込みます。

 objcopy \ --add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \ --add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \ --add-section .linux=/boot/vmlinuz-4.4.0-34-generic --change-section-vma .linux=0x2000000 \ --add-section .initrd=/boot/initrd.img-4.4.0-34-generic --change-section-vma .initrd=0x3000000 \ /usr/lib/systemd/boot/efi/linuxx64.efi.stub ubuntu.efi 

結果のUEFI ubuntu.efiアプリケーションは、ESIのEFI / BOOT /ディレクトリに配置する必要があります。 Ubuntuインストーラーは、ESPを決定し、/ boot / efiでマウントを構成する必要がありました。 このESPに他のブートローダーがない場合、ubuntu.efiを/boot/efi/EFI/BOOT/BOOTX64.EFIにコピーし、UEFIブートメニューでこのセクションを選択するとロードされます。

 mkdir -p /boot/efi/EFI/BOOT cp ubuntu.efi /boot/efi/EFI/BOOT/BOOTX64.EFI 

もし BOOTX64.EFIブートローダーは既にESPに記録されているため、別のESPを作成するか、別の名前でubuntu.efiを記述し、ファームウェアに組み込まれたUEFIコンソール（UEFIシェル）を介して対応するブートレコードを追加できます。 efibootmgr使用efibootmgr推奨されません⁵ 。

UPD：UEFIシェルがファームウェアに組み込まれていない場合は、こちらからダウンロードできます。 任意のESPのEFI / BOOT / BOOTX64.EFIに入れて、セキュアブートを無効にして起動します。 ブートレコードを追加するには、次のコマンドを入力します。

 bcfg boot add 0 fs0:\EFI\BOOT\UBUNTU.EFI # 0 --     ,      # fs0 --   ,    #       ESP,    \UBUNTU.EFI 

UEFIシェルへのリンクを提供してくれたPrototikに感謝します。 他のチームのリストはここにあります 。

セキュアブートを有効にしている場合、ubuntu.efiは署名されていないため起動できません。 セキュアブートとブートを一時的に無効にするか、chrootから続行します。

セキュアブートを構成する

キーの生成、ファームウェアへのキーのインストール、およびUEFIアプリケーションの署名については、 ここでCodeRushによって説明されているため、すべてを理解していることを前提としています。

作成したブートローダーに署名するだけです。

 sbsign --key ISK.key --cert ISK.pem --output BOOTX64.EFI ubuntu.efi 

ブートする予定のEFIセクションのEFI / BOOT /ディレクトリにBOOTX64.EFIを配置します。

自動化

initramfsの更新時にブートローダーを自動的に更新してサインアップするには、/ etc / initramfs / post-update.d /にupdate-efi-loaderスクリプトを作成し、必要に応じてパスを変更します。

 #!/bin/sh echo -n "quiet splash" > /tmp/cmdline objcopy \ --add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \ --add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \ --add-section .linux=/boot/vmlinuz-$(uname -r) --change-section-vma .linux=0x2000000 \ --add-section .initrd=/boot/initrd.img-$(uname -r) --change-section-vma .initrd=0x3000000 \ /usr/lib/systemd/boot/efi/linuxx64.efi.stub /tmp/ubuntu.efi sbsign --key /root/keys/ISK.key --cert /root/keys/ISK.pem --output /boot/efi/EFI/BOOT/BOOTX64.EFI /tmp/ubuntu.efi 

スクリプトに実行する権利を与えます。

 chmod a+x /etc/initramfs/post-update.d/update-efi-loader 

カーネルを更新するときは、この操作を手動で実行する必要があります。

ドライバーとカーネルモジュールの署名

サードパーティまたはネイティブのドライバーとカーネルモジュールをインストールする必要がある場合は、それらに署名する必要があります。 カーネルモジュールに署名するには、DER形式の証明書とパスワードなしのキー、つまり-nodesパラメーターで生成されたキーが必要です。

 openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \ -subj "/CN=Kernel Key" -outform DER -out kernel.der \ -keyout kernel.key 

署名するには、 sign-fileスクリプトを使用しsign-file 。

 /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 kernel.key kernel.der module.ko 

この証明書をファームウェアに追加するには、PEM形式に変換してからESLに変換し、KEKキーで署名する必要があります。

 openssl x509 -inform der -in kernel.der -outform pem -out kernel.pem cert-to-efi-sig-list -g "$(uuidgen)" kernel.pem kernel.esl sign-efi-sig-list -k KEK.key -c KEK.pem kernel kernel.esl kernel.auth 

明らかなヒント

タスクがデバイス上のデータを保護することである場合、セキュアブートはそれ以上の仕事を行いません。 残りはあなた次第です。

• 他の人のキーをファームウェアに追加しないでください。 Microsoftからでも。 まず第一に、マイクロソフトから。

  
  

• UEFIシェル、KeyTool、またはNVRAMへの書き込みアクセス権を持つ他のアプリケーションに署名しないでください。 それらをセットアップモードで使用します。

  
  

• デバイスの電源を入れたまま放置しないでください。 スタンバイモードのデバイス（RAMにサスペンド）には、RAMの暗号化コンテナーから復号化されたデータとマスターキーが含まれています。

  
  

• UEFIセットアップでパスワードを設定するのは、暗号コンテナーから行うよりも簡単ではありません。

  
  

• 内部デバイスへの物理アクセスにより、NVRAMメモリをリセットまたは損傷することでセキュアブートを無効にでき、ハードウェアタブも残します。 このような攻撃は、目に見えない場合にのみ成功します。 あなたがそれについて知ることができるようにそれを作ります：ケースのネジを遊びにくいステッカーで密封し、それらをグリッターワニスで覆います。 デバイスを密封します。

  
  

• 署名されていないアプリケーションを使用して、ダウンロードリストの先頭になります。 ある日、セキュアブートからのメッセージが表示されない場合、デバイスは一意に侵害されています。

  
  

• インターネットに接続されていない安全な場所に保管されているデバイスよりも信頼性の高いものは想像できません。 特定のファームウェアでのセキュアブートの実装の脆弱性は排除されません。

  
  

ボーナス：冬眠の復活

スタンバイモードの代わりにディスク全体を暗号化する場合、通常、休止状態を使用して状態を保存し、停止ポイントから作業を続行します。また、休止状態またはディスクへのサスペンドも行います。

セキュリティ上の理由から、 カーネルモジュール検証が有効になっている場合 、カーネル開発者は休止状態を無効にしています 。 これは、リカバリイメージが起動時に検証されず、スワップパーティションが置き換えられ、テストされていない潜在的に悪意のあるコードでシステムが起動するという事実によって議論されています。

これは、initramfsが検証されていないか、スワップパーティションが暗号化されていない場合に当てはまります。 ただし、このような条件下での休止状態の使用に関係なく、initramfsを置き換えることができ、機密データはスワップパーティションから復元されます。 この構成では、initramfsは署名付きブートファイルに含まれることによって検証され、スワップパーティションは暗号化されます。 したがって、この制限は私たちにとって無意味です。

Chung-Yi Leeは2013年にリカバリイメージの検証を提案し、2015年に彼のアイデアを実装するパッチを導入しました。 しかし、物事はまだそこにあります。 したがって、暗号化で十分に保護されており、検証なしで休止状態に戻ると仮定します。

方法1.カーネルモジュールの検証を無効にする

含まれるカーネルモジュールの検証により、休止状態が無効になります。 デフォルトでは、カーネルモジュールの検証はセキュアブートで有効になっていますが、セキュアブートに依存しません。 無効にして、セキュアブートのみを残すことができます。

これにより、セキュリティが大幅に損なわれることはありません。 カーネルモジュールは、信頼できるソースからカーネルアップデートとともにインストールされ、暗号化されたドライブと検証済みのinitramfsに保存されます。 サードパーティのドライバは手動でインストールされます。サードパーティのドライバが署名されているかどうかは関係ありません。すでに信頼されているためです。 カーネル用のSecureAptおよびサードパーティ製ドライバー用のTLS / HTTPSはMiTMから保護する必要があり、その後、復号化されたディスクへのルートアクセスのみが残ります。 しかし、この場合、攻撃者はすでにデータを持っています。

mokutilを使用してモジュールの検証を無効にする「リクエストを残す」ことができ、 shimブートローダーshimそれshim確認します。

 sudo apt-get install mokutil shim sudo mokutil --disable-validation 

パスワードを入力します。パスワードは文字で確認する必要があります。 ここで、 shimから起動し、その中の[ セキュアブート状態の変更 （sic！） ESPの 1つで/usr/lib/shim.efiをEFI / BOOT / BOOTX64.EFIに配置するか、UEFIシェルからブートエントリを追加します。 最初にセキュアブートを切断してから、元に戻します。

UPD 01/12/17：shim.efiと一緒に、 MokManagerを近くに置く必要があります。 パッケージの最新バージョンでは、 shim.efiとMokManagerはそれぞれ/ usr / lib / shim /、shimx64.efiとmmx64.efi.signedにあります。 mmx64.efi.signedの名前をmmx64.efiに変更します。

セキュアブートと休止状態が機能するようになり、UEFIアプリケーションは検証されましたが、カーネルモジュールはありません。

原則として、 shimとmokutil不要になりました。削除できます。

方法2.古いカーネルバージョンを使用する

休止状態を無効にするパッチがUbuntu-4.4.0-18.34に登場しました。 Ubuntu-4.4.0-17.33は無料です。 ただし、セキュリティ更新プログラムを無視しながら古いカーネルにとどまることは最良の選択肢ではありません。

方法3.カーネルをコンパイルする

時間に余裕がない場合は、この制限なしでカーネルをコンパイルできます。 多くの苦痛の後にあなたが結果に満足するという保証はありません。 しかし、本当にそれを望むなら、Linus TorvaldsとGPLv2を賞賛してください。あなたにはそうする権利があります。 時間を無駄にしないように、私がコンパイルしたカーネルを事前にテストしてください 。

 $ sudo nano /etc/apt/sources.list ... deb-src http://ru.archive.ubuntu.com/ubuntu/ xenial main restricted deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted ... $ apt-get update 

 apt-get source linux-image-$(uname -r) cd linux-4.4.0 

 linux_4.4.0-34.53.dsc 

 sudo apt-get install git 

 git clone git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git cd ubuntu-xenial 

 $ git tag -l Ubuntu-* ... Ubuntu-4.4.0-33.52 Ubuntu-4.4.0-34.53 Ubuntu-4.4.0-35.54 ... 

 git checkout -b temp Ubuntu-4.4.0-34.53 

 sudo apt-get build-dep sudo apt-get ccache fakeroot kernel-package libncurses5-dev 

 chmod a+x debian/rules chmod a+x debian/scripts/* chmod a+x debian/scripts/misc/* fakeroot debian/rules clean 

 cp /boot/config-4.4.0-34-generic config fakeroot debian/rules editconfigs 

 --- a/kernel/power/hibernate.c +++ b/kernel/power/hibernate.c @@ -67,7 +67,7 @@ static const struct platform_hibernation_ops *hibernation_ops; bool hibernation_available(void) { - return ((nohibernate == 0) && !secure_modules()); + return (nohibernate == 0); } /** -- 

 git add kernel/power/hibernate.c 

 git config --global user.email "you@example.com" git config --global user.name "Your Name" 

 $ git commit ... Allow hibernation on Secure Boot 

 $ git rebase Ubuntu-4.4.0-35.54     ,      … : Allow hibernation on Secure Boot 

 EDITOR=nano debchange -c debian.master/changelog -l "custom" 

 linux (4.4.0-3400.53custom1) UNRELEASED; urgency=medium * Allow hibernation on Secure Boot ... 

 fakeroot debian/rules clean skipabi=true skipmodule=true DEB_BUILD_OPTIONS=parallel=$(getconf _NPROCESSORS_ONLN) do_tools=false no_dumpfile=1 \ fakeroot debian\rules binary-generic 

 echo -n "quiet splash" > /tmp/cmdline objcopy \ --add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \ --add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \ --add-section .linux=/boot/vmlinuz-4.4.0-34-generic --change-section-vma .linux=0x2000000 \ --add-section .initrd=/boot/initrd.img-4.4.0-34-generic --change-section-vma .initrd=0x3000000 \ /usr/lib/systemd/boot/efi/linuxx64.efi.stub /tmp/test.efi sbsign --key /root/keys/my.key --cert /root/keys/my.pem --output /boot/efi/EFI/BOOT/BOOTX64.EFI /tmp/test.efi 

, . , , Secure Boot.

4.

, . , , , KDE Plasma, Kubuntu .

Linux, — . , . . , Qemu KVM . しかし、これは別の記事のトピックです。

: . , — . - . , Qubes OS. Secure Boot. Fail.

, .

1. ↑ GRUB grub-mkstandalone , .

   
   

2. ↑ , , grub.cfg GRUB grub-mkstandalone grub.cfg prefix , GRUB grub.cfg . .

   
   

3. ↑ .

   
   

4. ↑ USB . Windows 8 10 .

   
   

5. ↑ , . ESP .