Gelöst EFI-Fehlermeldung beim Booten

susejunky · 8 Apr. 2023

Hallo @BeastXXL ,

da ich secureboot nicht nutze, habe ich mich auch noch nie richtig damit befasst.

Ich habe das Thema lediglich in der openSUSE-Mailingliste und im openSUSE-Forum gelesen und kann Dich nur an diese beiden Stellen verweisen (der von mir unter #19 verlinkte Mailinglisten-Beitrag beinhaltet Verweise auf das openSUSE-Forum und auf Bugzilla).

Tut mir leid! Aber vielleicht findet sich hier im Forum noch jemand, der Dir weiterhelfen kann.

Viele Grüße

susejunky

BeastXXL · 14 Apr. 2023

Als ich auf der Suche war, wie andere einen Reset vom SBAT machen (würde), stieß ich auf diese Seite.
Mit meiner Vorgehensweise war ich gar nicht so falsch, denn im letzten Absatz steht:

To delete the policy, disable secure boot, run mokutil --set-sbat-policy delete, reboot, boot into the old shim to apply, and then turn secure boot back on again. Please note that booting the new shim after the reset will reapply the “previous” policy again.

Mich wundert, dass dort behauptet wird, dass mit dem shim-Update auf 15.7 die grub 1-Ebene nicht mehr läd und man bitte auf neuere Versionen der Distribution wechseln soll. Ist openSuse Leap 15.4 in diesem Punkt so alt, dass es hier Probleme gibt? Wenn ja, wie fixt man das?

Und noch eine Frage:
Vermutlich ist bootx64.efi der Fallback Bootloader. Wenn ich unter Windows der Pfad auf diese Datei statt auf shim lenke, sollte das Booten doch ohne Fehlermeldung funktionieren. Wenn dem so ist, warum sollte ich shim verwenden? Was ist der Vorteil von shim? Oder gibt es einen (großen?) Nachteil bei bootx64.efi?

josef-wien · 14 Apr. 2023

Auf Grund von Beitrag 3 vermute ich, daß \EFI\BOOT\BOOTX64.EFI eine Kopie von \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI ist.

\EFI\OPENSUSE\SHIM.EFI benötigst Du bei aktiviertem "secure boot". \EFI\OPENSUSE\GRUBX64.EFI funktioniert nur ohne "secure boot" (und kann laut Beitrag 1 im UEFI-Boot-Menü ausgewählt werden).

susejunky · 15 Apr. 2023

Hallo @BeastXXL ,

BeastXXL schrieb:
... warum sollte ich shim verwenden? Was ist der Vorteil von shim?

siehe:

https://doc.opensuse.org/documentation/leap/reference/single-html/book-reference/index.html#sec-uefi-secboot schrieb:
In the world of UEFI, securing the bootstrapping process means establishing a chain of trust. The “platform” is the root of this chain of trust; in the context of openSUSE Leap, the mainboard and the on-board firmware could be considered the “platform”. In other words, it is the hardware vendor, and the chain of trust flows from that hardware vendor to the component manufacturers, the OS vendors, etc.

The trust is expressed via public key cryptography. The hardware vendor puts a so-called Platform Key (PK) into the firmware, representing the root of trust. The trust relationship with operating system vendors and others is documented by signing their keys with the Platform Key.

Finally, security is established by requiring that no code will be executed by the firmware unless it has been signed by one of these “trusted” keys—be it an OS boot loader, some driver located in the flash memory of some PCI Express card or on disk, or be it an update of the firmware itself.

To use Secure Boot, you need to have your OS loader signed with a key trusted by the firmware and you need the OS loader to verify that the kernel it loads can be trusted.

Viele Grüße

susejunky

BeastXXL · 16 Apr. 2023

Zunächst einmal zu meiner Frage, wozu man shim benötigt: Die Frage war etwas zu kurz gedacht, da ja nicht jeder ein Dualboot-PC hat und dann natürlich shim braucht, wenn er/sie ein Linux mit aktiviertem SecureBoot booten möchte.

Wie man sehen kann, scheint das Problem gelöst zu sein (jedenfalls hoffe ich das

).

Das Problem dabei ist, dass ich nicht wirklich weiß, was ich gemacht habe bzw. was genau die Lösung bewirkt hat. Ich versuche das mal zu rekonstruieren:
Mit deaktiviertem SecureBoot habe ich

Code:

sudo mokutil --set-sbat-policy delete

ausgeführt und bei dem folgenden Reboot gesehen, dass die Fehlermeldung noch existiert.
Den obigen Code habe ich noch einmal ausgeführt, dann shim auf Vers. 15.4 downgradet. Nach dem Neustart war alles super (keine Fehlermeldung mehr).
Neustart, aber SecureBoot wieder aktiviert. Auch alles gut, aber leider shim auf Vers. 15.4. Und da ich keine Lust hatte, ein Update bei shim zu blocken, habe ich weiter experimentiert.
Daher wieder Neustart, dabei SecureBoot deaktiviert, den obigen Code ausgeführt, shim auf Vers. 15.7 upgegradet, Neustart. Nun kam ich zum ersten Mal auf die GRUB-Konsole. Da ich keine Ahnung habe/hatte, was ich hätte machen sollen, habe ich Reset gedrückt, SecureBoot deaktiviert und bin wieder ohne Fehlermeldung ins GRUB-Boot-Menü gekommen.
Wieder den obigen Code ausgeführt, Neustart, aber SecureBoot aktiviert, wieder auf die GRUB-Konsole gekommen.
Wieder Reset gedrückt. Ich wollte wieder mit deaktiviertem SecureBoot neustarten, da fiel mein Blick zufällig auf den Eintrag, welcher BootManager geladen werden soll. Statt meinem üblichen Windows Boot Manager (der nur entsteht, wenn ich unter Windows den Pfad auf shim leite), stand dort der "normale" openSuse-Boot-Loader (also der mit GRUBX64.EFI). Da das natürlich nicht mit SecureBoot funktioniert, wollte ich eigentlich wieder meinen alten Windows Boot Manager einstellen.
Dieser war nicht mehr da, dafür aber der opensuse-secureboot-Boot-Manager (der auch auf shim verweist). Den habe ich dann eingestellt und gebootet.
Siehe da: keine Fehlermeldung mehr und die Kistet bootet mit aktivem SecureBoot ganz normal.
Hier noch ein paar Ausgaben:

Code:

beastxxl@linux-5099:~> su
Passwort:
linux-5099:/home/beastxxl # efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0006,0005
Boot0000* opensuse-secureboot   HD(2,GPT,73a54532-793d-4332-97f9-48d9d4f783bb,0x109000,0x31800)/File(\EFI\OPENSUSE\SHIM.EFI)
Boot0005* opensuse      HD(2,GPT,73a54532-793d-4332-97f9-48d9d4f783bb,0x109000,0x31800)/File(\EFI\OPENSUSE\GRUBX64.EFI)..BO
Boot0006* Windows Boot Manager  HD(2,GPT,73a54532-793d-4332-97f9-48d9d4f783bb,0x109000,0x31800)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)..BO
linux-5099:/home/beastxxl # mokutil --sb-state
SecureBoot enabled
linux-5099:/home/beastxxl # sudo zypper se -s shim
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                  | Type       | Version              | Arch   | Repository
---+-----------------------+------------+----------------------+--------+-------------------------------------------------------------
   | python3-ec2publishimg | Paket      | 2.0.0-1.20           | noarch | openSUSE-Leap-15.4-Oss
   | rshim                 | Paket      | 2.0.6.1.5-bp154.1.33 | x86_64 | openSUSE-Leap-15.4-Oss
i+ | shim                  | Paket      | 15.7-150300.4.11.1   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
v  | shim                  | Paket      | 15.4-4.7.1           | x86_64 | openSUSE-Leap-15.4-Oss
   | shim                  | Quellpaket | 15.7-150300.4.11.1   | noarch | Update repository with updates from SUSE Linux Enterprise 15
   | shim-susesigned       | Paket      | 15.4-3.10.1          | x86_64 | openSUSE-Leap-15.4-Oss
linux-5099:/home/beastxxl #

Ich freue mich auf jeden Fall, dass das Problem nicht mehr existiert. Bitte Daumen drücken, dass es so bleibt.

BeastXXL · 16 Apr. 2023

OK, leider hat es doch nicht geklappt.

Nach einem Shutdown (für über eine Stunde) war die Fehlermeldung wieder da.
Bin jetzt bei shim auf Vers. 15.4 runter, habe es für Updates geblockt und nun keine Fehlermeldung mehr. Das Problem ist zwar "quasi gelöst", aber nicht richtig.

Daher bitte Hinweise geben, wie ich das Problem beheben kann. Bin nun wirklich am Ende meines Lateins.

susejunky · 17 Apr. 2023

Hallo @BeastXXL ,

BeastXXL schrieb:
Daher bitte Hinweise geben, wie ich das Problem beheben kann. Bin nun wirklich am Ende meines Lateins.

wenn ich den zugehörigen Fehlerbericht richtig verstehe, dann gibt es im Augenblick noch keine zuverlässige Lösung.

Ich würde secureboot vorerst deaktivieren und den Fortschritt der Fehlerbearbeitung verfolgen.

Viele Grüße

susejunky

BeastXXL · 17 Apr. 2023

Hallo @susejunky,

vielen Dank für den Link zum Fehlerbericht! Ich habe schon langsam an mir zu zweifeln begonnen. Dann besteht ja die berechtigte Hoffnung, dass das Problem tatsächlich genauer untersucht und wahrscheinlich sogar gelöst wird.

Aber, wenn schon diese Frage im Raum steht (Comment 17):

Question is how the new shim was installed and executed at least once and later the old one took over again, from some mystery location.

dann brauch ich mich nicht wundern, dass ich nicht weiterkomme.

Ja, dann werde ich wohl secureboot erstmal abschalten und den Standard-opensuse-Bootmanager (GRUBX64.efi) verwenden.

BeastXXL · 3 Mai 2023

Gestern gab es ein Update der shim-Datei. Hat aber nicht die erhoffte Wirkung gezeigt. Bin mir aber nicht sicher, ob ich einen Fehler gemacht habe.
Hab das Update installiert, unter Windows den Pfad für den Win-Boot-Manager auf shim gelenkt (bcdedit ...) und beim Neustart im BIOS SecureBoot aktiviert und den passenden Bootmanager bei den Prioritäten auf #1 gesetzt.
Beim Neustart kam dann der Bluescreen mit der MOK-Sache. Und hier weiß ich nicht genau, ob ich alles richtig gemacht habe.
Bei der Passworteingabe habe ich das Linux-Passwort genommen, was mich dann zur Auswahl brachte "Reboot, Key from disk, Key from hash". Hier habe ich Reboot genommen, weil mir das am Sichersten schien.

Lange Rede, kurzer Sinn: ich bekomme die selbe Fehlermeldung wie früher und bin mir nicht sicher, ob ich bei der MOK-Aktion etwas anders hätte machen müssen, damit die Fehlermeldung verschwindet.

Bin jetzt wieder ohne SecureBoot auf den opensuse-Bootmanager.

susejunky · 5 Mai 2023

Hallo @BeastXXL ,

BeastXXL schrieb:
Bei der Passworteingabe habe ich das Linux-Passwort genommen, ...

was muss man sich unter "Linux-Passwort" vorstellen? Das Kennwort eines Benutzers? Das Kennwort des Administrators ("root")?

BeastXXL schrieb:
Beim Neustart kam dann der Bluescreen mit der MOK-Sache. Und hier weiß ich nicht genau, ob ich alles richtig gemacht habe.

wie bereits gesagt, ich nutze kein secureboot aber ich hatte mir einmal folgendes notiert (aber nie verifiziert!):

Code:

cd /etc/uefi/certs

mokutil --import NAME_DES_AKTUELLEN_ZERTIFIKATS.crt --root-pw

systemctl isolate reboot

Beim Neustart wird ein blauer Bildschirm angezeigt mit

(select)
    "Press any key to perform MOK management"

    - continue boot
    - enroll MOK
    - enroll key from disk
    - enroll hash from disk
    
auswählen:     - enroll MOK

dann wird angezeigt:

    - View key0
    - Continue

auswählen:     - Continue

dann wird angezeigt:

Enroll the key(s)?
    - No
    - Yes

auswählen:     - Yes

dann "root"-Kennwort eingeben

dann wird angezeigt:

Perform MOK management
    - reboot
    - Enroll key from disk
    - Enroll hash from disk

auswählen:     - reboot

Viele Grüße

susejunky

BeastXXL · 5 Mai 2023

Hallo @susejunky ,

ja, ich hatte das Admin-Passwort gemeint.

Ich kann es nicht mehr 100% bestätigen, aber anhand deines Ablaufes glaube ich, dass ich bei den einzelnen Punkten intuitiv die "richtige" Auswahl gewählt hatte. Bei meinem Post #29 meinte ich, dass ich mir beim letzten Punkt (deines Ablaufes) nicht sicher war, ob ich mit "reboot" die richtige Wahl getroffen hatte. Aber anscheinend habe ich es.

Hat nur leider nicht geholfen

Viele Grüße,
B.

BeastXXL · 28 Nov. 2024

Der Vollständigkeit halber wollte ich nach langer Zeit zu diesem Problem noch die Lösung präsentieren.

Beunruhigt durch die Meldung, dass ein RootKit für Linux gesichtet wurde, wollte ich noch einmal testen, ob und wie mein Problem mit SecureBoot und shim gelöst werden kann.

Es ist ganz einfach: die Version 15.8 funktioniert bei mir einfach so, wie ich es gewohnt war. Im BIOS SecureBoot angestellt und "opensuse-secureboot" als Bootloader ausgewählt, Neustart.

Einziger Wermutstropfen: ich denke, das MOK-Prozedere kam nach dem Neustart. Leider habe ich fast nichts sehen können (nur eine gelbe Ecke auf blauem Grund) und habe nur Enter gedrückt. Irgendwann erschien ein "OK"-Button auf blauem Grund und mit Enter kam ich dann zum GRUB-Bootmenü.

Zur Sicherheit noch einmal Heruntergefahren und ca. halbe Minute vom Strom getrennt. Neustart funzt wie gewohnt.

Wie bekomme ich heraus, was bei dem MOK-Prozedere passiert ist und ob alles mit den Keys in Ordnung ist? Ist alleine deswegen alles in Ordnung, weil ich wieder mit SecureBoot zum GRUB-Bootmenü komme und Linux starten kann?

Viele Grüße,
B.

susejunky · 29 Nov. 2024

Hallo @BeastXXL ,

BeastXXL schrieb:
Wie bekomme ich heraus, was bei dem MOK-Prozedere passiert ist und ob alles mit den Keys in Ordnung ist? Ist alleine deswegen alles in Ordnung, weil ich wieder mit SecureBoot zum GRUB-Bootmenü komme und Linux starten kann?

hast Du Dir die in Beitrag #24 verlinkte openSUSE-Dokumentation schon durchgelesen?

Code:

bootctl status

liefert erste Informationen zum Startvorgang (z.B. ob secureboot dabei aktiv war) und mit mokutil lässt sich dann mehr zu den verschiedenen Schlüsseln herausfinden (siehe dazu auch man mokutil).

Viele Grüße

susejunky

BeastXXL · 29 Nov. 2024

Bin mir nicht sicher, aber für mich sieht's ok aus:

Code:

beastxxl@linux-5099:~> bootctl status
systemd-boot not installed in ESP.
System:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: enabled (user)
  TPM2 Support: no
  Boot into FW: supported

Current Boot Loader:
      Product: n/a
     Features: ✗ Boot counting
               ✗ Menu timeout control
               ✗ One-shot menu timeout control
               ✗ Default entry control
               ✗ One-shot entry control
               ✗ Support for XBOOTLDR partition
               ✗ Support for passing random seed to OS
               ✗ Load drop-in drivers
               ✗ Support Type #1 sort-key field
               ✗ Support @saved pseudo-entry
               ✗ Support Type #1 devicetree field
               ✗ Enroll SecureBoot keys
               ✗ Retain SHIM protocols
               ✗ Boot loader sets ESP information
          ESP: n/a
         File: └─n/a

Random Seed:
 System Token: not set
       Exists: no

Available Boot Loaders on ESP:
          ESP: /boot/efi (/dev/disk/by-partuuid/73a54532-793d-4332-97f9-48d9d4f783bb)
         File: └─/EFI/BOOT/bootx64.efi

Boot Loaders Listed in EFI Variables:
        Title: opensuse-secureboot
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/73a54532-793d-4332-97f9-48d9d4f783bb
         File: └─/EFI/OPENSUSE/SHIM.EFI

        Title: opensuse
           ID: 0x0005
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/73a54532-793d-4332-97f9-48d9d4f783bb
         File: └─/EFI/OPENSUSE/GRUBX64.EFI

        Title: Windows Boot Manager
           ID: 0x0006
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/73a54532-793d-4332-97f9-48d9d4f783bb
         File: └─/EFI/MICROSOFT/BOOT/BOOTMGFW.EFI

        Title: Windows Boot Manager
           ID: 0x0001
       Status: inactive
    Partition: /dev/disk/by-partuuid/73a54532-793d-4332-97f9-48d9d4f783bb
         File: └─/EFI/OPENSUSE/SHIM.EFI

Boot Loader Entries:
        $BOOT: /boot/efi (/dev/disk/by-partuuid/73a54532-793d-4332-97f9-48d9d4f783bb)
        token: opensuse-leap

0 entries, no entry could be determined as default.
beastxxl@linux-5099:~> ls -lR /boot/efi/EFI/opensuse/
/boot/efi/EFI/opensuse/:
insgesamt 3957
-rwxr-xr-x 1 root root      58 21. Nov 19:29 boot.csv
-rwxr-xr-x 1 root root     137 21. Nov 19:29 grub.cfg
-rwxr-xr-x 1 root root 2074624 21. Nov 19:29 grub.efi
-rwxr-xr-x 1 root root  155648 21. Nov 19:29 grubx64.efi
-rwxr-xr-x 1 root root  852456 21. Nov 19:29 MokManager.efi
-rwxr-xr-x 1 root root  965672 21. Nov 19:29 shim.efi
beastxxl@linux-5099:~> ls -al /etc/uefi/certs/
insgesamt 20
drwxr-xr-x 2 root root 4096  4. Nov 16:52 .
drwxr-xr-x 3 root root 4096 18. Okt 16:01 ..
-rw-r--r-- 1 root root 1177 28. Mai 2024  1F673297-kmp.crt
-rw-r--r-- 1 root root 1288  2. Okt 10:47 76B6A6A0.crt
-rw-r--r-- 1 root root 1257 18. Okt 16:01 BCA4E38E-shim.crt
beastxxl@linux-5099:~> mokutil -l
[key 1]
SHA1 Fingerprint: bc:a4:e3:8e:d1:84:2b:c8:6f:f7:6d:4d:a7:49:51:f1:62:88:59:f8
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
        Validity
            Not Before: Apr 18 14:33:41 2013 GMT
            Not After : Mar 14 14:33:41 2035 GMT
        Subject: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:cd:fd:ab:d7:2a:84:f8:81:c3:36:35:50:35:2c:
                    c7:ec:04:f1:f4:d6:cc:60:4b:c8:13:b3:74:9b:bd:
                    f6:c4:3f:63:3e:66:51:f2:7e:3f:6e:7c:76:7b:71:
                    9d:69:21:2a:15:9b:aa:a5:e5:56:c8:79:98:12:35:
                    cd:7b:63:8c:b8:37:29:ee:77:50:bc:b7:64:8f:fe:
                    26:4a:e5:83:18:1c:6c:5d:b4:87:ef:d7:33:c4:f8:
                    1a:3f:29:9a:84:5a:01:e0:d9:81:6d:31:77:62:29:
                    f5:c1:65:14:df:4a:1d:fb:b7:4a:46:3b:f3:90:8b:
                    a2:b8:26:2a:0a:c3:9e:54:b5:03:60:81:e3:d9:58:
                    35:ed:b0:0b:e2:4f:6b:ef:69:ba:8b:47:df:a4:c5:
                    da:d0:d2:25:aa:85:63:3e:2f:05:db:4c:69:02:a6:
                    0e:35:b3:c2:ae:70:b0:ff:25:80:31:c7:0d:39:74:
                    a3:c0:a4:50:cd:9f:3f:85:b7:62:fb:7b:92:6d:c8:
                    1e:12:d2:ee:0f:96:f4:01:30:d1:ed:e2:10:ec:d2:
                    b2:b8:a1:e1:c5:2d:b3:b1:1e:f8:c5:fa:79:68:9d:
                    e5:a1:92:0f:5e:4f:45:42:7e:90:18:55:8c:fe:c2:
                    13:31:b8:21:de:ac:30:9d:99:e1:6b:44:61:0c:43:
                    3d:75
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                EC:AB:0D:42:C4:56:CF:77:04:36:B9:73:99:38:62:96:5E:87:26:2F
            X509v3 Authority Key Identifier:
                keyid:EC:AB:0D:42:C4:56:CF:77:04:36:B9:73:99:38:62:96:5E:87:26:2F
                DirName:/CN=SUSE Linux Enterprise Secure Boot CA/C=DE/L=Nuremberg/O=SUSE Linux Products GmbH/OU=Build Team/emailAddress=build@suse.de
                serial:01
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        12:be:2c:85:85:5a:94:59:cd:49:51:08:17:c1:d9:63:27:29:
        d3:9e:9d:3f:15:03:99:24:14:9e:ed:77:41:18:f9:b2:f7:5f:
        b7:21:3a:ab:5e:0c:aa:a3:fd:b5:f0:a2:12:89:09:79:dd:09:
        70:a6:af:9c:22:21:91:02:26:b5:0f:ba:7b:c1:b8:3b:c2:c8:
        3e:4e:bb:74:cd:91:57:7a:cd:f4:c1:f6:2a:e6:98:df:59:a7:
        44:04:08:0d:09:f7:e4:07:3d:74:4d:28:cb:8d:0a:d5:c1:6e:
        4d:fb:25:09:32:8a:be:af:ce:37:4f:35:79:e8:7b:b2:e8:b0:
        4e:56:12:39:c9:3c:fb:5f:b8:b6:ad:22:58:7f:24:16:33:ca:
        1e:1c:b8:fc:62:5e:4c:ac:e0:7d:83:24:ee:9b:10:78:98:e2:
        e6:4a:ac:0a:cc:98:94:07:4a:69:18:fa:21:74:b5:12:48:42:
        83:76:8e:8a:48:7f:c6:8d:1e:cc:ee:e0:62:73:09:f3:c0:90:
        f7:49:57:d3:f6:7c:7d:1c:a1:76:9d:76:65:1e:fb:39:56:24:
        10:ae:ed:ea:3f:5b:5c:ea:2d:1e:5c:49:cf:4d:85:b6:fb:39:
        19:70:dd:1e:e6:21:f2:a3:31:19:1e:c3:b4:ae:f7:35:a7:a1:
        b4:61:6b:4e
beastxxl@linux-5099:~>

Oder sollte die Ausgabe von

Bash:

bootctl status

anders aussehen?

Gelöst EFI-Fehlermeldung beim Booten

susejunky

Moderator

BeastXXL

josef-wien

susejunky

Moderator

BeastXXL

BeastXXL

susejunky

Moderator

BeastXXL

BeastXXL

susejunky

Moderator

BeastXXL

BeastXXL

susejunky

Moderator

BeastXXL