Objeveny nové díry v procesorech Intel: zranitelnosti MDS. Rizika podobná jako u Spectre

36

Už je sice rok 2019 a ne 2018, ale bohužel to vypadá, že zdaleka není konec objevům bezpečnostních chyb v procesorech. Včera byly oznámené nově objevené slabiny, které jako zranitelnost Spectre dovolují škodlivému kódu krást nepozorovaně citlivá data nebo číst informace operačního systému a privilegovaného uživatele – ale i data z hypervizoru nebo dalších VM z virtualizovaného systému a dokonce chráněná data bezpečnostní enklávy SGX nebo režimu SMM. Oddechnout si můžou ale aspoň někteří z vás, vypadá to totiž, že tyto bezpečnostní díry zejí jenom v procesorech Intelu.

 

Zranitelnosti MDS

Tyto zranitelnosti dostaly přezdívky ZombieLoad, RIDL a Fallout, Intel je také označuje jako Microarchitectural Data Sampling (MDS) zranitelnosti. Tyto díry nezávisle objevilo několik různých výzkumných týmů, ovšem před nynějším odhalením byly skoro rok drženy v tajnosti/pod NDA (první hlášení dostal Intel loni v červnu), takže jednotliví objevitelé o sobě nevěděli a nekomunikovali spolu. Publikace nyní proto bude v několika různých verzích a pod různými jmény, které se v některých případech překrývají.

mds zranitelnosti logo
Logo zranitelností MDS

Chyby postihují procesory Intel

Tyto chyby postihují procesory Intel zřejmě už od roku 2008 až po ty nejnovější – ani bezpečnostní opravy v nejnovějších procesorech Core 9. generace proti nim bohužel nejsou účinné. Podle objevitelů se chyby nemají týkat procesorů ARM, ani x86 procesorů od AMD, mělo by tedy jít o chybu jen v architekturách Intel. Další instrukční sady (dnes je z nich asi relevantní hlavně Power) vůbec zmíněné nejsou; vzhledem ke specifičnosti pro Intel by pravděpodobně by asi obecně mohly být v suchu.

Yesterday, researchers announced three new security exploits – Fallout, Rogue In-Flight Data Load (RIDL) and “ZombieLoad Attack”. Based on our internal assessment, we believe AMD products are not impacted by these new threats. — vyjádření AMD

ZombieLoad

mds zranitelnosti utok zombieloadSlabým místem jsou u těchto útoků data nacházející se ve stádiu zpracování v procesoru, tedy v různých bufferech, frontách a podobných datových strukturách, ne ale přímo mezipamětích cache, na které se zatím útoky tohoto typu zaměřovaly dosud. ZombieLoad (CVE-2018-12130, „Microarchitectural Fill Buffer Data Sampling“) je trošku podobný útoku Meltdown – dokáže získat data z jakékoliv oblasti paměti, přičemž ho lze provést neprivilegovaným kódem, tedy buď lokálně spuštěným běžným programem, ale i třeba javascriptem na webové stránce nebo reklamním banneru.

Útok zneužívá slabinu tzv. fill bufferů při spekulativních operacích načítání (load) v procesoru. Výzkumníci zjistili, že při selhání těchto operací a jejich následnému opětovnému provedení vzniká přechodně nechráněná situace, pomocí které se lze šikovně napsaným programem dostat k datům v oblastech paměti, kam proces útočníka nemá mít přístup. Je tedy prolomena ochrana paměti ve smyslu čtení. Ne pro zápis, takže nelze například injektovat škodlivý kód, ale touto technikou se stejně jako Meltdownem nebo Spectre dají odcizit potenciálně citlivá data.

mds zranitelnosti utok fallout
Logo zranitelnosti Fallout

RIDL, Fallout

Také útoky označené jako RIDL a Fallout také míří na interní buffery procesoru: Line Fill Buffers, Load Porty a Store Buffery (u Falloutu). Těmi procházejí všechny data přicházející z paměti do CPU stejně jako data, která CPU ukládá do RAM. Útok je opět spekulativní: útočník se pokusí o load dat z oblasti, kam nemá přístup (a kde se nachází proces-oběť). Spekulativní vykonávání v procesoru požadovaná data dodá z bufferů procesoru (například Line Fill Bufferu), ačkoliv by nemělo. Tato neoprávněnost je zjištěna až dodatečně a CPU pak operaci revertuje. Ovšem škodlivý kód má mezitím příležitost si data přečíst a zkopírovat pro vlastní potřebu, s čímž už uklízející CPU nic neudělá.

datove struktury mds zranitelnosti
Červeně označené jsou zde datové struktury v procesoru Intel, jejichž slabé zabezpečení zneužívají MDS zranitelnosti

Tyto chyby mají jinak označení CVE-2018-12126 „Microarchitectural Store Buffer Data Sampling“, CVE-2018-12127 „Microarchitectural Load Port Data Sampling“ a CVE-2019-11091 „Microarchitectural Data Sampling Uncacheable Memory“.

Úniky/krádeže citlivých dat, odposlech na serverech

Všechny tři tyto útoky dokáží získat data z paměti privilegovaných procesů, operačního systému, hypervizoru a jiných VM běžících virtualizovaně na sdíleném fyzickém serveru (to znamená že jeden klient může šmírovat další zákazníky providera) a také ze zabezpečených enkláv SGX, čímž prolamuje jejich účinnost. Autoři uvádějí, že se tímto způsobem dá získat například historie procházení z prohlížeče, klíče, hesla a obecně data, která byla nedávno procesorem zpracovávána. Například obsah webových stránek prohlížených v již zavřeném anonymním okně prohlížeče.

VUSec například demonstroval únik dat z chráněného souboru /etc/shadow na Linuxu, v němž může mít systém uložené citlivé údaje včetně hesel. Tato operace byla realizována čistě jen pokusy o autentifikování přes SSH připojení, přičemž při každém pokusu byla leaknuta malá část a celý proces trval 24 hodin. Výzkumníci ale upozorňují, že rychlost závisí na okolnostech a v některých případech by útok mohl nést ovoce v řádu minut. V jiných demech bylo demonstrováno získání hashe hesla roota a také útok RIDL z javascriptového kódu.

Obrana: v softwaru plus aktualizací mikrokódu

Intel v dokumentu k těmto chybám uvádí, že chystá hardwarové opravy těchto slabin, které budou zapracovány do budoucích procesorů. Zatím není specifikováno, kterých/kdy. Na nynějších zranitelných procesorech bude třeba chybu ošetřovat v softwaru, podobně jako Spectre. Je třeba rizikové buffery vyprázdnit vždy před rizikovým přechodem, například před přechodem z jaderného do uživatelského režimu, před přepnutím z hypervizoru do kódu hostovaného klienta, při přechodu z kódu běžícího v enklávě SGX do kódu běžícího venku – a tak podobně. Tím by se mělo zajistit, aby pokud v neprivilegovaném režimu poběží útočný kód, nebude moci získat data patřící do privilegovaných/citlivých oblastí paměti.

Funkce pro čištění těchto bufferů (MD_Clear) v těchto situacích nicméně nejsou na dnešních CPU zpřístupněné. Intel proto vydá aktualizace mikrokódu, které je přidají. Bude nutné, aby vám výrobce PC nebo desky dodal aktualizaci BIOSu, v níž bude tento mikrokód vložen. Případně by tuto aktualizaci mohl možná opět distribuovat Microsoft přes Windows Update (případně Linuxové distribuce přes své systémy), pak by se tedy dostalo i na počítače, pro které výrobce nový BIOS nevydá. Každopádně ale budete potřebovat aktualizaci nějakým způsobem získat. Jak OS, tak BIOS desky ji pak bude nahrávat při každém spouštění, aktualizovaný mikrokód je v CPU totiž volatilní a nepřežije restart nebo vypnutí (to také znamená, že aktualizace nijak CPU fyzicky nemění).

Zatím nevíme, pro které všechny CPU Intel tyto aktualizace vydá. Proti Spectre nakonec aktualizoval jen procesory Sandy Bridge a novější a jen část předchozích procesorů architektury Nehalem. Opět tedy asi dojde na situaci, kdy u části stále použitelných CPU (jako je například Core 2 Duo/Quad) nebude aktualizace dostupná.

Aktualizováno: Opravy mikrokódu budou dostupné jenom pro procesory Sandy Bridge a novější (viz tento dokument). Všechny verze Nehalemům (včetně 32nm) mají smůlu.

Naštěstí to vypadá, že existuje alternativní čistě softwarová cesta, která by dané buffery také měla vyčistit pomocí sekvence jiných instrukcí, ovšem potřebná sekvence se údajně může lišit pro různá CPU. Intel uvádí odlišnou sekvenci pro skupinu Nehalem/Westmere a Sandy/Ivy Bridge, další pro Haswell/Broadwell, opět další pro Skylake a deriváty a ještě jiné pro Atomy (Silvermont/Airmont) a Xeony Phi (Knights LandingKnights Mill).

Patenty zranitelnost RIDL a Fallout VUSec
VUSec uvádí, že zranitelnost RIDL byla zjištěna už z popisů fungování CPU v patentech Intelu

Aktualizujte Operační systém

Pro fungování obou způsobů této ochrany musí ovšem být aktualizovaný používaný software a operační systém, pro které by měly teď již vycházet dotyčné aktualizace. Microsoft je pro Windows vydal v rámci včerejšího záplatovacího úterý (mělo by jít o aktualizaci KB4494441). Abyste opravy těchto chyb dostali, dbejte na to, abyste udržovali systém maximálně aktualizovaný a neodkládejte instalaci oprav. Respektive, ignorujte je jenom tehdy, pokud si jste pokročilí uživatelé a jste si skutečně jistí, že případné riziko je zanedbatelné nebo irelevantní. Obecně doporučujeme raději neriskovat a mít všechny dostupné aktualizace a opravy těchto bezpečnostních rizik nainstalované a zapnuté.

Dopady těchto chyb lze asi zhruba hodnotit jako podobné, jako u Spectre a Meltdownu. Největší riziko je pro servery, zejména cloudové, kde je útok hodně nepříjemný. Pro běžné uživatele PC je expozice škodlivému kódu menší a největším nebezpečím by bylo, pokud by tyto útoky zkoušel javascript na webových stránkách. Pokud tedy máte procesor Intel v v desktopu nebo notebooku, nemusíte vyloženě panikařit nebo hardware překotně měnit; i bez oprav asi nehrozí výrazně velké riziko (ovšem nikdy asi nelze zaručit, že tyto díry nezačne něco masivně napadat). Jak opět obecně doporučujeme průběžně instalovat všechny aktualizace operačního systému a důležitých programů jako jsou internetové prohlížeče, abyste riziko minimalizovali.

Hardware pouzity k odhaleni a popisu zranitelnosti RIDL a Fallout VUSec
Hardware pouzity k odhaleni a popisu zranitelnosti RIDL a Fallout VUSec

Patche podle Intelu stojí jen 1 až 3 % výkonu, ale…

Tyto opravy v softwaru a patrně i flushování bufferů pomocí nové funkce MD_Clear přidané aktualizacemi mikrokódu ale asi budou mít dopad na výkon při přechodu mezi jádrem a uživatelským prostorem a v podobných situacích. Dopad by asi mohl být podobného charakteru jako u Meltdownu/Spectre – zpomalení systémových volání a snížení výkonu I/O operací, které se projeví zejména v rychlosti NVMe SSD. Je možné, že bez aktualizovaného mikrokódu bude propad výkonu horší, než při využití nového mikrokódu, případně ochrana může být méně spolehlivá – jinak by totiž asi Intel věc pomocí mikrokódu neřešil. Ale pro to, jaké by v tom případně mohly být rozdíly, zatím informace nemáme.

Podle této stránky Intelu by na desktopu propad výkonu kvůli opravím MDS chyb v řadě úloh nemusel být ani patrný, v některých nastane zpomalení o 1–3 % (měřeno na Core i9-9900K). Otázkou ovšem je, zda byly pro tato čísla zvolené úplně relevantní benchmarky. Intel totiž hned vedle udává také příklady toho, jaký dopad má vypnutí HT, a to podle něj stojí jen 7–9 % výkonu, což je myslím příliš málo. HT má v mnoha škálujících aplikacích mnohem lepší přínos, a tudíž jeho vypnutí větší ztrátu; Intel si zdá se vybral příklady tak, aby v nich tyto velké ztráty nebyly. Je tak možné, že ony 1–3 % stejně tak neukazují nejhorší možné projevy.

Jinak mimo běžné uživatelské počítače Intel uvádí nejhorší (mimo situaci s vypnutím HT) dopad ve storage serverech, kde podle něj může nastat zhoršení až o 14 % (na Xeonu Platinum 8180). Toto opět připomíná SPectre/Meltdown, lze tedy čekat, že i v PC s NVMe úložišti může být postih víc než ty tři procenta.

Hyper Threading je opět slabinou

Ve většině těchto chyb figuruje jako rizikový faktor (ale ne jediný/nezbytný) Hyper Threading/SMT. Datové struktury, na které se útok zaměřuje, jsou totiž sdílené. Jako jeden ze způsobů ochrany se proto uvádí i vypnutí HT, což má ovšem velký dopad na výkon. Místo toho by ideálně neměli dva uživatelé (dvě VM) sdílet na serveru mít přiřazená vlákna (logické procesory) patřící k jednomu fyzickému jádru.

Intel nedoporučuje vypnutí HT jako obecné řešení těchto chyb (ty jsou zneužitelné i s neaktivním HT), ale ve svých formulacích připouští, že vypnutí HT může být pro některé (serverové) uživatele žádoucím opatřením navíc k softwarovým opravám.

Aktualizováno: mnozí výrobci operačních systémů teď uvádějí, že maximální úroveň ochrany před těmito chybami vyžaduje vypnutí HT, byť to nedoporučují všem uživatelům, ale jen těm, kteří čelí vyššímu riziku nebo spouštějí nedůvěryhodný kód (takto to formuluje Apple, který také varuje, že to může snížit výkon až o 40 %). Ovšem Google je o dost radikálnější a kompletně vypne HT v Chromeboocích, respektive systému Chrome OS.

Další informace: Hyper Threading v ohrožení kvůli dírám v CPU Intel. Google ho úplně vypne, jinde váhají


Zdroje k MDS zranitelnostem:

Nástroje MDS Tools pro kontrolu, zda je systém zranitelný

VUSec kromě informací, zdrojového kódu exploitu a dem také publikoval nástroj, kterým můžete otestovat počítač a zjistit, zda se vás MDS zranitelnosti týkají, či zda je má váš operační systém ošetřené, případně zda mikrokód vašeho procesoru poskytuje funkci MD_Clear.

Vystup programu MDSTool win32
Výstup programu MDSTool-win32.exe na procesoru Intel Atom Z3740 (Bay Trail) ukazuje stav MDS zranitelností a některých dalších bezpečnostních děr a záplat. Poznámka: ač to možná podle červených nápisů “vulnerable” nevypadá, jde o plně aktualizovaný Asus Transformer Book T100TA s 32bitovými Windows 10 1809

Galerie: Bezpečnostní chyby MDS v procesorech Intel: ZombieLoad, Fallout, RIDL


Objeveny nové díry v procesorech Intel: zranitelnosti MDS. Rizika podobná jako u Spectre
Ohodnoťte tento článek!
4.8 (96.52%) 23 hlas/ů

36 KOMENTÁŘE

    • Dívám se na to a týkalo by se to Whiskey Lake (refresh) a Cascade Lake. Ale – od oubou těchto rodin jsou zároveň revize, které jsou označené jako že MDS zranitelnosti mají, respektive dvě ze tří.
      Takže to asi bude opravovat nějaká jejich revize, kterou Intel buď vydal, nebo ji teprve plánuje, akorát z tohohle teda nevím, jestli už se třeba začala prodávat, nebo je teď ještě všechno na trhu zranitelné.

  1. Drobný problém je, že nově objevené zranitelosti lze zneužít vcelku jednoduše, blbým javascriptem, zatímco na zneužití Spetre a Meltdown musel být využit sofistikovaný postup, jehož výsledek závisel na tom, co procesor zpracovával za instrukce a data.

    • Spectre i Meltdown byly demonstrovany na javascriptech v prohlizecich. Tyto nove zranitelnosti maji dle CVSS zavaznost nizka az stredni, takze urcite nejsou zavaznejsi nez spectre a meltdown. Opet maji “problem” hlavne VM cloudy.

    • Vsechny predchozi mitigace davaji v syntetickych NVME SSD I/O testech 6-12%, v realu na hranici chyby mereni. Testovano na osme generaci CPU. Starsi generace po aplikaci retpoliny na tom nebudou nejak zasadne hur. Tyto nove mitigace pridavaji udajne 0-3% (v I/O, na vypocetni vykon to opet nema vliv). Zadne nezavisle testy zatim venku nejsou.

    • Těch 9 % co se někde píše je myslím vzato z grafu s “HT OFF”, takže v tom je zahrnuté vypnutí HT. Jak tam píšu v tom článku, tak je to zrovna dost podezřele nízké číslo, takže IMHO těch 1-3 % dopadu, když se HT nevypne, nemusí být úplně reálných. V nějakém testu výkonu SSD bude propad podle mě vyšší.

      V úlohách, které hodně vytěžují jádra CPU a ne I/O, by zpomalení být nemuselo (podobně jakou Spectre/Meltdown).

  2. Tady jde krásně vidět to, že architektura Core je už prostě zastaralá a její neustálé vylepšování sice přináší nějaký ten výkon navíc, ale tento náskok pak je zpětně zase degradován kvůli patchům na tyto chyby.
    Intel by měl začít vyvíjet novou architekturu, tak jako AMD, když přišli se Zenem před 3 roky.

    • Spíše bych řekl to, že v době vzniku návrhu nikdo o takových typech útocích ani neuvažoval. Stejně, nás jako nás dnes nenapadnou typy útoků za 10 let. To myslím není věc zastaralostí architektury, to je spíše paradigma. Vem si, že na obdobné útoky jsou citlivé i IBM Power, Z1 atd.
      U CPU, co podobné zranitelnosti nemají, tak je to podle mě spíše důsledek (nebo lépe vedlejší efekt) jiného návrhu, ale není to tak, že na tom při návrhu pamatovali. Na to jsou tyto typy zranitelností hodně mladé.
      Tím vedlejším efektem myslím to, že když např. v aplikace z nějakého (zcela jiného) důvodu nebudu používat dělení čísel, tak tam nemůže nastat chyba dělení nulou.

      Tím ale nerozporuji, že architektura Core může dnes být zastaralá, to neposoudím.

      • To, co píšeš, je samozřejmě pravda, nic není dokonalé a neexistuje způsob, jak otestovat úplně všechno před vydáním CPU architektury. Je prakticky nekonečně mnoho kombinací konkrétních situací a často se na chyby přijde vlastně úplnou náhodou.
        Každopádně u Intelu je situace taková, že od zveřejnění Spectre a Meltdown se prakticky pravidelně objevují nějaké další nové chyby, které často mají podobný způsob zneužití.
        Proto si myslím, že by Intel udělal lépe, kdyby začal pracovat na nové architektuře s jiným návrhem té kritické části než opravovat tu současnou (ať už hardwarově nebo softwarově). Hlavně co se týče HT, který je právě tím slabším místem.

        Každopádně jak už tu někdo píše, Intel má podstatně výraznější zastoupení na trhu s CPU, takže případný nález chyby je mnohem více pravděpodobný než u AMD CPU.

    • Tohle asi není správný závěr.
      Důvod, proč všechny tyhle průšvihy má Intel a nikdo jiný, bude jinde – příliš agresivní spekulací. Evidentně měli inženýři politiku provádět spekulativně operace kde to jen bude možné, s nízkým ohledem na případné chybné spekulace. Je dost možné, že tahle politika jim dovolila mít těch letech 2008-dodnes tak vysoké IPC a energetickou efektivitu proti ostatním. Inženýři dělající na Zenu nebo ARMech asi tu spekulaci u těchhle různých operací používají míň agresivně/s větší opatrností a kontrolováním, možná někdy i z ohledu na bezpečnostní rizika.

      • Nebo možná ještě jinak: tohle tím pádem může být i projev toho, že Intel zašel v optimalizaci architektury na výkon dál než ostatní a víc si to tím pádem vyžral, když se vynořily tyhle spekulativní útoky, kdežto konkurence může mít paradoxně trochu štěstí, že v tomhle trochu zaostala.

        Ale zas tak jednoduché to taky být nemusí, klidně tam opravdu u ARM/AMD už mohlo jít o projev oprávněné opatrnosti, zatímco Intel se to rozhodl riskovat.

        Každopádně to ale nebude “zastaralost”. Koneckonců to postihuje CPU Intelu z roku 2008, ale ne AMD z roku 2008 a pozdějších (K10, Bulldozery atd).

  3. Tohle retezeni chyb, kdy se objevuji dalsi a dalsi s vyssi pravdepodobnosti realneho zneuziti zacina byt dost desiva. Zajimave, ze se to tyka predvsim Intelovskych navrhu. Byt adminem a mit vliv na vyber HW do firmy, tak se Intelu zacnu opravdu vyhybat.

    • Jo, tu ž jsem tak nějak prošvihl/nechal být, se přiznám. Přišla mi o něco méně závažná než ta úroveň Spectru a dalších spekulativních útoků, protože ty přímo leakují data, kdežto Spoiler jenom leakuje informaci o fyzické paměti (takže probíjí ASLR a je to pořád něco, k čemu hacker/útočník/nepriviligovaný uživatel nemá mít přístup, ale skutečný útok se pak musí realizovat až v kombinaci s další zranitelností, třeba rowhamemerem).

  4. Použil jsem ten tool z článku a červený mám pouze poslední 4 položky (mimo SMT), což předpokládám, že znamená, že se mě na 4570 týkají právě ty nejnovější chyby.

    A ted mi odpustte mozná hloupý dotaz nebo dva, ale mužou mi tímhle způsobem odposlechnout heslo zavaděče VeraCryptu, kterým mám zašifrovaný systémový disk? Předpokládám, že ne, ale ujišťuju se, že jsem to pochopil správně.

    A teoreticky – kdybych měl všude dvoufázové přihlašování a bankovnictví na PC vůbec nepoužíval, takže bych se bál hlavně o krádež fotek z disku – má mě tahle zranitelnost nějak vzrušovat?

    • “Použil jsem ten tool z článku a červený mám pouze poslední 4 položky (mimo SMT), což předpokládám, že znamená, že se mě na 4570 týkají právě ty nejnovější chyby. ”
      Už jsem to viděl u někoho jinde na fóru, ale vypadá to, že ty ostatní (starší) chyby to někomu detekuje špatně a ukazuje to, že u daného CPU neexistují, i když je má (tam to bylo i7-8700K). Ten nástroj je asi ne vždy detekuje správně (mě fungoval, zvláštní, ale holt je nový, tak asi má bugy – případně si říkám jestli třeba nemohl být problém s oprávněním, že to neběželo jako správce, nebo tak něco).
      Každopádně Haswellnemá žádné z těch novějších oprav a týká se ho IIRC snad úplně všechny ty slabiny, co se od začátku roku 2018 našly (ale to je stejné třeba u toho Skylake, lepší je to až s těma nejnovějšíma čipama, kde se začínají opravy objevovat).

      Co se týče těch rizik. Teoretická možnost odposlechu dešifrovacích klíčů uložených v RAM je právě asi největší riziko téhle věci, i když dostat se přesně k těm konkrétním datům by neměla být zas nějak snadná věc pro nějaký automaticky pracující malware (aspoň doufám). Jestli je ten klíč ponechaný v paměti, což asi musí být, aby se z disku dalo číst, tak ho tyhle útoky dovolující čtení libovolné části RAM, mohou opravdu leaknout. Samozřejmě v praxi ho budou muset najít, nebo nějakým způsobem vědět, kde hledat.

      U disku – z disku takový malware číst nebude moct. Dostane se (zase mluvíme teoreticky) k tomu, co je v RAM, tj. jen k tomu, co by někdo na tom PC otevřel a tím by se to načetlo do RAM. Pro krádež většího objemu dat nevím, jestli jsou tyhle útoky zas tak nebezpečné, protože je u nich často poměrně nízká rychlost toho pokoutního čtení. Takže na větší objem dat to může být nevhodné, protože by to trvalo dlouho – nejnebezpečnější je to proto na ty klíče a přístupové údaje, což je na velikost malá věc a když se tedy trefí její lokace v RAM, tak je to venku rychle.

      • Rozumím. Děkuji za odpověď.

        Já jsem doufal, že některý z těch předchozích, loni objevených chyb se mě netýkaj proto, že ten muj procesor nemá HT (vím, že u něčeho ho doporučili vypnout a netýkalo se to těch nejnovějších chyb). Takže to mám ale stejně děravý. 😀

        A co se týče toho odposlechu těch šifr. klíčů, tak jsem se domníval, že i kdyby se mi ten škodlivý kod dostal do pc, třeba přes nějakej javascript, tak ho restartem z tý paměti dostanu. Jenže až teď při psaní mi dochází, že ty klíče musej v paměti asi bejt uložený i po tom, co si ten disk při startu PC “odhesluju” a tim pádem ten kód vůbec nepotřebuje, abych to heslo zadával “za jeho dohledu”.