Bad shim signature, Secure Boot probléma

Fórum: 

Sziasztok,

Misztikus hibával szívok. Három SSD van a gépemben. Egy Debian, egy Linux Mint és egy Windows 10. A Debian és a Linux Mint önállóan működő, teljes értékű rendszerek, saját EFI-jük van. A Windows 10 rendszerbetöltője a Debian SSD-jén van.

Bekapcsolt Secure Boot mellett, ha a Debiant választom ki az UEFI-ben első boot opcióként, akkor a GRUB-ban kiválasztva betölt a Debian, viszont a Linux Mint nem és valami ilyesmi üzenetet küld a GRUB:

error: bad shim signature. error: you need to load the kernel first.

Ha a Linux Mintet állítom a boot első helyére UEFI-ben, akkor az tölt be, viszont akkor meg a Debian írja ki a "bad shim signature" üzenetet a GRUB-ban...

Kikapcsolt Secure Boot mellett nincs ilyen probléma egyikkel sem. A Windows minden esetben betölt.

Mi lehet a probléma, hogyan tudnám orvosolni? Leggyakrabban azt a választ kapom, hogy kapcsoljam ki a Secure Bootot... oké, de, ha már van, akkor igazából miért ne használjuk?

Bad shim signature, Secure Boot probléma

Értékelés: 

0
Még nincs értékelve

A kulcsmondat szerintem ez: "A Windows 10 rendszerbetöltője a Debian SSD-jén van."
Nekem is van 3 SSD-n 3 kulonbozo Linux distribuciom de mindegyiknek a sajat EFI-jen
van a rendszerbetoltoje. Nincs is veluk gond. (Igaz, a Secure Boot disable)

"Secure Bootot... oké, de, ha már van, akkor igazából miért ne használjuk?"
Tudomasom szerint, a Secure Bootot mar regen feltortek.
A kepzett hackerek szamara a Secure Boot atjarohaz.

kami911 képe

Hali, szerintem az a gond,

Értékelés: 

0
Még nincs értékelve

Hali, szerintem az a gond, hogy a két gyártó kernel aláírása (root CA) nem azonos, és a saját telepítője, vagy ezt vagy az helyezi el a gép UEFI-jében.

Ezzel tudod lekérdezni:

sbverify --list /boot/vmlinuz

Az utóbbi a bootolandó kernel image pontos neve.

A UEFI/BIOS-ban hozzá tudod adni a megfelelőt, továbbiakat.

Bad shim signature, Secure Boot probléma

Értékelés: 

0
Még nincs értékelve

#1 Köszönöm! Tehát magyarán azon kívül, hogy engem szívat, értelme nincs, hogy be van kapcsolva.

kami911 képe

Bad shim signature, Secure Boot probléma

Értékelés: 

0
Még nincs értékelve

#3 szerintem van értelme,  meg mindig érdekes és tanulságos az ilyeneket megjavítani.

És mi az értelme?

Értékelés: 

0
Még nincs értékelve

És mi az értelme?

Mert hogy jó játék javítgatni azt, ami kikapcsolva semmi gondot nem okoz, igen, annak van sportértéke.

De miért kell bekapcsolni?

Éjjel jön valami betörő, odamegy a kikapcsolt gépedhez, betesz egy random pendrive-ot, te meg jól megakadályozod a bootolását?

kami911 képe

És mi az értelme?

Értékelés: 

0
Még nincs értékelve

#5 Az UEFI firmware sebezhetőségek, amik legalább 25 számítógépgyártót érintenek: https://linuxmint.hu/hir/2022/02/az-uefi-firmware-sebezhetosegek-amik-legalabb-25-szamitogepgyartot-erintenek

Intel CPU mikrokód frissítés: két biztonsági javítás és funkcionális hibajavítások: https://linuxmint.hu/hir/2024/09/intel-cpu-mikrokod-frissites-ket-biztonsagi-javitas-es-funkcionalis-hibajavitasok

 

És mi az értelme?

Értékelés: 

0
Még nincs értékelve

#6

"Konkrétabban, egy rendszergazdai jogosultságokkal rendelkező helyi vagy távoli támadó az SMM hibáit kihasználva a következő feladatokat hajthatja végre:

Számos hardveres biztonsági funkció érvénytelenítése (SecureBoot, Intel BootGuard)."

 

Tehát a válasz  a miért kapcsoljam be a secure bootot kérdésre az, hogy UEFI hiba miatt a támadó ki tudja kapcsolni.

Hát én segítek neki, nem kell kikapcsolja :)

kami911 képe

És mi az értelme?

Értékelés: 

0
Még nincs értékelve

#7 ezzel még könnyebbé teszed a bejutását. Értem én, hogy megszakérted, hogy miért ne, de lehet, hogy egyszer ez segít majd, hogy eljerülj egy támadást. Pont ezért kell frissen és aktívan tartani amennyit lehet, a biztonsági megoldásokból, mert manapság sérülékenységek láncolatát is alkalmazzák.

És mi az értelme?

Értékelés: 

0
Még nincs értékelve

#8
Ha egy minden szempontbol jol mukodo rendszeren nem okoz problemat a Secure Boot
engedelyezese, akkor szerintem is jobb ha engedelyezzuk.

devil képe

.ez az egész egy protokollal

Értékelés: 

0
Még nincs értékelve

.ez az egész egy protokollal megoldhato.szerkeszteni,aláirni,importálni.és nincs secure boot gond.ha eroszakkal bekapcsolva akarjatok hagyni.
devil

.ez az egész egy protokollal

Értékelés: 

0
Még nincs értékelve

#10
Ha engedelyezett Secure Boot mellett telepitesz olyan wifi drivert (hogy legyen wifi kapcsolatod)
amelyiknek nincs megfelelo digitalis alairasa, akkor azt a telepitett divert nem hagyja betoltodni.
Tehat, csak kikapcsolt Secure Boot mellet lesz wifi kapcsolatod.

.ez az egész egy protokollal

Értékelés: 

0
Még nincs értékelve

#11 Ja. Van egy HP notim (olyan pont mint a Kamié :-), azon a Linux Mint 22, ha be van kapcsolva a Secure Boot, akkor a képernyő csak 1024*768-as felbontással működik, ha meg ki van kapcsolva, akkor megy megy FHD-ban mint a kisangyal. Még nem mélyedtem bele hogy mi okozza. Most raktam össze egy gépet,  Gigabyte B550 lappal, azon bekapcsolt (pontosabban AUTO módban) Secure Boot nem okoz semmi gondot, működik minden.

Szóval vannak érdekes dolgok...

Rendben. Szóval újrahúztam

Értékelés: 

0
Még nincs értékelve

Rendben. Szóval újrahúztam mindhárom meghajtót, észszerűen. Minden rendszernél telepítés közben csak az adott rendszer alá szánt SSD volt a gépben, így mind kapott saját EFI partíciót, most már nem vesznek össze. A Debian okozott egy kisebb galibát, azt mégegyszer újra kellett telepítsem, mert kiderült, hogy valamiért Legacy módban települt. El nem tudom képzelni miért, nem voltak neki ott EFI mappái, ahol kellett volna. Na mindegy, újratelepítés után az is működik rendben, az UEFI bootválasztójából navigálok, hogy éppen melyik SSD-re akarok bebootolni és a Secure Boot is aktív mindenhol, mokutillal is ránéztem.