Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů
Bakalářská práce
Použití Intel AMT a IPMI pro testování low-level softwaru Václav Fanfule
Vedoucí práce: Ing. Michal Sojka, Ph.D.
13. května 2014
Poděkování Děkuji vedoucímu práce Ing. Michalu Sojkovi, Ph.D. za vedení, rady a pomoc při tvorbě této práce. Dále také děkuji rodině za podporu v průběhu celého studia a všem dalším, kteří jakkoli přispěli ke vzniku této práce.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen „Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či spracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla.
V Praze dne 13. května 2014
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2014 Václav Fanfule. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci Fanfule, Václav. Použití Intel AMT a IPMI pro testování low-level softwaru. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.
Abstract This paper focuses on Intel Active Management Technology (AMT) and on using this technology for testing low-level software. The result is a set of tools for power control, IDE redirection and serial over LAN and integration of these tools into the novaboot tool, which is used for testing low-level software. Created tools are primarily intended for Linux. Keywords AMT, SOL, IDE-R, novaboot, Power control
Abstrakt Práce je zaměřena na technologii Intel Active Management Technology (AMT) a na využití této technologie při testování nízkoúrovňového softwaru. Výsledkem je vytvoření sady nástrojů pro ovládání stavu napájení, IDE redirection a serial over LAN a integrace těchto nástrojů do nástroje novaboot, který slouží pro testování low-level softwaru. Vytvářené nástroje jsou primárně určeny pro Linux. Klíčová slova AMT, SOL, IDE-R, novaboot, Ovládání stavu napájení
ix
Obsah Úvod
1
1 Technologie 1.1 Intel AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Nástroje pro práci s AMT . . . . . . . . . . . . . . . . . . . . . 1.3 Novaboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 3 5 7
2 Implementace 2.1 Remote power control a SOL . . . . . . . . . . . . . . . . . . . 2.2 IDE-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 9 10
3 Návod k použití 19 3.1 Povolení SOL apod. . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Flashování ME . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Použití novabootu . . . . . . . . . . . . . . . . . . . . . . . . . 21 4 Testování 25 4.1 Použité počítače . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2 Výsledky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Závěr
29
Literatura
31
A Seznam použitých zkratek
35
B Obsah přiloženého CD
37
xi
Seznam obrázků 1.1 1.2
Diagram platformy založené na chipsetu Q87 [15] . . . . . . . . . . Diagram komunikace SOL . . . . . . . . . . . . . . . . . . . . . . .
4 6
2.1 2.2 2.3
Zprávy na velikost média . . . . . . . . . . . . . . . . . . . . . . . Struktura zprávy s odesílanými daty. . . . . . . . . . . . . . . . . . Struktura požadavku na zaslání dat. . . . . . . . . . . . . . . . . .
14 15 16
3.1 3.2 3.3
Stavy AMT [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AMT MEBx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AMT web server . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19 20 21
xiii
Seznam tabulek 4.1 4.2 4.3 4.4
Specifikace Specifikace Specifikace Specifikace
prvního testovacího počítače Gigabyte druhého testovacího počítače ASUS . . třetího testovacího počítače Lenovo . . čtvrtého testovacího počítače Dell . . .
xv
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
25 25 26 26
Úvod Testování nízkoúrovňového softwaru (například jádra operačního systému nebo ovladačů zařízení) je podstatně náročnější než testování běžných programů. Pokud je testován běžný program, je možné ho zkompilovat a spustit na lokálním počítači. Jeho chyby nijak neohrozí operační systém, stačí pouze program opravit a zkompilovat znovu, ovšem při testování low-level softwaru může často docházet k pádu celého operačního systému. Z tohoto důvodu tedy není žádoucí testovat nízkoúrovňový software na stejném počítači, na kterém je vyvíjen. Z tohoto důvodu byl vyvinut nástroj novaboot, který automatizuje bootování různých operačních systémů na různých počítačích nebo v emulátoru [20]. Cílem této práce bylo prozkoumat technologii Intel Active Management Technology (AMT) a využít ji při testování low-level softwaru. Jedná se především o možnost řízení stavu napájení počítače bez závislosti na aktuálním stavu napájení počítače nebo operačním systému počítače. Jediná podmínka je, že počítač musí být připojen do elektrické a počítačové sítě. Dále jde o přesměrování výstupu sériové linky ze vzdáleného počítače za účelem získání výstupu z tohoto počítače. Nakonec jsem také využil přesměrování IDE zařízení na testovaný počítač (IDE-R). Tato funkce umožňuje připojit virtuální CD mechaniku na vzdáleném počítači. Data z tohoto CD jsou ale uložena na lokálním počítači ve formě ISO obrazu disku a jsou na vzdálený počítač posílána přes síť. Z této virtuální CD mechaniky je možné na vzdáleném počítači nabootovat testovaný software (například jádro operačního systému) i přesto, že data, ze kterých se načítá daný software jsou uložena pouze na lokálním počítači. V první kapitole se zabývám popisem technologií využitých v této práci, nejprve zmíním hlavní součásti a specifikace technologie Intel AMT, poté se zaměřím na nástroje pro práci s AMT a to zejména na Software Developement 1
Úvod kit (SDK), který vydal Intel na podporu AMT a budu pokračovat u opensource nástrojů amtterm a amttool. Ve druhé kapitole části se nachází popis samotné implementace, konkrétně se jedná o podporu Serial over LAN (SOL), vzdáleného řízení stavu napájení a IDE redirection. Všechny funkce, které jsem implementoval využívají technologii Intel AMT. V původním zadání byla i část zabývající se technologií Intelligent Platform Management Interface (IPMI). Kvůli podstatně vyšší náročnosti implementace IDE-R, než bylo očekáváno, bylo po konzultaci s vedoucím práce rozhodnuto, že se zaměřím pouze na AMT a upřednostním kompletní dokončení práce s AMT před započetím práce na IPMI. IPMI jsem se věnoval pouze z teoretického hlediska. Pravděpodobně by nebylo možné přesměrovat pomocí IPMI obraz disku, SOL a řízení stavu napájení by nejspíš pomocí IPMI možné bylo [9], z tohoto pohledu jsem se tedy věnoval pro tyto účely vhodnější technologii. Ve třetí části mé bakalářské práce jsem vytvořil také detailní návod k použití a nastavení AMT na daném počítači. Ve stejné kapitole se také nachází popis aktualizace firmwaru pro AMT, v neposlední řadě je zde uveden i návod k použití nástroje novaboot. Ve čtvrté kapitole s názvem Testování uvedu na jakých počítačích probíhal vývoj a testování a jsou zde uvedeny i výsledky mé práce. Využitelnost vidím především při testování a ladění low-level softwaru v součinnosti s nástrojem novaboot. Využití AMT značně zjednodušuje použití novabootu, není již potřeba hardwarový prvek který by obstarával vzdálené ovládání napájení a přesměrování sériové linky. Je možné také použít jednotlivé programy zvlášť, například je možné pomocí IDE-R na vzdáleném počítači přeinstalovat operační systém.
2
Kapitola
Technologie V této kapitole stručně představím technologie použité v mé bakalářské práci. Nejprve představím technologii Intel AMT, poté se zaměřím na nástroje pro práci s AMT a v závěru kapitoly představím nástroj Novaboot.
1.1
Intel AMT
Intel AMT (Active Management Technology) je technologie pro vzdálenou správu počítačů založených na platformě Intel bez závislosti na operačním systému. První verze Intel AMT se objevila v období procesorů Core 2 (rok 2006). Pomocí AMT je možné například restartovat vzdálený AMT počítač, přesměrovat sériovou linku nebo přesměrovat IDE machaniku. Tuto technologii podporují některé základní desky s chipsetem řady Q. Základní desky s chipsetem Q965 jsou první, které mohou mít podporu technologie Intel AMT. S každou další generací chipsetů vydal Intel novou generaci AMT, aktuální verze Intel AMT je 9.0. Update na novější generaci AMT je možný pouze prostřednictvím výměny základní desky. Intel AMT patří pod marketingové označení vPro. Pod označení vPro kromě AMT spadá například podpora zabezpečení IEEE 802.1x, podpora hardwarové virtualizace a další převážně bezpečnostní technologie [12]. Pro podporu AMT není potřeba žádný další specializovaný hardware, všechny funkcionality jsou integrované v chipsetu prostřednictvím mikrokontroléru založeného na architektuře ARC [19]. O samotnou obsluhu AMT se stará Management Engine (ME), což je součást BIOSu. Rozšíření BIOSu pro správu ME se nazývá MEB-x (Management Engine BIOS Extension). Blížší informace jsou vidět na obrázku 1.1. Technologie AMT má za primární cíl zjednodušení správy počítačů v podnikové síti. Její výhody spočívají ve zjednodušení a usnadnění práce administrátorů, nevýhodami jsou především požadavky na hardware, pro funkčnost této technologie je potřeba mít certifikovanou základní desku s chipsetem řady 3
1
1. Technologie
Obrázek 1.1: Diagram platformy založené na chipsetu Q87 [15] Q. Někteří výrobci počítačových sestav ale tuto funkcionalitu v některých případech blokují [2]. Výběr těchto základních desek je omezený, ale především v podnikové sféře jsou hojně zastoupené. Mezi hlavní funkce AMT patří: • řízení stavu napájení vzdáleného počítače • IDE redirection (IDE-R), které umožňuje přes síť emulovat IDE mechaniku, využívá se pro přesměrování mechaniky nebo obrazu CD • přesměrování sériové linky • od verze 6.0 připojení ke vzdálenému grafickému uživatelskému rozhraní s možností ovládání vzdáleného počítače (KVM) [1] za využití protokolu VNC. • User Consent - možnost vyžadovat před každým připojením k počítači souhlas uživatele. Vzdálené ovládání počítače je realizováno několika způsoby, jedním z nich jsou protokoly pro vzdálené volání procedur Simple Object Access Protocol 4
1.2. Nástroje pro práci s AMT (SOAP) [22] nebo Web Services Management (WS-management) [3]. WSmanagement i SOAP posílají XML strukturované příkazy na ovládaný počítač, WS-management vychází ze syntaxe SOAP, využívá pouze jiné konkrétní příkazy. Další možnost je využít k řízení zabudovaný web server. Intel AMT využívá pro síťovou komunikaci protokol TCP a porty 16992 a 16994. Port 16992 je využíván pro integrovaný web server a pro WS-management, 16994 pak pro serial over LAN (SOL), IDE-R a případně KVM (KVM je možné i přesměrovat na výchozí VNC port 5900). Síťová komunikace může (ale nemusí) být zabezpečena pomocí protokolu TLS. Při TCP komunikaci je využívána Digest [6] nebo Basic autorizace. Je možná i autorizace pomocí Active Directory účtu nebo pomocí protokolu Kerberos. Mezi alternativy k AMT se řadí například Open Platform Management Architecture (OPMA) nebo Intelligent Platform Management Interface (IPMI) [9]. OPMA je otevřený standard pro vzdálenou správu hardwaru. Vyžaduje připojení dedikované karty do tzv. mCard slotu a v některých verzích vyžaduje i připojení druhého ethernetového kabelu výhradně pro technologii OPMA, proto je tato technologie vhodná spíše pro servery. OPMA je podporovaná firmou AMD a stává se tak přímým konkurentem pro AMT od Intelu, AMT je ale mnohem více rozšířeno, a to především v osobních počítačích. IPMI je v dnešní době nejrozšířenější technologií pro vzdálenou správu hardwaru serverů. Narozdíl od AMT vyžaduje IPMI dedikovaný chip, který může být přímo integrovaný buď na základní desce, nebo na přídavné PCI kartě. Může být využito jak pro zjišťování informací ze senzorů (teploty, otáčky ventilátorů atp.), tak pro SOL (Serial over LAN) a další. IPMI je určen pro vzdálenou správu, je tedy podobně zaměřen jako AMT. Jeho nevýhoda je, že standard pro IPMI je omezený a další rozšíření (jako web server nebo KVM) již implementuje každý výrobce serveru sám, a proto není jednoduché vytvořit univerzální ovládací program.
1.2
Nástroje pro práci s AMT
V této sekci jsou uvedeny nástroje pro práci s AMT.
1.2.1
SDK
Firma Intel na svých stránkách uveřejňuje Software developer kit (SDK), který má pomoci vývojářům s psaním programů které podporují Intel AMT. Součástí tohoto SDK jsou jak ukázkové kusy kódu, tak knihovny potřebné pro samotný běh programů. V neposlední řadě také obsahuje dokumentaci k Intel 5
1. Technologie
AMT PC Intel AMT
Síťová karta
SOL
PC
Virt. sériový port Operační systém
Obrázek 1.2: Diagram komunikace SOL AMT. Zdrojové kódy v SDK jsou psané v C++ a C# a některé skripty, převážně pro nastavení AMT, jsou psané v powershellu. Intel neuveřejňuje zdrojové kódy podpůrných knihoven, v rámci SDK dodává pouze již zkompilované dynamické (pro Windows) nebo statické (pro Linux) knihovny. Tyto knihovny ovšem oficiálně podporují pouze některé hlavní distribuce Linuxu, jako Red Hat nebo Debian a to v 32 i 64bitové verzi. Množství ukázkových aplikací pro Linux je výrazně nižší než pro Windows, taktéž některé funkce jsou přístupné pouze pro Windows. Samotné protokoly např. pro SOL nebo IDE-R nejsou v rámci SDK zdokumentovány. Taktéž WS-Management je zdokumentován pouze z uživatelské stránky, samotná struktura XML dotazů posílaných na AMT již není zdokumentována ani jinak popsána. SDK je poměrně rozsáhlé a zaměřuje se především na administrátory a na hromadnou správu počítačů s AMT. Intel AMT SDK je ke stažení na webu firmy Intel [8]. Referenční příručka je k dispozici tamtéž [10].
1.2.2
Amtterm, amttool
Amtterm a amttool jsou open source nástroje od Gerda Hoffmanna určené pro práci s AMT počítači [7]. První verze byla vydána v roce 2007, v současnosti další vývoj neprobíhá, ale jsou opravovány chyby v těchto programech. Amtterm je nástroj, který umožňuje přesměrování sériové linky po síti (SOL), což je přeposlání výstupu sériové linky z testovaného počítače přes síť do jiného počítače a naopak. Diagram pro SOL je zobrazen na obrázku 1.2. Amtterm je psán v jazyce C a nevyužívá SDK, přímo komunikuje s ME přes TCP spojení s využitím komunikačního protokolu pro AMT SOL. Ve výchozím nastavení pracuje na portu 16994. Výchozí uživatelské jméno použité utilitou amtterm je „admin“, heslo je bráno z proměnné prostředí AMT_PASSWORD nebo z parametru. Pokud není zadán parametr pro heslo ani není nastavena 6
1.3. Novaboot proměnná AMT_PASSWORD, amtterm si vyžádá zadání hesla po spuštění. Aktuální verze je 1.3. V této i ve starších verzích se SOL přesměrování přeruší při každém restartu hostitelského počítače kvůli nedekódování jednoho druhu zprávy. Oprava této chyby je k dispozici v repozitáři projektu, ale tato opravená verze nebyla vydána a nedostala se tak například do Debian repozitářů. Amttool je nástroj pro získání informací o AMT a změnu stavu napájení vzdáleného počítače připojeného přes síť. Amttool je napsán v jazyce Perl a využívá protokol SOAP (Simple Object Access Protocol). SOAP je protokol pro výměnu zpráv, založených na XML, pomocí HTTP. V AMT 6.0 byl SOAP označen jako zastaralý [13] a od AMT verze 9.0 (která odpovídá procesorům Core čtvrté generace) již není vůbec implementován. Jako jeho náhrada je od AMT verze 3.2 implementován WS-management. Program amttool tedy není možné použít s nejnovějším hardwarem, ale na starších počítačích je využitelný především k získání informací o počitači nebo ke změně stavu napájení. Ukázka výpisu informací: ./amttool 147.32.86.81 info AMT version: 6.2.20 Hostname: . Powerstate: S5 (soft-off) Remote Control Capabilities: IanaOemNumber 0 OemDefinedCapabilities IDER SOL BiosReflash BiosSetup BiosPause SpecialCommandsSupported PXE-boot HD-boot cd-boot SystemCapabilitiesSupported powercycle powerdown powerup reset SystemFirmwareCapabilities f820 K nástrojí amttool neexistuje žádná alternativa, která by využívala protokol WS-management. Z dlouhodobého hlediska tedy není příliš vhodné spoléhat se pouze na amttool.
1.3
Novaboot
Novaboot je nástroj pro zjednodušení bootování různých operačních systémů v různých prostředích. Načte takzvaný novaboot skript a použije ho buď k nabootování systému v emulátoru (například qemu), nebo k vygenerování konfigurace pro daný bootloader a případně i k nakopírování potřebných souborů (např. obraz jádra operačního systému) na správná místa, například na vzdálený server. Dále, pokud je to možné, přesměruje sériovou linku testovaného počítače na standardní výstup testujícího počítače. Mým úkolem bylo integrovat podporu AMT do novabootu.
7
Kapitola
Implementace V této kapitole se budu zabývat samotnou implementací. Nejprve popíši implementaci podpory změny stavu napájení, poté serial over LAN, v další sekci se budu zabývat IDE redirection.
2.1
Remote power control a SOL
Remote power control značí ovládání stavu napájení vzdáleného AMT počítače. K těmto účelům je možné použít utilitu amttool, která ale má nevýhodu v použití protokolu SOAP, který již od nových verzí AMT není podporován. Z důvodu zachování funkčnosti i s novými generacemi AMT jsem se rozhodl použít protokol WS-management. Implementoval jsem vlastní program s podporou AMT za využití WS-managementu, žádné již hotové řešení se mi nepodařilo nalézt. Existují programy na obsluhu WS-managementu, například wsl [21] nebo openwsman [16]. Wsl jsem se rozhodl nepoužít z důvodu špatné komunikace s AMT při put požadavcích, při požadavku na změnu stavu napájení, konkrétně při spuštění příkazu wsl put "CIM_PowerManagementService" PowerState=2 vrátí chybu namespace error : Namespace prefix c on SelectorSet is not defined a na základě této chyby není korektně vygenerován XML souboru, v tomto XML souboru zcela chybí požadavek na změnu PowerState. Get příkaz wsl get "CIM_PowerManagementService" ale proběhne v pořádku a vrátí očekávaný obsah.
Openwsman jsem nepoužil, protože není ve standardních repozitářích Debianu. Dále mi nepřišlo zcela nutné kvůli jednomu specifickému požadavku na WS-management používat externí nástroje, které většinou nejsou standardní součástí systému. Napsal jsem proto vlastní skript, který řeší autorizované připojení na AMT počítač a poté vykoná určenou změnu stavu napájení. 9
2
2. Implementace Skript je přímo součástí novabootu, je tedy psán v Perlu, za využití modulu LWP, který je určen pro obsluhu webu. K ovládání změny stavu jsou v novabootu implementovány další přepínače: • bez dalších přepínačů je AMT počítač restartován • s přepínačem --on je počítač pouze zapnut • s přepínačem --off je počítač vypnut a novaboot je poté ukončen. V případě neúspěšné změny stavu napájení je vypsána chyba a novaboot skončí chybou. Neúspěch může nastat zejména v případě, že je již někdo připojen k AMT, v tom případě selže pokus o vypnutí počítače. V případě pokusu o změnu stavu napájení lokálního počítače je také vypsána chyba. Také pokud je počítač vypnutý, tak se při pokusu o restart zobrazí varovné hlášení. Pro obsluhu SOL byl využit program amtterm, který je psán v jazyce C a jeho volání je taktéž integrované do novabootu. Je spouštěn za pomoci modulu Expect, po spuštění je 10 vteřin vyčkáno na vypsání textu RUN_SOL, který značí, že amtterm úspěšně navázal spojení a spustil přesměrování sériové linky. Pokud amtterm tento text nevypíše, novaboot vypíše chybové hlášení a ukončí se. Chyba může nastat zejména v případě, že je již někdo připojen k SOL na vzdáleném počítači, v takovém případě amtterm skončí chybou, mezi další chyby může patřit například neexistující cílový počítač nebo špatné heslo.
2.2
IDE-R
V této části se budu zabývat implementací IDE-R. Protože neexistuje žádný vhodný program pro Linux, který by toto řešil, bylo nutné zvolit vlastní řešení. Jsou dvě možnosti jak implementovat IDE-R, buď je možné využít SDK a napsat poměrně krátký program, nebo se SDK úplně vyhnout. Obě možnosti mají své výhody i nevýhody. • využití SDK – výhody jednoduchost a malá délka programu – nevýhody Intel poskytuje své podpůrné knihovny pouze ve formě uzavřených binárních knihoven, tento program tedy nemusí na některých platformách fungovat chybí kontrola nad programem a posílanými daty 10
2.2. IDE-R Intel v dokumentaci k SDK u popisu funkce „IMR_IDEROpenTCPSessionEx“ píše, že na Linuxu není podporované přesměrování obrazů disků, ale pouze přesměrování fyzických disků [10] • bez použití SDK – výhody univerzálnost, toto řešení bude fungovat bez ohledu na platformu přehled o tom, jaká data se posílají po síti – nevýhody složitost a rozsahu kódu IDE-R protokol není nikde zdokumentován nejprve je nutné metodami zpětného inženýrství zjistit, jak tento protokol funguje Po konzultaci se svým vedoucím práce jsem se rozhodl pro řešení bez využití SDK a jeho funkcí, zejména z důvodu funkčnosti na různých systémech a bez nutnosti využívání zbytečně rozsáhlého SDK. Původně jsem se domníval, že komunikační protokol pro IDE-R nebude příliš složitý, doufal jsem v textový nebo již nějaký známý zdokumentovaný protokol. Rozhodl jsem se pro prozkoumání tohoto protokolu použít program Wireshark, který slouží k zachytávání síťového provozu. Další možností byla dekompilace binárních knihoven z SDK, tato možnost mi přišla zbytečně komplikovanější než prozkoumání protokolu za využití programu Wireshark. Program na obsluhu IDE-R jsem psal v jazyce C. Jako referenční program jsem použil ukázkový program na přesměrování IDE a sériové linky z SDK v grafické verzi pro Windows. Na začátku procesu zkoumání protokolu pro IDE-R jsem zjitil, že není možné zachytávat síťový provoz na AMT počítači, zde se dotyčný síťový provoz již nedostane k programu Wireshark, je tedy proto nutné používat Wireshark na počítači, ze kterého je spuštěné přesměrování IDE. Bylo zjištěno, že tento protokol je stejný jako protokol pro SOL, pouze využívá jiné příkazy, pro další testování jsem tedy použil zdrojové kódy amttermu, které jsem dále rozšiřoval. Protokol je binární, obvyklá délka jednotlivých zpráv je přibližně 30 B, pokud se v dané zprávě neposílají přesměrovaná data. Odlišnou strukturu od ostatních zpráv mají inicializační a keep-alive zprávy, které budu popisovat později. AMT počítač budu dále nazývat server a počítač, ze kterého je spuštěno přesměrování, budu nazývat klient. Obecnou strukturu zprávy je možné vidět například na obrázku 2.1a. V prvních 4 bajtech zprávy je číslo typu zprávy 11
2. Implementace a případně i příznaky. Obvykle je použit pouze první bajt pro číslo typu zprávy, podle tohoto čísla ale není možné určit, o jakou zprávu se přesně jedná, je to pouze obecný typ zprávy, který například rozlišuje, jestli se jedná o navázání spojení, autorizaci, nebo o posílání dat. V dalších 4 bajtech je pořadové číslo zprávy, posílané, v rozporu se standardem pro posílání dat přes síť [18], v Little-endian pořadí. Výjimkou jsou pouze úvodní a autorizační zprávy, které číslo zprávy neobsahují. Veškeré požadavky jdou od AMT počítače, klient pouze odpovídá na dané požadavky. V dalších bajtech se již liší struktura požadavků od odpovědi. V 12. bajtu je určení přesného typu zprávy, 13. bajt slouží pro příznaky ohledně typu zprávy, obvykle je tento bajt nulový. Ve 14. a 15. bajtu se určuje, jestli se jedná o přesměrování disketové nebo CD mechaniky, pokud se jedná o přesměrování CD, tak tyto bajty mají hodnotu „B0 A0“. Pokud o FD, pak mají hodnotu „A0 A0“, ve zvláštních případech mohou mít tyto bajty i jinou hodnotu, především se to týká zpráv zasílaných během BIOS POST fáze (zjišťování stavu počítače BIOSem). Další bajty jsou již specifické pro každý požadavek a budou popsány při rozebírání jednotlivých požadavků, všechny čísla zpráv a jiná identifikační čísla budu pro přehlednost uvádět v hexadecimální soustavě. Jako první zpráva je posláno zahájení komunikace a určení, jestli se bude jednat o IDER nebo SOL. Tato zpráva používá první 4 bajty na typ zprávy, číslo zprávy je 0x10, délka zprávy je 8 B, v této zprávě je v textové podobě uvedeno „SOL“ nebo „IDER“. Následuje autentizace, ukázka z SDK využívala Digest autentizaci, já jsem ale použil funkce z amttermu, které používaly Basic autentizaci. Následuje příkaz pro spuštění přesměrování IDE-R a poté příkaz pro zapnutí přesměrování CD a FD. Není možné zapnout pouze přesměrování CD nebo FD, existuje jedině příkaz na zapnutí obojího současně. Tento příkaz je poslední, který posílá klient, ostatní posílá server a klient pouze odpovídá. Výjimkou je pouze příkaz pro ukončení přesměrování. Každá zpráva obsahuje své pořadové číslo, číslováno je od nuly, první číslovaná zpráva je první zpráva po autentizaci. Číslovány jsou zvlášť zprávy od klienta a zvlášť zprávy od serveru. Vzhledem k tomu, že odpověď na zprávu nemusí mít (a po zasílání dat ani nemá) stejné pořadové číslo jako původní zpráva, nedokázal jsem najít důvod, proč vůbec zprávy pořadové číslo obsahují. Vzhledem k tomu, že komunikace probíhá po TCP protokolu, který zajišťuje, že budou doručeny všechny zprávy a že budou doručeny ve stejném pořadí, ve kterém byly odeslány, není potřeba zprávy číslovat. Pomocí tohoto číslování ani není možné odeslat více požadavků a poté přijmout více odpovědí, protože odpověď na zprávu nemusí mít stejné číslo jako samotná zpráva. 12
2.2. IDE-R Číslo zprávy je pravděpodobně použito z důvodu univerzálnosti protokolu. Kdyby například byl použit transportní protokol UDP, bylo by již potřeba posílat číslo zprávy. V pravidelném několikavteřinovém intervalu jsou posílány tzv. keepalive zprávy, jejich délka je 8 B a kromě čísla zprávy (0x4B) obsahují pouze pořadové číslo. Na každou takovouto zprávu je nutné odpovědět se stejným číslem zprávy a vlastním pořadovým číslem. Zde využitý protokol nemá dokumentaci ani není popsán, není podobný žádnému mně známému protokolu na přenos dat po síti, pravděpodobně se jedná o upravenou verzi ATA příkazů [17], nekorespondují ale čísla požadavků a délka příkazů také neodpovídá. Poslání prvních dat z média je předchází přibližně 30 jiných požadavků, mezi nimi jsou například autentizace nebo zjištění velikosti média. Diagram zobrazující strukturu požadavku na zjištění velikosti média je možné vidět na obr. 2.1a. Zpráva, ve které je zaslána velikost média, má strukturu zobrazenou na obr. 2.1b Velikost média je čtyřbajtové kladné číslo přenášené po síti v Big-endian pořadí, narozdíl od čísla zprávy. Toto číslo je vypočítáno jako velikost obrazu disku v B lomeno velikost bloku mínus jedna. Velikost bloku je 2 048 B v případě CD a 512 B v případě disketové mechaniky. Další požadavek, který zde blíže popíši, je požadavek na poslání dat viz obr. 2.3. AMT si zažádá o určitý úsek dat z média, zašle informaci o požadované velikosti dat a o požadované pozici dat. První bajt ze čtveřice upřesnění typu požadavku značí, že se jedná o požadavek na poslání dat, při některých speciálních hodnotách příznaků ale nemusí být zasílána data, může se posílat pouze jiná zpráva. Druhý bajt značí velikost požadované části dat, velikost dat v bajtech je rovna 256násobku tohoto bajtu. Z toho vyplývá, že je možné v rámci jednoho požadavku požádat o maximálně 64 kB dat. V případě FD je vždy žádáno o data o velikosti nějakého násobku 512, v případě CD je žádáno o násobek 2 048. Pozice udává umístění prvního požadovaného bajtu dat, je posílána jako čtyřbajtové číslo v Big-endian pořadí. Je vypočítána jako velikost bloku krát poslané číslo. Jako odpověď je posílána hlavička znázorněná na obrázku 2.2. Příznaky, zejména u odpovědí, jsou si dost často velmi podobné, ale málokdy zcela shodné. U většiny bajtů z příznaků jsem nedokázal vypozorovat, co přesně značí. Posílání větších částí dat má jednu specifickou vlastnost, na jejíž důvod jsem nedokázal přijít: pokud je posíláno víc než 8 kB dat najednou, je po těchto 8 kB znovu poslána obdobná hlavička, jako je zobrazena na obr. 2.2. Navíc při 13
14
00
(a) Struktura požadavku na zjištění velikosti média.
Obrázek 2.1: Zprávy na velikost média
00
54
00
IDE-R odeslání informací
IDE-R příkaz
50
00
00
00
1B
08
02
00
00
00
00
Čítač
00
45
Příznaky
00
b5
00
1A
02
00
00
00
Typ odpověďi
b0
58
Příznaky
00
B0
A0
85
00
00
00
03
00
Velikost média
Celkem 26B příznaků mj. označující typ média
08
00
Čítač
00
00
ae
00
00
Příznaky
00 .. 00
00
00
00
b0
08
50
00
00 .. 00
Celkem 12B příznaků
25
Příznaky
Rozhodnutí jestli se jedná o FD nebo CD
08
Upřesnění typu požadavku
Požadavek na velikost disku
00
00
Typ požadavku
2. Implementace
(b) Struktura odpovědi na požadavek na zjištění velikosti média.
00
00
08
54
00
03
2D
00
b4
00
02
00
00
00
IDE-R odeslání informací
00
00
00
85
00
Příznaky
03
00
00
00
b0
50
00
Data z přesměrovaného média Velikost je určena požadavkem
Data
Celkem 26B příznaků mj. označující typ média
58
Čítač
b0
00
Typ odpověďi
00
00
00
00
00
2.2. IDE-R
Obrázek 2.2: Struktura zprávy s odesílanými daty.
15
16
00
IDE-R příkaz
50
00
00
00
00
00
Čítač
00
01
Příznaky
Požadavek na poslání dat
54
Typ požadavku
00
00
08
A0
A0
28
Velikost požadované části
45
00
00
10
Příznaky
Pozice požadované části dat
00
Pozice
Rozhodnutí jestli se jedná o FD nebo CD
00
Příznaky
A0 A0 značí FD, A0 B0 značí CD
Upřesnění typu požadavku
00
00
01
00
00
00
2. Implementace
Obrázek 2.3: Struktura požadavku na zaslání dat.
2.2. IDE-R těchto požadavcích musí být u poslední takto vložené hlavičky v příznacích uvedeno, kolik 256B bloků ještě zbývá k odeslání. Toto chování si vysvětluji univerzálností tohoto komunikačního protokolu. Výsledný program byl také zaintegrován do novabootu, pokud je novaboot spuštěn s parametrem --ider, je na začátku vygenerován bootovatelný iso image dle konfiguračního souboru. Následně je vygenerován prázdný image diskety, který je nutný pro přesměrování disketové i CD mechaniky. Následuje spuštění přesměrování v samostatném procesu pomocí příkazu fork, po spuštění IDE redirection je pokračováno stejně jako v případě použití pouze parametru --amt, což znamená spuštění programu amtterm a následně restartování testovaného počítače. Pro správnou funkčnost je nutné v programu BIOS nastavit primární bootovací zařízení na přesměrované CD.
17
Kapitola
Návod k použití V této kapitole stručně popíši návod na nastavení Intel AMT a používání programů novaboot a dalších utilit potřebných v mé práci.
3.1
Povolení SOL apod.
Pro podporu AMT je potřeba mít zapojenou paměť RAM v prvním slotu, obvykle se jedná o slot nejblíže k procesoru. Bez splnění této podmínky není možné používat AMT. Dále je nutné AMT nastavit, neboť se může nacházet ve třech různých stavech, viz obrázek 3.1. Výchozím stavem je Factory Mode. Z tohoto stavu je možné se dostat pomoci MEB-x (Management Engine BIOS Extension). K tomu, abychom se do MEB-x dostali, je nutné povolit AMT v setup programu BIOSu. Do MEB-x je možné se dostat pomocí klávesové zkratky Ctrl+P stisknuté v průběhu tzv. Power-On Self Testu (POST) při startu počítače, Výchozí heslo do MEB-x je „admin“a je potřeba ho změnit po prvním přihlášení. Heslo musí obsahovat alespoň 8 znaků, malé i velké písmeno, číslici i speciální znak. Uživatelské jméno je „admin“. V MEB-x lze
Obrázek 3.1: Stavy AMT [1] 19
3
3. Návod k použití
Obrázek 3.2: AMT MEBx
nastavit základní nástroje viz obrázek 3.2. V podnikových sítích existuje i možnost nastavení bez nutnosti fyzického přístupu k počítači, ale tato možnost je pro naše účely zbytečně komplikovaná, proto se budu zabývat počáteční konfigurací pouze přes MEB-x.
Dalším stavem je Setup Mode, což je stav, ve kterém je již možné AMT nakonfigurovat vzdáleně a nebo lokálně, a to i bez pomoci MEB-x. Plně nakonfigurovaný stav se nazývá Operational Mode. Pro účely mé bakalářské práce je potřeba povolit SOL, IDER a zakázat User consent (při povoleném User consent je nutný souhlas uživatele před každým připojením). Také je nutné v MEB-x správně nakonfigurovat síťové připojení. Power Policies je potřeba nastavit na: Desktop: ON in S0, ME Wake in S3, S4-5, aby bylo možné se připojit i na vypnutý počítač. Compatibility mode doporučuji vypnout, při jeho zapnutí se na testovacích strojích přerušovalo spojení při spuštění počítače. Dále je ještě potřeba nastavit ListenerEnabled na hodnotu true, což už nelze udělat přes MEB-x. Je možné to nastavit například přes Powershellový skript, který je přiložen na CD. Skript se jmenuje „amt_listener.ps1“, skript si po spuštění vyžádá hostname, uživatelské jméno a heslo a poté nastaví ListenedEnabled na true. Pro správnou funkčnost skriptu je potřeba mít nainstalovaný MEI driver [14]. 20
3.2. Flashování ME
Obrázek 3.3: AMT web server Základní správu je možné provádět i z prostředí web serveru, který běží na portu 16992, ukázka viz obrázek 3.3.
3.2
Flashování ME
Někdy může být z různých důvodů nutné aktualizovat firmware Intel ME. Tyto aktualizace mohou pomoci například při chybách MEB-x vzniklých buď uživatelskou chybou, nebo chybou v samotném AMT. Intel k ME vydává aktualizace, ale poskytuje je pouze svým partnerům, kteří s nimi mohou naložit dle svého uvážení, z velkých výrobců HW uveřejňuje tyto aktualizace ke stažení pouze Lenovo, například na AMT verze 6 jsou ke stažení zde [11]. Aktualizovat je možné z prostředí Windows nebo DOS, a to pouze lokálně. Není možné aktualizovat firmware na nižší verzi a také nelze atualizovat firmware na vyšší hlavní verzi, tedy například není možný update z AMT 5 na 6.
3.3
Použití novabootu
Typické použití novabootu spočívá ve vytvoření spustitelného novaboot skriptu, který bude mít na první řádce #!/usr/bin/env novaboot. Poté bude bootování různých operačních systémů na vzdáleném (nebo emulovaném) počítači stejné jako spouštění lokálních programů. Výchozí akce při spuštění novaboot skriptu je spuštění Qemu s konfigurací danou novaboot skriptem. Mezi další možnosti patří nahrání vytvořeného boot˜loaderu a všech dalších nutných souborů na server (parametr --server). Parametr --iprelay umožňuje použití relé řízeného přes TCP/IP k resetování a přesměrování sériové linky 21
3. Návod k použití testovaného počítače. V neposlední řadě je možné pomocí novabootu vytvořit bootovatelný iso image z novaboot skriptu pomocí přepínače --iso. Pro práci s AMT počítačem je určen parametr --amt, pro resetování počítače se používá WS-management a pro přesměrování vstupu/výstupu se používá SOL (Serial over LAN). Parametr --amt má formát: [user[:password]@]host[:port]. Výchozí hodnota pro user je „admin“, pokud není zadáno heslo, tak je použita hodnota proměnné prostředí AMT_PASSWORD. Pokud není stanoven port, je použit výchozí port pro SOL 16994. Pokud je použit parametr --amt, je možné použít i parametr --ider, který zapne přesměrování obrazů CD a FD na testovaný počítač. Autorizace je použita stejná jako pro parametr --amt, je potřeba zadat cestu k .img obrazu diskety a k .iso obrazu CD. Formát parametru je --ider "cesta k obrazu diskety.img""cesta k obrazu CD.iso". Ukázka výpisu programu novaboot při použití --amt i --ider: ./linux-test –amt sh.fanfule.cz –ider novaboot: Read /home/x/novaboot/.novaboot novaboot: Generating images. novaboot: Running: dd if=/dev/zero of=fd.img bs=512 count=200 200+0 vstoupivších záznamů 200+0 vystoupivších záznamů 102 400 bajtů (102 kB) zkopírováno, 0,00105603 s, 97,0 MB/s novaboot: Running: ./linux-test –iso ider.iso novaboot: Read /home/x/novaboot/.novaboot novaboot: Entering directory ‘/home/x/novaboot/examples’ novaboot: Created /home/x/novaboot/examples/SCALAR(0x9ed94ec) novaboot: Running: genisoimage -R -b stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -hide-rr-moved -J -joliet-long -o ider.iso -graft-points bin/boot/grub/ boot/grub/menu.lst=menu-iso.lst build/buildroot/images/bzImage=build/buildroot/images/bzImage build/buildroot/images/rootfs.cpio.gz=build/buildroot/images/ rootfs.cpio.gz I: -input-charset not specified, using utf-8 (detected in locale settings) Size of boot image is 4 sectors -> No emulation Total translation table size: 2048 Total rockridge attributes bytes: 1723 Total directory bytes: 11092 Path table size(bytes): 78 Max brk space used 0 22
3.3. Použití novabootu 3327 extents written (6 MB) ISO image created: /home/x/novaboot/examples/ider.iso novaboot: Running: amtterm -u admin -p ??? sh.fanfule.cz 16994 novaboot: Running: ider -f fd.img -c ider.iso -u admin -p ??? sh.fanfule.cz 16994 ider: NONE -> CONNECT (connection to host) amtterm: NONE -> CONNECT (connection to host) ipv4 sh.fanfule.cz [147.32.125.228] 16994 open redir start ider: CONNECT -> INIT (redirection initialization) ider: INIT -> AUTH (session authentication) ider: AUTH -> INIT_IDER (IDE redirect initialization) ider: INIT_IDER -> IDER_ENABLE_FEATURES (enable IDE-R features) ider: IDER_ENABLE_FEATURES -> IDER_ENABLE_FEATURES enable IDE-R of CD and FD) ider: IDER_ENABLE_FEATURES -> RUN_IDER (IDE redirect active) ipv4 sh.fanfule.cz [147.32.125.228] 16994 open amtterm: CONNECT -> INIT (redirection initialization) amtterm: INIT -> AUTH (session authentication) amtterm: AUTH -> INIT_SOL (serial-over-lan initialization) amtterm: INIT_SOL -> RUN_SOL (serial-over-lan active) serial-over-lan redirection ok connected now, use ˆ ] to escape novaboot: Entering directory ‘/home/x/novaboot/examples’ novaboot: Reseting the test box... done novaboot: Serial line interaction (press Ctrl-C to interrupt)... The system is powered off. The system is powered on. Warning, SOL device is running in loopback mode. Text input may not be accepted SOL device is no longer running in loopback mode [ 1.220602] 0000:00:16.3: ttyS2 at I/O 0xf0e0 (irq = 19) is a 16550A ... Welcome to Buildroot buildroot login:
23
Kapitola
Testování 4.1
Použité počítače
V tabulkách 4.1, 4.2 , 4.3 a 4.4 je možné vidět hardwarové specifikace počítačů použitých při testování, 1. testovací počítač (dále bude nazýván také Gigabyte) je můj osobní , na kterém probíhal hlavní vývoj, 2. testovací počítač (ASUS) mi zpřístupnil pro testování můj vedoucí , 3. (Lenovo) a 4. testovací počítač (Dell) jsem měl krátce zapůjčen. Počítač Dell sice podporoval AMT, ale bylo na tomto počítači od výrobce nenávratně zakázáno [2], zprovoznění AMT by pravděpodobně vyžadovalo výměnu základní desky, nebo minimálně servisní zásah technika Dellu, z toho důvodu jsem tento počítač nemohl použít pro testování. Níže tedy budu uváTabulka 4.1: Specifikace prvního testovacího počítače Gigabyte Procesor RAM Chipset Základní deska Verze BIOSu Verze ME
Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz 8GB DDR3 Q87 Gigabyte Q87M-D2H F4 9.0.31
Tabulka 4.2: Specifikace druhého testovacího počítače ASUS Procesor RAM Chipset Základní deska Verze BIOSu Verze ME
Intel(R) Core(TM) i5 CPU 661 @ 3.33GHz 4GB DDR3 Q57 ASUS P7Q57-M DO 1103 6.2.20 25
4
4. Testování Tabulka 4.3: Specifikace třetího testovacího počítače Lenovo Procesor RAM Chipset Základní deska Verze BIOSu Verze ME
Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz 2GB DDR3 Q67 Lenovo 9HK147AUS 7.1.3
Tabulka 4.4: Specifikace čtvrtého testovacího počítače Dell Procesor RAM Chipset Základní deska Verze BIOSu Verze ME
Intel(R) Core(TM) Core 2 Duo Processor E8400 @ 3GHz 1GB DDR2 Q45 / Q43 Dell 0C27VV Dell-15 nezjištěno
dět pouze zbylé 3 testovací počítače. Každý z testovacích počítačů je postaven na jiném chipsetu s jinou verzí AMT. Díky tomu jsem mohl vyzkoušet odlišnosti mezi různými verzemi AMT. Například testovací počítač Gigabyte jako jediný nepodporuje SOAP protokol, ale oproti ostatním podporuje měkké vypnutí počítače.
4.2
Výsledky
Na testovacích počítačích se mi podařilo plně zprovoznit power control a SOL, jediný problém, na který jsem narazil, byla potřeba zapnout ListenerEnabled, což nebylo úplně triviální odhalit. IDE-R byl mnohem více problematický, i přesto se mi ale podařilo napsat funkční program na přesměrování obrazů medií, který fungoval na všech testovacích počítačích. Na prvním a na třetím počítači se mi podařilo i nabootovat z přesměrovaného obrazu, na 2. počítači, pravděpodobně kvůli omezení AMT, není možné zvolit bootování z přesměrovaného média. Protože jsem IDE-R implementoval na základě odposlouchávání síťové komunikace pomocí Wiresharku a snažil jsem se zreplikovat tuto komunikaci a protože AMT posílá několik desítek různých požadavků, nemohu zaručit, že na některých počítačích nebo v některých situacích AMT nepošle požadavek, který se ve sledované komunikaci neobjevil, a IDE-R tudíž nebude fungovat korektně. Zaměřil jsem se především na bootování a přesměrování CD, takže není otestované bootování z přesměrované diskety, ale načtení dat z diskety bylo funkční na všech testovacích počítačích. Přesměrování DVD je podpo26
4.2. Výsledky rováno, ale nedá se očekávat, že by bylo potřeba, z toho důvodu jsem ho neimplementoval. U některých požadavky, které AMT posílá, se mi nepodařilo zjistit, co přesně znamenají, proto na ně odpovídám stejnou zprávou jako odpovídá ukázkový program z SDK, nicméně neobjevil jsem žádný případ, kdy by se to ukázalo jako újma na obecnosti.
27
Závěr V uvodní, teoretické části jsem popsal technologii Intel AMT. Zejména se zaměřuji na části, které mohou být použity při testování low-level softwaru. Mezi tyto části patří Serial over LAN, IDE redirection a vzdálené ovládání stavu napájení. V teoretické části jsou zmíněny také konkurenční technologie IPMI a OPMA. Byla provedena integrace nástroje amtterm do nástroje novaboot, amtterm slouží pro Serial over LAN. Dále bylo implementováno ovládání stavu napájení a jeho integraci do novabootu. V poslední části bylo implementováno IDE redirection, přesměrování CD nebo FD mechaniky na vzdálený počítač. V původním zadání bylo i použití technologie IPMI. Kvůli podstatně vyšší náročnosti IDE redirection než bylo očekáváno (bylo nutné metodami zpětného inženýrství prozkoumat a naimplementovat nezdokumentovaný protokol pro IDE redirection) bylo rozhodnuto, že se v této práci budu věnovat pouze technologii AMT. IPMI jsem zkoumal pouze z teoretického hlediska. Podařilo se mi plně zprovoznit AMT a implementovat IDE redirection, Serial over LAN i řízení stavu napájení pro účely testování low-level softwaru. Na jednom z testovacích počítačů (ASUS) nebylo možné nabootovat z přesměrované mechaniky, zřejmě z důvodu omezení AMT, na počítači Lenovo bylo AMT zcela zakázáno a nebylo možné jej povolit. Na zbývajících dvou počítačích se mi podařilo restartovat dotyčný počítač, nabootovat na něm z přesměrovaného CD a poté přijímat obsah přesměrované sériové linky i odesílat obsah na sériovou linku. Tato funkčnost byla integrována do nástroje novaboot, čímž se novaboot stal plně použitelný bez využití specializovaného hardwaru, postačí pouze běžný stolní počítač na platformě Intel s vhodnou základní deskou. Zdrojové kódy je možné nalézt v mých repozitářích na githubu [5] a [4] nebo na přiloženém CD. 29
Závěr Všechny zde předvedené technologie se ukázaly být velmi mocným nástrojem ať už při využití pro testování low-level softwaru, jako tomu bylo v tomto případě, tak například při využití při správě sítě.
30
Literatura [1]
R Dell: Intel Active Management Technology – Start Here Guide [online]. [cit. 2014-04-19]. Dostupné z: https:// software.intel.com/sites/default/files/m/2/1/f/f/a/43527Intel_AMT8_Start_Here_Guide.pdf
[2]
Dell: Manageability Mode Options on Replacement System Boards for the DellTM OptiPlexTM 755 – KB Article – 327359 | Dell US [online]. [cit. 2014-04-18]. Dostupné z: http://www.dell.com/support/ troubleshooting/us/en/04/KCS/KcsArticles/ArticleView?c=us&l= en&s=bsd&docid=DSN_36400464FB593B86E040A68F5B284972
[3]
DMTF: Web Services Management [online]. [cit. 2014-05-09]. Dostupné z: http://www.dmtf.org/standards/wsman
[4]
R AMT SoL client + IDE-R client + tools [online]. [cit. Fanfule, V.: Intel 2014-05-13]. Dostupné z: https://github.com/fanfuvac/amtterm
[5]
Fanfule, V.: novaboot – A tool for booting various operating systems on various hardware or in qemu [online]. [cit. 2014-05-13]. Dostupné z: https://github.com/fanfuvac/novaboot
[6]
Franks, J.; Hallam-Baker, P.; Hostetler, J.; aj.: HTTP Authentication: Basic and Digest Access Authentication. RFC 2617 (Draft Standard), Červen 1999. Dostupné z: http://www.ietf.org/rfc/rfc2617.txt
[7]
R SoL client + tools [online]. [cit. 2014-05-11]. Hoffmann, G.: Intel AMT Dostupné z: https://www.kraxel.org/cgit/amtterm/
[8]
R Intel: Download the latest Intel AMT Software Development Kit (SDK) [online]. [cit. 2014-04-18]. Dostupné z: https: //software.intel.com/en-us/articles/download-the-latestintel-amt-software-development-kit-sdk
31
Literatura [9]
Intel: Intelligent Platform Management Interface Specification Second Generation v2.0 [online]. [cit. 2014-05-11]. Dostupné z: http://www.intel.com/content/dam/www/public/us/en/documents/ product-briefs/second-gen-interface-spec-v2-rev1-4.pdf
R AMT SDK Implementation and Reference Guide [on[10] Intel: Intel line]. [cit. 2014-04-18]. Dostupné z: https://software.intel.com/ sites/manageability/AMT_Implementation_and_Reference_Guide/ default.htm R Management Engine Firmware Update Tool (version 6.2.20.1035) [11] Intel [online]. [cit. 2014-05-06]. Dostupné z: http://support.lenovo.com/ en_US/downloads/detail.page?DocID=DS022364 R vProTM Technology [online]. [cit. 2014-05-10]. Dostupné z: [12] Intel http://www.intel.com/content/www/us/en/architecture-andtechnology/vpro/vpro-technology-general.html R AMT: WSMAN Interface is replacing the SOAP(EOI) Interface [13] Intel [online]. [cit. 2014-04-18]. Dostupné z: https://software.intel.com/enus/blogs/2012/12/01/intel-amt-wsman-interface-is-replacingthe-soapeoi-interface R [14] Intel ME: Management Engine Driver [online]. [cit. 201405-06]. Dostupné z: https://downloadcenter.intel.com/ Detail_Desc.aspx?DwnldID=22596 R Q87 Chipset Platform Diagram [online]. [cit. 2014-05-10]. [15] Intel Dostupné z: http://www.intel.com/content/www/us/en/chipsets/ business-chipsets/q87-chipset-diagram.html
[16] OpenWSMAN: OpenWSMAN – WS-Management for all [online]. [cit. 2014-04-28]. Dostupné z: http://openwsman.github.io/ [17] Reynolds, J.; Postel, J.: AT Attachment 8 – ATA/ATAPI Command Set (ATA8-ACS) [online]. Dostupné z: http://www.t13.org/documents/ UploadedDocuments/docs2006/D1699r3f-ATA8-ACS.pdf [18] Reynolds, J.; Postel, J.: Assigned Numbers. RFC 1700 (Historic), Říjen 1994, obsoleted by RFC 3232. Dostupné z: http://www.ietf.org/rfc/ rfc1700.txt [19] Skochinsky, I.: Rootkit in your laptop [online]. [cit. 2014-05-09]. Dostupné z: https://www.yumpu.com/en/document/view/23134299/breakpoint2012-skochinsky 32
Literatura [20] Sojka, M.: novaboot – A tool for booting various operating systems on various hardware or in qemu [online]. [cit. 2014-05-11]. Dostupné z: https://github.com/wentasah/novaboot/ [21] Ubuntu: Ubuntu Manpage: wsl – A shell based command line client for WSMAN servers [online]. [cit. 2014-04-28]. Dostupné z: http:// manpages.ubuntu.com/manpages/saucy/man1/wsl.1.html [22] W3C: Simple Object Access Protocol [online]. [cit. 2014-05-09]. Dostupné z: http://www.w3.org/TR/soap12-part1/
33
Příloha
Seznam použitých zkratek AMT Active manegement technology IDE-R IDE redirection IPMI Intelligent Platform Management Interface ME Management engine MEB-x Management engine BIOS extension OPMA Open Platform Management Architecture POST Power-On Self Test SOAP Simple Object Access Protocol SOL Serial over LAN XML Extensible markup language
35
A
Příloha
Obsah přiloženého CD
readme.txt...................................stručný popis obsahu CD src impl...................................zdrojové kódy implementace thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce thesis.pdf ............................. text práce ve formátu PDF 37
B
