OVĚŘENÍ SELHALA: Hardware neprochází kontrolami. MÁM PANIKAŘIT?
NÁVODY > KATEGORIE > Bios/Uefi + Hardware a Firmware
18.06.2026
V Linuxu se v Nastavení může objevit červené hlášení „Ověření selhala“, „Hardware neprochází kontrolami“ nebo „Bezpečné zavádění má problémy“. Na první pohled to může působit velmi vážně. Mnoho uživatelů si může myslet, že počítač byl napaden, firmware je poškozený nebo je linuxové jádro infikované malwarem.
Ve skutečnosti to tak být nemusí.
Tento článek vysvětluje, co znamenají hlášení v části Zabezpečení zařízení, jak je doplnit příkazem fwupdmgr security, co znamenají úrovně HSI:0 až HSI:5, jak chápat hlášení „Jádro je pozměněno“ a proč není dobrý nápad naslepo měnit Secure Boot klíče v BIOSu/UEFI.
Článek vychází z praktického testu na počítači AceMagic se Zorin OS 18.1, kde byl Secure Boot zapnutý, UEFI databáze certifikátů se dala aktualizovat, ale systém přesto zůstal na nízké úrovni HSI kvůli hlubším firmware/UEFI kontrolám.
Zabezpečení zařízení v Linuxu může zobrazit varování „Ověření selhala“ nebo „Bezpečné zavádění má problémy“. Takový stav nemusí automaticky znamenat napadený systém, ale je potřeba zjistit, která konkrétní kontrola selhala.
Rychlá navigace:
- Netechnicky řečeno
- Co kontroluje Zabezpečení zařízení v Linuxu
- Co znamená HSI
- Co znamená vykřičník za HSI
- Tři důležité položky pro Secure Boot v Linuxu
- Praktický příklad: Secure Boot je zapnutý, ale HSI zůstává nízké
- Co znamená „Jádro je pozměněno“
- Jak ověřit stav jádra
- Kdy u „Jádro je pozměněno“ zpozornět
- Aktualizace certifikátů UEFI db, KEK a dbx
- Jak provést základní kontrolu
- Co má běžný uživatel řešit jako první
- Co lze často opravit vlastními silami
- Co uživatel často neopraví sám
- Pozor na Restore Factory Keys a Reset To Setup Mode
- Praktická ukázka: přepnutí Custom / Standard nemusí pomoci
- Pokus o opravu přes MOK Manager nemusí vždy projít
- A co LUKS šifrování?
- Jak postupovat bezpečně
- Kdy panikařit a kdy ne
- Shrnutí pro běžného uživatele
1. Netechnicky řečeno
Pokud Linux hlásí „Ověření selhala“, neznamená to automaticky, že je počítač napadený.
Často to znamená jen toto:
Linux zkontroloval firmware, Secure Boot, stav jádra a některé hardwarové ochrany. Něco z toho není v ideálním stavu, něco výrobce počítače nenastavil dokonale, něco nejde opravit z Linuxu a něco může být jen důsledek používání běžných nástrojů, například VirtualBoxu nebo VMware.
Důležité je nepanikařit, ale zjistit, která konkrétní kontrola selhala.
2. Co kontroluje Zabezpečení zařízení v Linuxu
V prostředí GNOME a v distribucích, které tuto část Nastavení používají, se může zobrazit sekce Zabezpečení zařízení. Ta vyhodnocuje stav počítače podle informací z firmware, Secure Bootu, fwupd a dalších systémových kontrol. Je důležité pochopit, že nejde o antivir.
Tato část neříká přímo: V systému je malware.
Spíše říká: Některé bezpečnostní vlastnosti firmware, UEFI, Secure Bootu nebo běžícího jádra nejsou v ideálním stavu.
Pro podrobnější výpis lze použít příkaz:
bash
fwupdmgr security
Tento příkaz vypíše takzvaný Host Security ID, zkráceně HSI.
3. Co znamená HSI
HSI je zjednodušené hodnocení bezpečnostního stavu počítače z pohledu firmware a hardwarových ochran. fwupd dokumentace uvádí, že HSI měří pouze takové bezpečnostní ochrany, které může koncový uživatel ověřit bez připojení dalšího hardwaru, instalace dalšího softwaru nebo vypnutí existujících bezpečnostních vrstev. HSI je primárně určeno pro notebooky a stolní počítače.
Zjednodušeně:
Oficiální dokumentace fwupd uvádí, že bezpečný základ by měl být alespoň HSI:1. Pokud počítač nedosahuje ani této úrovně, doporučuje upravit nastavení firmware, kontaktovat výrobce nebo zvolit jiný hardware. Zároveň uvádí, že počítače s důvěrnými dokumenty by měly mířit na HSI:3 nebo vyšší.
4. Co znamená vykřičník za HSI
Někdy se zobrazí například:
HSI:0!
Vykřičník znamená, že byl zjištěn runtime problém, tedy problém v běžícím systému. Podle fwupd může jít například o vypnutý Secure Boot, tainted kernel, neuzamčené jádro, nešifrovaný swap nebo upravené pluginy fwupd.
To je důležité: číslo HSI:0 a vykřičník ! nejsou totéž.
- HSI:0 říká, že počítač nesplnil některé základní firmware/hardwarové kontroly.
- ! říká, že je navíc problém v běžícím systému.
5. Tři důležité položky pro Secure Boot v Linuxu
Pro běžného uživatele Linuxu jsou při prvním ověření velmi důležité hlavně tyto tři položky:
- UEFI secure boot
- UEFI db
- Uzamčení linuxového jádra
Ideální stav je:
- UEFI secure boot: Povoleno
- UEFI db: Platné
- Uzamčení linuxového jádra: Povoleno
Tyto tři položky říkají:
- Secure Boot je ve firmware zapnutý.
- UEFI databáze povolených certifikátů je platná.
- Linuxové jádro je spuštěné v uzamčeném režimu.
fwupd popisuje UEFI Secure Boot jako mechanismus, který ověřuje, že kód spouštěný firmwarem je důvěryhodný. Secure Boot vyžaduje, aby každá binárka načítaná při startu byla ověřena proti důvěryhodným certifikátům.
Samostatná kontrola UEFI db ověřuje databázi certifikátů, které určují, jaké EFI binárky mohou být spuštěny. Stav valid znamená, že je tato databáze z pohledu fwupd v pořádku.
6. Praktický příklad: Secure Boot je zapnutý, ale HSI zůstává nízké
Na testovaném počítači AceMagic byl Secure Boot zapnutý:
- SecureBoot enabled
Současně fwupdmgr security ukazoval:
- Identifikátor zabezpečení hostitele: HSI:0!
Přitom základní položky pro Secure Boot byly v pořádku:
- UEFI secure boot: Povoleno
- Uzamčení linuxového jádra: Povoleno
- UEFI db: Platné
To znamená, že základní Secure Boot řetězec v Linuxu může být v pořádku, ale počítač může přesto zůstat na nízké úrovni HSI kvůli jiným firmware/hardwarovým kontrolám. V konkrétním výpisu selhávaly například položky související s CSME manufacturing mode, SPI ochranami, BIOS regionem a UEFI Platform Key.
To je pro běžného uživatele důležité:
Zapnutý Secure Boot neznamená automaticky vysokou úroveň HSI.
7. Co znamená „Jádro je pozměněno“
V Zabezpečení zařízení nebo ve výstupu fwupdmgr security se může objevit hlášení:
- Linuxové jádro: „Poskvrněno“
nebo v událostech:
- Jádro je pozměněno
Toto hlášení zní velmi nebezpečně. V Linuxu ale obvykle odpovídá stavu označovanému jako tainted kernel.
Oficiální dokumentace linuxového jádra vysvětluje, že kernel se označí jako „tainted“ tehdy, když nastane událost, která může být později důležitá při vyšetřování problémů. Dokumentace zároveň říká, že většinou není potřeba se tím přehnaně znepokojovat; informace je důležitá hlavně pro ladění a hlášení chyb. Stav lze ověřit souborem /proc/sys/kernel/tainted. Pokud je hodnota 0, jádro není tainted; jiná hodnota označuje důvod.
fwupd kontroluje tainted stav jádra, protože při výpočtu HSI potřebuje získávat informace od běžícího linuxového jádra. Pokud je jádro tainted například kvůli out-of-tree modulu, fwupd nemusí plně důvěřovat hodnotám, které od jádra dostává.
8. Jak ověřit stav jádra
Použijte příkaz:
bash
cat /proc/sys/kernel/tainted
Výsledek:
- 0
znamená, že jádro není tainted.
Jiná hodnota znamená, že jádro je označené jako tainted.
V testovaném systému byla po jednom z ověření hodnota:
- 4096
Tato hodnota odpovídá bitu 12, tedy načtenému externímu modulu mimo běžné distribuční jádro.
Dříve byla zachycena i hodnota:
- 4608
která odpovídala kombinaci:
- bit 9 = kernel warning
- bit 12 = externí / out-of-tree modul
V praxi to může způsobit například VirtualBox, VMware, některé grafické ovladače, některé Wi-Fi ovladače, ZFS nebo jiné moduly mimo standardní jádro.
Pro rychlé ověření typických modulů lze použít:
bash
lsmod | grep -E 'vbox|vmmon|vmnet|nvidia|wl|zfs'
Pokud používáte VirtualBox nebo VMware, mohou se objevit například moduly:
- vboxdrv
- vboxnetflt
- vboxnetadp
- vmmon
- vmnet
To samo o sobě neznamená, že byl počítač napaden. Znamená to, že v jádře běží modul mimo standardní jádro distribuce.
9. Kdy u „Jádro je pozměněno“ zpozornět
Pokud používáte VirtualBox, VMware nebo jiný známý nástroj, který zavádí vlastní kernel moduly, je vysvětlení obvykle jednoduché.
Zpozornět má smysl tehdy, když:
- žádnou virtualizaci nepoužíváte,
- nevíte o žádném externím ovladači,
- ve výpisu lsmod vidíte neznámé moduly,
- zároveň se objevují další podezřelé projevy systému,
- systém se chová nestandardně po neznámé aktualizaci nebo zásahu.
Ani tehdy není správné hned tvrdit „mám malware“. Správný postup je zjistit, který modul nebo událost tainted stav způsobila.
10. Aktualizace certifikátů UEFI db, KEK a dbx
V roce 2026 začínají být důležité nové Secure Boot certifikáty z roku 2023. Microsoft uvádí, že starší Secure Boot certifikáty z roku 2011 se blíží k expiraci a mají být nahrazovány novými certifikáty z roku 2023. Dokumentace Microsoftu uvádí například Microsoft Corporation KEK CA 2011, Microsoft UEFI CA 2011, Microsoft Windows Production PCA 2011 a jejich nové náhrady z roku 2023. Ablauf des Windows Secure Boot-Zertifikats und Updates der Zertifizierungsstelle.
Ubuntu zároveň uvádí, že 2023 CA je distribuována pomocí fwupd přes aktualizace bezpečnostních databází publikované Microsoftem a výrobci zařízení na LVFS.
Pro instalaci aktualizací se používá například:
bash
sudo fwupdmgr refresh
# sudo fwupdmgr refresh --force
sudo fwupdmgr update
V testovaném případě fwupdmgr get-updates ukázal, že v historii proběhly aktualizace:
- KEK CA (2011 → 2023)
- UEFI CA (2011 → 2023)
- UEFI dbx (20230501 → 20250902)
Samostatné ověření přes mokutil --db zároveň ukázalo, že v databázi db jsou přítomné nové položky:
- Microsoft UEFI CA 2023
- Microsoft Option ROM UEFI CA 2023
Zajímavé je, že výpis mokutil --kek v tomto konkrétním testu stále zobrazoval pouze Microsoft KEK CA 2011. Proto je vhodné výsledky číst opatrně a nespoléhat na jediný příkaz.
11. Jak provést základní kontrolu
Nejprve ověřte Secure Boot:
bash
mokutil --sb-state
Ideální výsledek:
- SecureBoot enabled
Potom spusťte:
bash
fwupdmgr security
Hledejte hlavně:
- Host Security ID: HSI:x
- UEFI secure boot
- UEFI db
- Linux kernel lockdown
- Linux kernel
V českém výstupu přibližně:
- Identifikátor zabezpečení hostitele: HSI:x
- UEFI secure boot
- UEFI db
- Uzamčení linuxového jádra
- Linuxové jádro
12. Co má běžný uživatel řešit jako první
Pro běžný domácí počítač má smysl zkontrolovat především:
- Secure Boot zapnutý
- UEFI db platná
- Uzamčení linuxového jádra povolené
- Systém aktualizovaný
- Firmware aktualizovaný, pokud je dostupný
- Firewall zapnutý
- AppArmor aktivní
- Šifrování disku u notebooku
- Zálohy
Příkazy:
bash
mokutil --sb-state
fwupdmgr security
fwupdmgr get-updates
Případně aktualizace:
bash
sudo fwupdmgr refresh
# sudo fwupdmgr refresh --force
sudo fwupdmgr update
13. Co lze často opravit vlastními silami
Některé problémy má uživatel šanci vyřešit sám:
Typicky jde například o zapnutí Secure Bootu v BIOSu/UEFI, instalaci dostupných aktualizací firmware přes Software nebo fwupdmgr, opětovnou aktualizaci UEFI db certifikátů, ověření kernel lockdownu nebo zjištění, zda stav „Jádro je pozměněno“ nezpůsobují známé moduly VirtualBoxu, VMware, grafického ovladače nebo jiného běžného nástroje.
14. Co uživatel často neopraví sám
Některé kontroly závisí na výrobci počítače, BIOSu/UEFI nebo hardwaru.
V testovaném výpisu selhávaly například:
- režim csme pro výrobce: Odemčeno
- uzamčení SPI: Zakázáno
- Popisovač v SPI pro BIOS: Neplatné
- Oblast v SPI pro BIOS: Odemčeno
- Klíč platformy v UEFI: Neplatné
Tyto položky jsou pro HSI důležité, ale běžný uživatel často nemá v BIOSu/UEFI žádnou jednoduchou volbu, kterou by je opravil. fwupd dokumentace u některých podobných firmware kontrol uvádí jako řešení kontaktovat OEM výrobce nebo čekat na firmware update.
Praktický závěr:
Pokud selhávají hlubší firmware ochrany, nemusí to být chyba Linuxu. Často jde o vlastnost nebo nedostatek konkrétního BIOSu/UEFI.
15. Pozor na Restore Factory Keys a Reset To Setup Mode
Při testování na počítači AceMagic byly vyzkoušeny volby v BIOSu/UEFI:
Restore Factory Keys
Reset To Setup Mode
Reset To Setup Mode
Výsledek byl varovný.
Po uložení změn se systém nespustil běžným způsobem a firmware zobrazil červené hlášení:
Secure Boot Violation, Invalid signature detected. Check Secure Boot Policy in Setup
Teplý restart z klávesnice nepomohl. Až úplné vypnutí a opětovné zapnutí počítače umožnilo systém znovu spustit. Poté bylo nutné znovu nainstalovat certifikáty přes aplikaci Software/fwupd a UEFI db se znovu vrátila do platného stavu.
Tento test je důležitý, protože ukazuje:
Obnova továrních Secure Boot klíčů není bezpečný univerzální opravný postup pro začátečníky.
Tyto volby mohou změnit obsah Secure Boot databází:
- PK
- KEK
- db
- dbx
a mohou způsobit, že firmware dočasně odmítne spustit Linux, protože aktuální zavaděč nepovažuje za důvěryhodný.
Proto není vhodné začátečníkům doporučovat:
- Restore Factory Keys
- Reset To Setup Mode
- Clear Secure Boot Keys
- Delete Secure Boot Keys
- ruční práci s PK/KEK/db/dbx
- Enroll EFI Image bez znalosti důsledků
16. Praktická ukázka: přepnutí Custom / Standard nemusí pomoci
Na testovaném počítači byla v BIOSu/UEFI položka:
- Secure Boot Mode: Custom / Standard
Přepnutí z Custom na Standard způsobilo, že Zabezpečení zařízení ukázalo neplatnou UEFI db. Po návratu na Custom aplikace Software nabídla instalaci certifikátů. Po instalaci byla UEFI db znovu platná.
Z toho plyne:
Standard není automaticky lepší než Custom. U některých počítačů může režim Standard obnovit starší tovární stav klíčů, který fwupd/GNOME vyhodnotí jako neaktuální nebo neplatný.
17. Pokus o opravu přes MOK Manager nemusí vždy projít
Byl také vyzkoušen příkaz:
bash
sudo mokutil --enable-validation
Tento postup se používá k opětovnému zapnutí validace přes shim/MOK. Debian popisuje postup tak, že se spustí mokutil --enable-validation, zvolí se heslo, po restartu se v MOK Manageru vybere Change Secure Boot state, zadávají se požadované znaky hesla a změna se potvrdí.
V testovaném případě byl postup proveden, ale MOK Manager skončil hlášením:
- Failed to delete Secure Boot state
To ukazuje, že ani správný postup nemusí na každém firmware fungovat.
Pro článek je to důležité sdělení:
Když oprava přes MOK Manager selže, neznamená to automaticky, že uživatel zadal špatné heslo.
Někdy může být problém hlouběji ve firmware/UEFI proměnných nebo v konkrétní implementaci BIOSu.
18. A co LUKS šifrování?
Secure Boot klíče a LUKS šifrování jsou různé vrstvy.
Secure Boot řeší:
- firmware → EFI zavaděč → shim → GRUB → kernel
LUKS řeší:
- šifrovaný obsah disku
Obnova Secure Boot klíčů by sama o sobě neměla poškodit LUKS kontejner. Může ale způsobit, že systém dočasně nenabootuje, protože firmware odmítne spustit zavaděč.
Pokud uživatel zná LUKS heslo, data obvykle zůstávají dostupná například z Live USB. Riziko tedy není typicky „ztráta dat“, ale „dočasně nenabootuje systém“.
Výjimkou by mohla být situace, kdy je LUKS automaticky navázán na TPM a PCR hodnoty. V takovém případě změna Secure Boot stavu, klíčů nebo boot řetězce může změnit měření v TPM a automatické odemčení může přestat fungovat.
19. Jak postupovat bezpečně
Před jakoukoliv změnou v BIOSu/UEFI:
- Uložte si aktuální stav.
- Vyfoťte původní nastavení BIOSu/UEFI.
- Neměňte více voleb najednou.
- Připravte si Live USB se Zorin OS nebo Ubuntu.
- Ověřte, že znáte LUKS heslo, pokud používáte šifrování disku.
- Nepoužívejte volby pro mazání nebo reset Secure Boot klíčů, pokud přesně nevíte, co dělají.
Užitečné příkazy před změnou:
bash
mokutil --sb-state > mokutil-sb-state-pred.txt
fwupdmgr security > fwupdmgr-security-pred.txt
sudo mokutil --db > mokutil-db-pred.txt
sudo mokutil --kek > mokutil-kek-pred.txt
cat /proc/sys/kernel/tainted > kernel-tainted-pred.txt
Po změně:
bash
mokutil --sb-state > mokutil-sb-state-po.txt
fwupdmgr security > fwupdmgr-security-po.txt
sudo mokutil --db > mokutil-db-po.txt
sudo mokutil --kek > mokutil-kek-po.txt
cat /proc/sys/kernel/tainted > kernel-tainted-po.txt
20. Kdy panikařit a kdy ne
Není důvod k panice, pokud:
- Secure Boot je zapnutý
- UEFI db je platná
- kernel lockdown je povolený
- „Jádro je pozměněno“ odpovídá známému modulu VirtualBoxu/VMware
- systém se chová normálně
Je vhodné problém řešit, pokud:
- Secure Boot je vypnutý, ačkoliv má být zapnutý
- UEFI db je neplatná
- kernel lockdown je vypnutý
- HSI náhle kleslo po změně BIOSu nebo aktualizaci
- počítač hlásí Secure Boot Violation
- nevíte, proč je jádro tainted
Není vhodné naslepo dělat:
- Restore Factory Keys
- Reset To Setup Mode
- Clear/Delete Secure Boot Keys
- Enroll EFI Image bez znalosti důsledků
- ruční mazání EFI proměnných
21. Shrnutí pro běžného uživatele
Pokud v Linuxu uvidíte hlášení „Ověření selhala“, neznamená to automaticky napadený počítač.
Nejprve zkontrolujte:
- mokutil --sb-state
- fwupdmgr security
- cat /proc/sys/kernel/tainted
Pro základní Secure Boot stav je důležité, aby bylo v pořádku:
- UEFI secure boot: Povoleno
- UEFI db: Platné
- Uzamčení linuxového jádra: Povoleno
Pokud je systém na HSI:0, má smysl zjistit proč. Ne všechno ale půjde opravit. Některé položky závisí na výrobci počítače, BIOSu/UEFI a hardwaru.
Nejdůležitější praktický závěr:
fwupdmgr security je velmi užitečný diagnostický nástroj, ale není to jednoduchý verdikt „počítač je bezpečný / počítač je napadený“.
Červené hlášení znamená: zjistěte, která kontrola selhala, a podle toho rozhodněte, zda jde o běžně vysvětlitelný stav, opravitelnou konfiguraci nebo omezení konkrétního hardwaru.
Ne vždy se tak může dostat váš počítač do stavu viz obrázek (Ověření prošla, hardware splňuje základní bezpečnostní požadavky, bezpečné zavádění je aktivní).
22. Související články
Pokud se chcete v tématu Secure Bootu, MOK Manageru, UEFI a bezpečného zavádění Linuxu zorientovat podrobněji, mohou se Vám hodit také tyto související návody:
- Secure Boot v Linuxu: jak ověřit nové certifikáty Microsoft 2023 před rokem 2026 - Vysvětlení, proč se řeší nové certifikáty Microsoft 2023 a jak ověřit, zda je systém už obsahuje.
- Secure Boot v Linuxu: aktualizace KEK a DB doplnila nové certifikáty Microsoft 2023 - Praktický navazující článek o aktualizaci databází KEK a DB ve firmwaru UEFI.
- MOK Manager: Continue boot, špatné heslo a oprava při instalaci Zorin OS - Návod pro situace, kdy se při instalaci Zorin OS zobrazí MOK Manager, uživatel zvolí Continue boot, zadá špatné heslo nebo potřebuje celý postup opravit.
- Co je to BIOS/UEFI, rozdíly a proč o tom píšu? - Základní vysvětlení BIOSu, UEFI, Secure Bootu a zavádění systému. V části „Secure Boot lidsky“ je stručně popsáno také to, kde do celého procesu zapadá shim.
- Při zapnutí notebooku se zobrazí „Booting in insecure mode“. Co s tím? - ověřování v podepsaném EFI programu shim může být vypnuté.
23. Doporučené zdroje
- fwupd: Host Security ID Specification — oficiální dokumentace HSI, úrovní HSI a runtime suffixu.
- fwupd: UEFI Secure Boot Certificates — vysvětlení kontroly UEFI db.
- Linux kernel documentation: Tainted kernels — oficiální vysvětlení stavu tainted kernel.
- fwupd plugin: Linux Kernel Tainted — kontrola tainted jádra ve fwupd/HSI.
- Ubuntu Community Hub: Microsoft UEFI CA rotation — informace o zavádění certifikátů 2023 přes fwupd/LVFS.
- Microsoft Support: Windows Secure Boot certificate expiration and CA updates — přehled certifikátů 2011 a nových certifikátů 2023.
PODPOŘTE OTEVŘENÉ NÁVODY A DALŠÍ ROZVOJ WEBU LINUX PRO DOMÁCNOST:
Věřím v otevřené znalosti a v to, že kvalitní návody mají být dostupné bez reklam, rušivých prvků a zbytečného trackingu. Každý článek na webu Linux pro domácnost vzniká na základě rešerše, praktického testování na reálném nebo virtuálním počítači, ověřování v různých linuxových distribucích a pečlivého zpracování krok za krokem. Často jde o práci na několik hodin, někdy i několik dnů.
Pokud Vám některý návod pomohl, ušetřil čas nebo usnadnil řešení problému, budu rád za dobrovolnou finanční podporu. A pokud se Vám myšlenka tohoto webu líbí a chcete jeho tvorbu podporovat pravidelně, podívejte se prosím na stránku: