Kaz Wolfeの答えはかなり良いですが、私はいくつかの点を強調し、拡大したいと思います。
私が最後にチェックしたとき、Shimは基本的に、一種の並行セキュアブート検証機能を提供しました。GRUBはEFIプログラムではないLinuxカーネルを起動するように設計されています。したがって、Shimは、後続プログラムがShimを呼び出してバイナリが署名されていることを確認できるように、EFIに自身を登録します。Shimは次の2つの方法のいずれかで行います。
- Shimの組み込みキー-Ubuntuの一部として提供されるものを含むほとんどのShimバイナリには、組み込みのセキュアブートキーが含まれています。UbuntuのShimには、UbuntuのGRUBおよびLinuxカーネルを検証するCanonicalの公開キーが含まれています。したがって、このキーはRAMに保存され、これらが進むにつれて一時的になります。Shimの主なポイントは、後続のプログラム（GRUB）がセキュアブートタイプの検証を実行できるようにすることですが、GRUBは実際にセキュアブートの検証を実行しません。Shimがなければ、CanonicalはGRUBのすべての新しいリリースとすべての新しいLinuxカーネルに署名するためにMicrosoftに依存する必要があります。
- マシン所有者キー（MOK） -MOKは基本的にShimの組み込みキーの拡張ですが、通常のユーザーが操作するためのものです。Canonicalのキーで署名されていないバイナリを起動する場合は、MOKを使用できます。MOKは、ファームウェアの組み込みセキュアブートキーと同様に、NVRAMに保存されます。MokManagerと呼ばれるプログラムを介して、NVRAMに簡単に追加できます。MOKをNVRAMに入れることは、ほとんどの人が気にしないほど面倒であり、多くの人が問題を抱えています。参照した私のページで説明されているように、セキュアブートサブシステムを完全に制御するよりも簡単です（Linux用EFIブートローダーの管理：セキュアブートの制御）。
ほとんどの場合、MOKは使用されません。WindowsとUbuntuをデュアルブートする場合は、おそらくファームウェアの組み込みキーとUbuntuのShimバイナリに埋め込まれたキーでうまくいくでしょう。別のLinuxディストリビューションを追加したり、独自のカーネルをコンパイルしたり、GRUB以外のブートローダーを使用したり、サードパーティのカーネルモジュールを使用したい場合は、MOKを使用します。
これらの2つのソースに加えて、ファームウェアにはセキュアブートキーも組み込まれています。Shimがこれらのキーを使用するかどうかは思い出せません。それは考え暗黙的にそれがEFIの使用している場合は、それらを使用LoadImage()してStartImage()コール（それがないが、私はこの答えのコンテキストを検討していません）。私の記憶では、GRUBがコールバックしてカーネルが署名されているかどうかを確認するときに、独自の検証コードはファームウェアのセキュアブートキーを使用しませんが、それを正しく覚えていない可能性があります。
Shimがセキュアブートシステムにどのように統合されるかについては、最後に確認しましたが、そうではありませんでした。IIRCは、その後続プログラム（GRUB）を起動するために、Tianocore UEFIサンプル実装のコードの簡略版に似た独自のバイナリ読み込みコードを実装しています。このコードは、Shimの独自のセキュアブート検証コードを呼び出します。このコードは、組み込みキーとローカルMOKリストに対してバイナリをチェックし、バイナリを起動します。（ファームウェアの独自のセキュアブートキーを使用することもありますが、私はそうは思いません。）GRUBがロードされると、Shimのバイナリ検証機能を呼び出して、Linuxカーネルを検証します。 EFIがEFIプログラムを起動する方法）。したがって、Shimは実際にはファームウェアにあまり深く統合されていません。1つまたは2つの機能を後続のプログラムで使用できるようにするだけです。LoadImage()そして、StartImage()EFI機能変わりません。
とはいえ、EFIは通常のEFIシステムコールを置換または補完する方法を提供し、一部のツールはこれらの方法を使用します。たとえば、Shimの機能と同様のことを行うツールであるPreLoaderプログラムは、ファームウェアにさらに深く統合されました。通常のUEFIセキュアブートキーと MOKの両方StartImage()をチェックするように、破損または廃止された機能にパッチを適用して修正するように設計されたEFIシステムコールを使用しました。PreLoaderは道端でかなり落ちています。その開発者とShimの開発者は、標準のLinuxセキュアブートツールとしてPreLoaderではなくShimに焦点を当てるために協力しています。知る限りでは、ShimはPreLoaderのより深いUEFI統合を採用していません。ただし、コードを非常に詳しく調べてからしばらく経ちましたので、これについては時代遅れかもしれません。とはいえ....
私自身のrEFIndブートマネージャは、PreLoaderプログラムから取得したコードを使用して、Shimのバイナリ検証コードをUEFIの通常の検証サブシステムに「接着」します。したがって、図のrEFIndを使用してLoadImage()、StartImage()最初にShim認証コードを使用してEFIプログラムを起動して呼び出し、それが失敗した場合、標準のUEFIセキュアブート認証を次に呼び出します。gummiboot / systemd-bootブートマネージャーは、同様のことを行います。両方のプログラムがこれを行うのは、EFIスタブローダーを介してLinuxカーネルを起動するためです。つまり、EFI LoadImage()とStartImage()呼び出しに依存するためです。これは、独自の方法でLinuxカーネルを起動するフルブートローダーであるGRUBとは対照的です。したがって、GRUBは、ShimのキーまたはローカルMOKリストを認識するためにこれらのEFIシステムコールを必要としません。
これが物事を明確にするのに役立つことを願っていますが、どうなるかはわかりません。このすべての作業の詳細は非常に乱雑であり、詳細に対処してからしばらく経ちました。そのため、私自身の考えは整理されていません。