Hlavní navigace

Názor ke zprávičce Microsoft ukončí podporu Windows 10 v roce 2025: příprava na Windows 11, nebo Windows 365 od Lael Ophir - Neexistuje žádný zázračný bezpečný systém. Jenom samotný kernel...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 17. 6. 2021 4:43

    Lael Ophir

    Neexistuje žádný zázračný bezpečný systém. Jenom samotný kernel Linuxu měl v roce 2020 celých 126 bezpečnostních zranitelností. Technicky je to způsobené tím, že se SW píše v C/C++, což je jazyk vysloveně náchylný na chyby. Pro uživatele to znamená nutnost udržovat systém aktuální. Windows 7 nejsou podporované, takže je nemůžete mít aktuální, a tedy jsou děravé jako řešeto. Mimochodem svého času jste mohl upgradovat na Windows 10 zdarma.

    Windows samozřejmě můžou bez problému vydržet v jedné instalaci. Měl jsem stroj, který začal na Windows 2000, přešel na XP, na těch na jiný HW, pak na Vistu a Win7. Při dalším upgradu HW jsem ho reinstaloval na 64-bit verzi Windows, jinak by mohl jet klidně dodnes. A pochopitelně se dá přejít na NVMe bez reinstalace, pokud víte, jak to funguje ve Windows s boot drivery.

    Pokud jde o class drivery, tak opakuji, že přináší řadu problémů. Odkazoval jsem vás na xHCI errata, a psal jsem, že implementace se liší od specifikace. Sice se prsíte, jak si čtete a upravujete zdrojáku, ale působí to, že jste je moc neviděl. Koukněte se do xhci.c:
    "Existing Intel xHCI controllers require a delay of 1 mS, after setting the CMD_RESET bit, and before accessing any HC registers. This allows the HC to complete the reset operation and be ready for HC register access. Without this delay, the subsequent HC register access, may result in a system hang very rarely"
    "Some Renesas controllers get into a weird state if they are reset while programmed with 64bit addresses (they will preserve he top half of the address in internal, non visible registers). You end up with half the address coming from the kernel, and the other half coming from the firmware. Also, changing the programming leads to extra accesses even if the controller is supposed to be halted. The controller ends up with a fatal fault, and is then ripe for being properly reset. Special care is taken to only apply this if the device is behind an iommu. Doing anything when there is no iommu is definitely unsafe..."
    "Some Fresco Logic host controllers advertise MSI, but fail to generate interrupts. Don't even try to enable MSI"
    "Quirk to work around issue generated by the SN65LVPE502CP USB3.0 re-driver that causes ports behind that hardware to enter compliance mode sometimes. The quirk creates a timer that polls every 2 seconds the link state of each host controller's port and recovers it by issuing a Warm reset if Compliance mode is detected, otherwise the port will become "dead" (no device connections or disconnections will be detected anymore). Becasue no status event is generated when entering compliance mode (per xhci spec), this quirk is needed on systems that have the failing hardware installed."
    "If system is subject to the Quirk, Compliance Mode Timer needs to be re-initialized Always after a system resume. Ports are subject to suffer the Compliance Mode issue again. It doesn't matter if ports have entered previously to U0 before system's suspension."
    a další, další a další...
    https://github.com/torvalds/linux/blob/master/drivers/usb/host/xhci.c

    Už vám to dochází? Ten "standardní class driver používající HW API" je slepenec standardní funkcionality, a k tomu obrovské hromady workaroundů pro specifický HW. Když ho použijete na HW, na kterém nebyl testovaný, tak to může dopadnout všelijak. Ztuhne to? Ztuhne to při pokusu o spánek nebo probuzení? Bude to nedej bože mršit data?

    Nakonec podobné problémy s netestovaným HW se vyskytují v reálném světě. Tady vidíte příklad notebooků Samsung, které se bricknuly bootem do Linuxu. Proč? Protože někdo před lety dostal od někoho ze Samsungu neoficiálně seznam paměťových adres, na které se dá zapsat pro aktivaci nějakých funkcí BIOSu. Z toho vznikl modul samsung-laptop, který do té paměti zapisoval, a používal se pro všechny modely notebooků Samsung, i když s nimi vůbec nebyl testovaný. U modelů, které nově bootovaly přes UEFI, ten zápis nedopadl, protože na daných adresách jaksi žádná paměť nebyla (testování na UEFI boot nedopadlo, protože se změnila sémantika funkce efi_enabled()). To vedlo k řetězci událostí (zahrnujícím UEFI firmware bug), který zařízení bricknul.
    https://www.root.cz/zpravicky/nektere-nove-notebooky-od-samsungu-nepreziji-instalaci-linuxu/

    Řešení je zcela zjevné: nespoléhat na device class, psát driver podle dokumentace HW, *TESTOVAT*(!) ho na skutečném HW, a výhradně na tom HW ho také používat. Jenže na Linuxu to není reálné, protože je podpora HW mizerná i s tímto přístupem "zkusíme to, a třeba to bude fungovat". Přísnější kritéria by znamenala, že by podpora HW šla do kytek úplně.