bubba Es gibt den Hinweis: Es ist sinnvoll, die EFI-Partition nach /boot zu mounten.

Ich zweifle an, dass das Einhängen der ESP nach /boot sinnvoll ist. Es gibt sogar Fälle, in denen das kontraproduktiv ist:

  • Wenn man mehrere (Arch) Linux-Installationen hat, die alle die ESP nach /boot einhängen
  • Wenn man ein vollverschlüsseltes System haben möchte, bleibt /boot dennoch unverschlüsselt
  • Wenn die ESP eher klein gewählt ist, man aber viele verschiedene Kernel installieren will

bubba Aber wie bekomme ich die Partition nach /boot/efi ?

Die ESP wird dort eingehängt, wo du sie einhängst. Wenn du also /boot/efi haben möchtest, dann musst du die ESP eben entsprechend einhängen. Und da wird auch kein Verzeichnis automatisch erzeugt.

Die ESP ist dazu gedacht, dass dort die Bootloader installiert werden (sozusagen als Ersatz für den Bootloader-Teil im Master Boot Record). Sie enthält in jedem Fall ein Verzeichnis \EFI mit den jeweiligen Unterverzeichnissen für die Bootloader, z.B. \EFI\gentoo, \EFI\arch und das Spezialverzeichnis \EFI\BOOT.
Der traditionelle Einhängepunkt (insbesondere bei Grub) ist /boot/efi. Aber man kann die ESP auch nach /efi einhängen oder eben auch nach /boot.

Das Verzeichnis /boot enthält alle Dateien, die zum Starten des Betriebssystems nötig sind. Also zum Zeitpunkt nachdem der Bootloader schon geladen wurde. Dies umfasst den Kernel, das initrd, Mikrocode, Konfigurationen und Dateien, die der Bootloader benötigt.

Indem du die ESP nach /boot einhängst, würdest du die gleiche Partition für zwei komplett unterschiedliche Zwecke verwenden.

Da ich kein systemd-boot benutze, kann ich nicht sagen, ob bei systemd-boot noch etwas zu beachten ist, falls du die ESP nicht nach /boot einhängst.

      Vielen Dank für die ausführliche Erklärung :-)

      In der Anleitung für Einsteiger steht:

      Für die Partition "BOOT" die bei UEFI-Systemen nötig ist, wird das Verzeichnis /mnt/boot angelegt und dort eingebunden.

      Also wäre es eigentlich egal wo ich das einbinde, hauptsache es wird natürlich eingebunden?
      Könnte das auch nach /mnt/XYZ einbinden?

      Denke ich halte mich dann einfach an die Anleitung um Probleme zu vermeiden bei der Installation.

        Die Wahl deines Bootloaders oder Bootmanagers bestimmt die Wahlmöglichkeiten der Mountpoints für die EFI-Partition auf deinem System. Wenn du den Kernel mittels EFISTUB direkt vom EFI laden lässt, musst du die EFI-Partition nach /boot mounten. Mit einem Bootmanager wie system-boot oder Grub ist dies hingegen nicht notwendig und du kannst die EFI-Partition dahin mounten, wo es dir passt. Es hat sich dafür /efi eingebürgert, dies ist allerdings nicht im FHS festgeschrieben. Eine Vollverschlüsselung im engsten Sinne ist mit EFI allerdings nicht möglich, da das System immer eine unverschlüsselte EFI-Partition haben muss, auf der das EFI nach einem Loader suchen kann. Ob auf dieser jetzt noch Kernel und Initramfs liegen ist dabei aus der Sicherheitsperspektive irrelevant, da der dort befindliche EFI-Loader so wie so ohne Umgehung der Systemverschlüsselung manipuliert werden kann. Gegen eine solche Manipulation hilft einzig und allein Secure Boot in Kombination mit einem TPM.

          schard Wenn du den Kernel mittels EFISTUB direkt vom EFI laden lässt, musst du die EFI-Partition nach /boot mounten.

          Bist du sicher? Es würde doch reichen, wenn man die benötigten Dateien auf die ESP kopiert und /boot auf der Partition mit dem Wurzelverzeichnis belässt, oder nicht?

          schard Eine Vollverschlüsselung im engsten Sinne ist mit EFI allerdings nicht möglich, da das System immer eine unverschlüsselte EFI-Partition haben muss, auf der das EFI nach einem Loader suchen kann.

          Eine Vollverschlüsselung im engsten Sinne ist nicht möglich, weil die Firmware einen verschlüsselten Bootloader nicht entschlüsseln kann.
          Einen Bootloader zu verschlüsseln, ist auch ziemlich unnötig, da er praktisch keine schützenswerten Daten enthält (Verschlüsselung dient primär dem Schutzziel Vertraulichkeit).
          Um Manipulationen am Bootloader zu entdecken, gäbe es Secure Boot.

          schard Ob auf dieser jetzt noch Kernel und Initramfs liegen ist dabei aus der Sicherheitsperspektive irrelevant, da der dort befindliche EFI-Loader so wie so ohne Umgehung der Systemverschlüsselung manipuliert werden kann.

          Falsch. Wenn man nur den Bootloader manipulieren kann, ist der Angriffsvektor deutlich kleiner als wenn man den Bootloader, Konfigurationen, initrd und Kernel manipulieren kann.

          schard Gegen eine solche Manipulation hilft einzig und allein Secure Boot in Kombination mit einem TPM.

          TPM ist empfehlenswert, aber keine notwendige Komponente für einen funktionierenden Secure Boot.
          Aber da Arch Linux keine Kernel und Bootloader signiert, ist Secure Boot für Arch Linux Nutzer praktisch nutzlos oder nur mit grossem Aufwand so realisierbar, dass Secure Boot tatsächlich etwas nützt.
          Einfach blind drauflos signieren wäre dann ein "Signed Boot" und kein "Secure Boot" mehr.

          bubba In der Anleitung für Einsteiger steht

          Die Anleitung für Einsteiger ist genau dies: Eine Anleitung für Einsteiger, die viele Dinge vereinfacht. Die Vereinfachung macht es Einsteigern leichter. Sie ist aber nicht dazu geeignet, sich in die Materie tiefer einzuarbeiten.

          bubba Also wäre es eigentlich egal wo ich das einbinde, hauptsache es wird natürlich eingebunden?

          Im Prinzip ist es egal, wohin du die ESP einbindest. In der Praxis hat sich /boot/efi als traditioneller Einhängepunkt durchgesetzt. Der Einhängepunkt /efi macht aus logischer Sicht am meisten Sinn und /boot sehe ich praktisch nur im Arch Linux Umfeld und bei systemd-boot.

          Nur der Vollständigkeit halber: Die ESP muss nur dann eingebunden sein, wenn auf der ESP der Bootloader installiert oder aktualisiert wird. Die ESP ist für Arch Linux eigentlich nicht relevant. Bei meinen unverschlüsselten Arch Installationen habe ich in Arch Linux keinen Bootloader installiert und auch die ESP nicht eingebunden. Ich lasse Arch dann immer vom Grub eines anderen Linux starten.

          bubba Könnte das auch nach /mnt/XYZ einbinden?

          Ja, könntest du. Aber dann musst du dich selbst fragen, warum das sinnvoll sein sollte. Und bei Problemen müsstest du hier im Forum jedes Mal erklären, was du dir dabei gedacht hast.

          bubba Denke ich halte mich dann einfach an die Anleitung um Probleme zu vermeiden bei der Installation.

          Vor vielen Jahren habe ich auch mit der Anleitung für Einsteiger angefangen. Damit solltest du ein funktionierendes System installieren können.

          • schard hat auf diesen Beitrag geantwortet.

                            Gerry_Ghetto Bist du sicher? Es würde doch reichen, wenn man die benötigten Dateien auf die ESP kopiert und /boot auf der Partition mit dem Wurzelverzeichnis belässt, oder nicht?

                            Warum sollte man Kernel und Initramfs kopieren, wenn man sie bereits unter /boot hat?

                            Gerry_Ghetto Einen Bootloader zu verschlüsseln, ist auch ziemlich unnötig, da er praktisch keine schützenswerten Daten enthält (Verschlüsselung dient primär dem Schutzziel Vertraulichkeit).

                            Falsch. Mit einem manipulierten Bootloader kann man beliebige Software auf dem System laden.

                            Gerry_Ghetto Falsch. Wenn man nur den Bootloader manipulieren kann, ist der Angriffsvektor deutlich kleiner als wenn man den Bootloader, Konfigurationen, initrd und Kernel manipulieren kann.

                            Blödsinn. Wenn ich den Bootloader manipulieren kann, kann ich diesen durch beliebiges ersetzen und alle mögliche Software auf dem System laden. Z.B. einen manipulierten Kernel. Und wenn der Kernel und / oder das Initramfs unverschlüsselt dort liegen, kann ich diese auch direkt manipulieren.
                            Darüber hinaus erachte ich Kernel und Initramfs nicht als vertrauliche Daten.

                            Gerry_Ghetto Aber da Arch Linux keine Kernel und Bootloader signiert, ist Secure Boot für Arch Linux Nutzer praktisch nutzlos oder nur mit grossem Aufwand so realisierbar, dass Secure Boot tatsächlich etwas nützt.
                            Einfach blind drauflos signieren wäre dann ein "Signed Boot" und kein "Secure Boot" mehr.

                            Aufwändig ist das allemal. Deswegen mache ich das auch nicht. Das Signieren muss natürlich in einem vertrauenswürdigen Kontext erfolgen. Und natürlich gilt wie immer: Garbage in → garbage out.

                            Deinen übrigen Ausführungen stimme ich zu.

                                      Gibt es irgendwo ein schönes Diagramm vom Bootvorgang, angefangen vom EFI über die ESP mit den diversen Komponenten bis zum Auffinden von / ?
                                      Oder traut sich jemand zu, so ein Schaltbild mal mittels Markdown hier zu entwerfen?
                                      Dann könnte man dieses Diagramm für die verschiedenen Anwendungsfälle später weiter differenzieren.

                                      Das Mounten der ESP ist zwar für die Installation wichtig und für das spätere Updaten aber verstehen kann man das Ganze erst, wenn man den Bootvorgang betrachtet.

                                      • Dirk hat auf diesen Beitrag geantwortet.

                                        tuxnix
                                        Mermaid ist leider nicht unterstützt ...

                                        graph TD;
    A-->B;
    A-->C;
    B-->D;
    C-->D;
                                        • tuxnix hat auf diesen Beitrag geantwortet.

                                            Vorneweg: Ich musste etwas basteln, um verschachtelte Zitate einigermassen sinnvoll darstellen zu können.

                                            schard

                                            Gerry_Ghetto Einen Bootloader zu verschlüsseln, ist auch ziemlich unnötig, da er praktisch keine schützenswerten Daten enthält (Verschlüsselung dient primär dem Schutzziel Vertraulichkeit).

                                            Falsch. Mit einem manipulierten Bootloader kann man beliebige Software auf dem System laden.

                                            Die Verschlüsselung dient primär dem Schutzziel der Vertraulichkeit und nicht der Integrität. Manipulationen verletzen die Integrität einer Datei. Wenn du Manipulationen erkennen willst, brauchst du andere Mechanismen, z.B. Signaturen und Hashes. Verschlüsselte Dateien können (mehr oder minder) zielgerichtet manipuliert werden. Bei der Entschlüsselung wird dann einfach die manipulierte Datei entschlüsselt.
                                            Natürlich ist es schwieriger, verschlüsselte Dateien zu manipulieren. Aber um Manipulationen zu erkennen oder zu verhindern, ist die Verschlüsselung nicht das erste Mittel der Wahl.

                                            schard

                                            Gerry_Ghetto Falsch. Wenn man nur den Bootloader manipulieren kann, ist der Angriffsvektor deutlich kleiner als wenn man den Bootloader, Konfigurationen, initrd und Kernel manipulieren kann.

                                            Blödsinn. Wenn ich den Bootloader manipulieren kann, kann ich diesen durch beliebiges ersetzen und alle mögliche Software auf dem System laden. Z.B. einen manipulierten Kernel. Und wenn der Kernel und / oder das Initramfs unverschlüsselt dort liegen, kann ich diese auch direkt manipulieren.
                                            Darüber hinaus erachte ich Kernel und Initramfs nicht als vertrauliche Daten.

                                            Ich glaube, du hast mich falsch verstanden. Ich wollte nicht sagen, dass Manipulationen am Bootloader ungefährlich sind, sondern ich wollte nur sagen, dass unverschlüsselte Kernel und initramfs zusätzlich zum unverschlüsselten Bootloader einen viel grösseren Angriffsvektor bieten, da ein Angreifer viel mehr Möglichkeiten und Tools zur Verfügung hat. Und somit ist dies durchaus relevant für die Sicherheitsperspektive.

                                            Und das initramfs kann Schlüssel enthalten, um LUKS-Container automatisch zu entschlüsseln.

                                            • schard hat auf diesen Beitrag geantwortet.
                                            • schard gefällt das.

                                                  Gerry_Ghetto Und das initramfs kann Schlüssel enthalten, um LUKS-Container automatisch zu entschlüsseln.

                                                  Wer sowas macht lebt in Sünde und verdient was immer ihm passiert.

                                                      schard Vor allem führt es die Verschlüsselung ad-absurdum, wenn der Schlüssel im Klartext auslesbar ist ohne ihn zu kennen.

                                                        schard

                                                        Gerry_Ghetto Und das initramfs kann Schlüssel enthalten, um LUKS-Container automatisch zu entschlüsseln.

                                                        Wer sowas macht lebt in Sünde und verdient was immer ihm passiert.

                                                        Dann lebe ich wohl in Sünde. Aber bei mir ist /boot verschlüsselt. Ich mache das so, damit ich die Passphrase beim Starten nicht zweimal eingeben muss.

                                                        Ich gehe davon aus, dass ich weiss, was ich tue. Aber es gibt wahrscheinlich auch Leute, die nicht wissen, was sie tun. Dementsprechend kann es auch unverschlüsselte initramfs geben mit sensiblen Daten.