Hlavní navigace

Intel Seamless Update: aktualizace UEFI bez restartu

15. 9. 2021

Sdílet

Intel Xeon Ice Lake Autor: Intel

Společnost Intel připravuje do Linuxu zajímavou inovaci pro své platformy. První patche už do jádra zamířily a až se vše podaří dotáhnout do konce, bude možné na strojích Intel aktualizovat firmwary (zejména UEFI) bez nutnosti restartu stroje. Vše proběhne v rámci aktuálního běhu operačního systému.

Novinka necílí na běžné uživatele a jejich desktopy, primárně je připravována pro serverové platformy a pro zákazníky, kteří mají smluvní placenou podporu týkající se downtime jejich strojů. Mnohé velké stroje mají dobu rebootu měřenou v lepším případě v jednotkách minut a tak pokud bude existovat cesta, kterak aktualizovat firmware bez nutnosti restartu, půjde o výhodu dané platformy. Jistě netřeba ve světe po Spectre/Meltdown dodávat, jak důležité jsou v enterprise světě právě aktualizace firmwarů.

Seamless Update bude služba s podporou v linuxovém jádru, která je součástí firemní Platform Firmware Runtime Update a kódu ovladačů Telemetry. Nový kód v jádru zavádí nová ACPI ovladač PRFU pro práci s Platform Firmware Runtime Update ze strany operačního systému. Podpora telemetrie je tu pro logování procesů kolem aktualizace firmwaru. Vedle samotného otevřeného kódu v Linuxu také Intel v srpnu vydal whitepaper popisující aktualizaci firmwarů bez restartu z hlediska Intel Management Mode Firmware Runtime Update, kde je právě jaderná část Intel Seamless Update popsána.

S ohledem na to, že Intel typicky připravuje půdu pro nové železo v Linuxu dopředu, lze předpokládat, že tato nová iniciativa souvisí s reálnou dostupnosti Xeonů 10nm generace Sapphire Rapids, které ve většině situací nejsou lepší/výhodnější než EPYCy, ale toto by mohlo zákazníky zaujmout.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 16. 9. 2021 18:54

    Lol Phirae

    Jo, asi tomu taky moc nerozumím. Když jsem cosi řešil s vývojářema corebootu pro PC Engines, tak trapně trvali na tom, že aby aktualizace BIOSu byla efektivní, je nutný power cycle.

    16. 9. 2021, 18:58 editováno autorem komentáře

  • 17. 9. 2021 13:27

    Trident

    No jo. PCckari. Reboot jako jednotka výkonu servisaka.

    To je pouze mentalni nastavení vývojářů. Svět PC hw se na rebootless updaty firmwaru připravuje velmi zvolna.

    U BIOSu dneska může být blby že to může nahrávat dalsi firmware nebo mikrokod cipsetu i jinam jen po startu.

  • 18. 9. 2021 1:32

    MSBOSS

    Tak ono se může leccos při tom podělat. Všechny komponenty musí být napsané tak, že počítají s tím, že ten update může proběhnout.
    Pár příkladů, co se může stát (říkám to jen jako člověk, co trochu psal pro x86, UEFI neznám, jen HW, na kterém běží):

    UEFI nebude připravené na live patch. Nahrajete nové UEFI, ale ono se standardně po startu ozrcadlí do RAM (proč se taky Linux vyhýbá spodním pár megabajtům, že jo, dřív BIOS slušně zabíral jenom UMA). Takže je to opatchovaný, nepotřebujete restart, ale jedete stále na staré verzi.
    Dobře, takže opatchujete zrcadlo v paměti. Nojo, ale co když nebudou sedět délky funkcí nebo adresy entrypointů? Dejme tomu, že budou (nevím, jestli na to dneska není nějaký standard, kdysi bývalo vše dostupné hezky popsané v IVT a později přes IDT a šlo to snadno přemapovat, ale co já vím, jak je to dnes). Takže přepíšeme zrcadlo. Za předpokladu, že dokážete nějak vyflusat všechny cache a deskriptorový cache, aby tam někde nezbyl starý obsah, tak je asi víceméně vyhráno pro ring 0 a vyšší.
    Když se třeba blbě přemapuje IDT (nebo nevyfluše cache / deskriptorová cache a skočí se někam hodně blbě), tak se hezkypěkně může stát, že vám bude třeba chybět nějaký záznam. Při pokusu o jeho vykonání to spadne do faultu, když bude chybět fault interrupt, tak do double faultu a když bude chybět i on, tak do triple faultu, což jinak znamená, že se ten reset udělá HW sám (takhle se btw na 286 přepínalo z pmode do r-mode, protože jediná alternativa byla použít k tomu kontrolér klávesnice, ale to trvalo asi 100x déle a nešlo mít na tom postavené extendéry DOSu). Ale řekněme, že teda všechny cache i deskriptorové cache se korektně vyflušou.
    Nojo, jenže to je jenom ta "uživatelská" část. Co třeba ring -1? Tam by asi systém neměl mít přístup, ne? Proto se to taky jmenuje SMM, aby si to spravoval ten "HW systém sám", protože odtamtud se dá ovládat leccos včetně napětí na jádře, frekvence hodin atd. Systém by neměl už mít šanci si tam hrábnout. Dneska už sice asi nehrozí, že by se procesor přehřál, ale... dá se představit si, že pokažený SMM nastaví vysoké napětí na jádře a vypne větráky, procesor se přehřeje, systém bude už dávno vytuhlej, takže nezareaguje, motherboard nebude mít implementovanej PROCHOT a i po dosažení THERMTRIPU bude procesor krmenej a nakonec než někdo do serverovny dojde, tak shoří na statické ztráty. Ale dejme tomu, že se to nestane.
    Další krok je doufat, že výměna FW v Intel ME proběhne OK, jinak se může stát cokoli, protože to má absolutní kontrolu nad celým počítačem. Ale řekněme, že to má Intel pošéfovaný, koneckonců je to jejich spywarová komponenta.
    A teď si vemte, že máte v serveru RAID řadič s vlastním BIOSem. Dokážete vyměnit UEFI, aniž byste nějak porušili kontext držený mezi UEFI a tím externím BIOSem (pokud tedy nějaký je kromě vědomí o jeho existenci)? Nedrží si ten BIOS někde ve spodní části RAMky nějaký svůj vlastní kontext, kde jsou třeba nějaké odkazy na entrypointy starší verze UEFI?

    Nechci říkat, že to nemůže fungovat. Ale i jako náhodný kolemjdoucí dokážu vymyslet tisíc a jednu věc, na které se to může rozbít, a které dodnes byly tím důvodem, proč se to bez restartu nedělá. Jako Intel můžete znát vlastní HW, vlastní FW bloky, v kernelu to můžete mít pořešený, ale jakmile tam bude nějaká komponenta, která není 100% jistě napsaná tak, že to bude fungovat nebo nad kterou nemáte kontrolu (víte, co máte za loadovatelné bloky v RAID řadiči, síťové kartě at.?), tak je to velmi nejistý počin. A když zvládnete všechny deterministické věci, tak tu máte pořád komplikace s cachováním. No, jsem zědav, jak to bude fungovat. Vzhledem k tomu, že mi na oficiálním jádře v Ubuntu 21.04 nefunguje správně ani s2idle, tak jsem zvědav, jak bude fungovat tahle komplexní záležitost.

  • 17. 9. 2021 13:30

    Trident

    To je v enterprise prostředí celkem normální. I to že inicializace backplane a pak POST může zabrat i 30 minut. A to mluvím o pecku. Ne o power nebo sparceti.

Byl pro vás článek přínosný?

Autor zprávičky

Příznivec open-source rád píšící i o ne-IT tématech. Odpůrce softwarových patentů a omezování občanských svobod ve prospěch korporací.