0x1A Security Violation

[Terenz]

Liebe Leute,

nach dem Austausch der Tastatur meines Medion Laptop (MD63920) durch Medion auf Garantie ging leider nix mehr: kein Bootloader, stattdessen die Fehlermeldung „Verification failed 0x1A Security Violation“.
Danach habe ich im Bios ein Admin Password gesetzt, und dort ‚Secure Boot‘ auf ‚disabled‘ gesetzt. Ergebnis: alles funktioniert normal.
Soweit, so gut. Ich möchte aber nicht dauerhaft ohne ‚Secure Boot‘ arbeiten. Was könnte ich tun?

[kalle123]

Hallo, außer der Laptop Type verrätst du ja nicht sehr viel.

Zumindest würde es helfen, wenn du sagst, was du auf dem Gerät installiert hast ...

cu KH

[cosinus]

Soweit, so gut. Ich möchte aber nicht dauerhaft ohne ‚Secure Boot‘ arbeiten. Was könnte ich tun?

Secure Boot ist ziemlich unnötig. Das wurde mal von Microsoft ursprünglich mit Windows 8 für UEFI-Systeme eingeführt. Es sorgt dafür, dass nur ordentlich signierte Kernel booten können.

[Terenz]

Sorry,
in meiner dauerhaft stabilen Naivität hatte ich angenommen, da der Rechner schon bei der Abarbeitung der BIOS Konfiguration hängen bleibt, daß Debian mit dem Problem nix zu tun hat.
die Debian Version ist 11.4 Ochsenauge
das BIOS ist von AMI 1.01.00.MN.V01
Installiert ist auf dem Rechner nicht sehr viel (ist mein 'Unterwegs'-Büro); die wichtigsten Programme sind für mich FreeCAD (=appimage, v.21), versch. Render Engines (LuxCore, PovRay), Gimp & die üblichen Standard-Anwendungen.

Cheers, T

[kalle123]

https://wiki.debian.org/SecureBoot

Starting with Debian version 10 ("Buster"), Debian included working UEFI Secure Boot to make things easier.

Gerade fand an anderer Stelle hier im Forum eine Diskussion zum Thema 'secure boot' statt

viewtopic.php?t=188956&hilit=secure+boot

Gruß KH

[niemand]

Ich möchte aber nicht dauerhaft ohne ‚Secure Boot‘ arbeiten. Was könnte ich tun?

Die Frage ist ja: nutzt du Funktionen, die ein aktiviertes Secure Boot voraussetzen, etwa TPM2? Entgegen der hier manchmal vorgebrachten Behauptung, dass es nur für Windows sinnvoll wäre, ist das eigentlich eine ziemlich gute und sehr wohl auch unter Linux nutzbare Sache; allerdings muss man’s derzeit noch aktiv einrichten – wenn man das nicht gemacht hat, wird man auch keine Nachteile haben, wenn man’s abschaltet.

Interessanter wäre die Frage, warum es bei dir nach der Reparatur den Fehler triggert, während es davor kein Problem gab. Wurde im Rahmen der Reparatur eine neue Firmwareversion aufgespielt? War Secure Boot vorher deaktiviert und wurde für etwa deren Diagnosesystem aktiviert? Haben sie an deiner Installation herumgepfuscht?

[Terenz]

Erstmal vielen Dank für die sehr konkreten Hinweise. Einiges habe ich zwischenzeitlich schon gelesen, anderes steht jetzt auf der Leseliste. Zwischendurch muß ich aber auch noch ein bischen Geld verdienen.

Die Frage, was die Medion Leute da wohl gemacht haben, außer auftragsgemäß die Tastatur auszutauschen, habe ich mir auch gestellt, aber nicht beantworten können. Jedenfalls war auf dem Bios kein Admin Password drauf, als ich den Rechner zurückbekommen habe. Und nur mit einem solchen Password kann man in dem BIOS Secure Boot an- und abschalten.

In jedem Falle habe ich Secure Boot nicht selbst eingerichet, folglich dürfte es - wenn ich das richtig verstanden habe, auch bisher nix geschützt haben.

Auf jeden Fall gibt es jetzt für mich einiges zu tun, und wenn ich nicht mehr weiter weiß, gründe ich keinen Arbeitskreis, sondern frage in diesem Forum noch mal nach, in dem auch seltenen Gästen zeitnah kompetent geholfen wird.

Bon Soir,
Terenz

[rhHeini]

Die Frage, was die Medion Leute da wohl gemacht haben, außer auftragsgemäß die Tastatur auszutauschen, habe ich mir auch gestellt, aber nicht beantworten können. Jedenfalls war auf dem Bios kein Admin Password drauf, als ich den Rechner zurückbekommen habe. Und nur mit einem solchen Password kann man in dem BIOS Secure Boot an- und abschalten.

Du kannst davon ausgehen dass die noch ein paar mehr Möglichkeiten in der Hinterhand haben und das den Kunden nicht verraten .... wie z.B. auf Auslieferzustand zurücksetzen.

[cosinus]

War das BIOS denn komplett verstellt, als du das Notebook wiederbekommen hast?
Ich könnte mir gut vorstellen, dass die das BIOS vor dem Rückversand einfach auf Standardwerte zurücksetzten. Vermutlich meinst du auch, dass man in diesem BIOS ein Adminpasswort setzen muss, sonst kann man Secure Boot nicht abschalten. Oder meinst du das nicht?

[Terenz]

Komplett verstellt waren die Bios-Einträge wohl nicht. Nur die Boot-Sequenz kam mir komisch vor.

Das Secure Boot ließ sich von mir - soviel ist sicher - nicht abschalten, ohne ein Admin PW zu vergeben.
Kurios ist aber folgendes: Auf dem Medion Reparaturschein steht unter 'Hinweise': "Ein Belastungstest wurde fehlerfrei durchgeführt. System durch Password geschützt." Welches Password ?? Mir wurde keines genannt. Ich konnte auch, wie angesprochen, ein PW meiner Wahl setzen.

Und schließlich auch noch dieses:
"Diagnose Werkstatt: Verformt (LCD-Anzeige, LCD-Anzeige).
Maßnahmen: Folgende Hardwarekomponente wurde ersetzt (LCD-Anzeige, LCD-Anzeige)."
Der von mir monierte Defekt war, wie erwähnt, eine in der Mitte aufgewölbte Tastatur.

[rhHeini]

Passt doch alles super zusammen.

[cosinus]

Ein Passwort ist nicht gleich Passwort. Im BIOS kann man diverse Passwörter vergeben:

• user-/supervisor password
• poweron password
• boot device control password
• SSD/HDD password (und da kann man noch zwischen user und master unterscheiden )

Und schließlich gibt es noch die Passwörter im Betriebssystem auf der internen SSD/HDD. Welches "password" meint Medion nun also?

Auch wenn immer wieder propagiert wird, dass Secure Boot kein Versuch sein soll, andere OS auszusperren - wenn man extra ein supervisor password festlegen muss nur um das abschalten zu können, dann ist das definitiv eine weitere Gängelei und Erschwerung, Betriebssysteme zu booten, die noch kein Secure Boot können.