カーネルコマンドラインから暗号化キーを取得するのではなく、initramfsなしで実行できる完全なディスク暗号化方式はありますか？攻撃者がブートローダファイルのみを読み取ることができるため、これは安全ではないことを認識していますが、このデバイスの起動プロセスのために起動するたびにコマンドラインを手動で入力する必要があります。
私はこのarm64デバイス用に独自のカーネルをコンパイルしたので、カスタムカーネル設定オプションは私にとって問題ではありません。
ベストアンサー1
いいえ。
まあ、通常FDEはハードウェア（Linuxではない）になければなりません。それ以外の場合、カーネルはどこから来たかです。この問題を解決したとします（おそらくあまり一般的ではないブートプロセスの提案に関連している可能性があります）...
コマンドラインオプションを使用して復号化されたブロックデバイスでは、ルートファイルシステムをマウントできません。 ecryptfsをrootとしてマウントすることも不可能です。 ecryptfsをマウントする前に、ecryptfsのバックアップファイルシステムを設定する必要があります。
（技術的にはハッキングオプションがありますrootdelay=が、2つのrootfを並べてマウントする起動オプションはなく、どのような方法でもブロックデバイスの暗号化を解除する起動オプションもありません。）
通常、/proc/cmdlineすべてのユーザースペースプロセスで読み取ることができるので、Linuxはここにキーを入れることをお勧めしません。これらのアイデアをFDEの暗黙のセキュリティ要件と調和させることは困難ですが、おそらく人為的な状況があるかもしれません。
選択した方法でストレージスタックを構築できるユーザースペースコードの塊をカーネルに渡したいと思います。カーネル開発者でさえ承認しない方法です:-).起動時にこのBLOBを渡すことができます。あるいは、カーネルにビルドすることもできます。これを初期 ramfs または単に initramfs と呼ぶことができます。良いニュース！誰かがすでにこのカーネル機能を実装しています。
この質問は、なぜ9文字の単語を話すことができないのか説明しません。カスタムコンパイルを実行しているので、いつでも好きな名前にパッチを適用できます。 ：-P。
（これはより一般的なオプションです。技術的には、暗号化されていないパーティションを使用して同じコードを保存できますが、通常はあまり便利ではありません。）
ディストリビューションのinitramfsほど大きくする必要はありません。たとえば、クイック検索でこれが合理的な出発点になることがわかりました。
https://gist.github.com/packz/4077532
initramfs に必要なモジュールのみを有効にするカスタムビジボックスを構築できます。静的リンクがどれくらいうまく機能するかによって異なりますが、initramfsがカーネルよりも小さいことを願っています。