Hlavní navigace

Názor ke zprávičce Intel Seamless Update: aktualizace UEFI bez restartu od MSBOSS - Tak ono se může leccos při tom podělat....

  • Aktualita je stará, nové názory již nelze přidávat.
  • 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.