Jaderné noviny – 2. 1. 2014: Nový hypervizor Jailhouse

20. 1. 2014 | Luboš Doležel | Jaderné noviny | 4085×

Aktuální verze jádra: 3.13-rc6. Citáty týdne: Alan Cox, Ian Jackson, David Miller. Žádná nová .bz2 na kernel.org. Hypervizor Jailhouse.

Obsah

• Aktuální verze jádra: 3.13-rc6
• Citáty týdne: Alan Cox, Ian Jackson, David Miller
• Žádná nová .bz2 na kernel.org
• Hypervizor Jailhouse
  • Datové struktury
  • Povolujeme Jailhouse
  • Inicializace CPU

Aktuální verze jádra: 3.13-rc6

Aktuální vývojová verze jádra je 3.13-rc6, vydaná 29. prosince. Ještě před tím vyšla verze 3.13-rc5, a to 22. prosince. Teď je vhodná chvíle na to, abych řekl, že i kdyby se věci uklidnily, tak stejně bude alespoň -rc8, jelikož LCA je letos docela brzy a já nebudu otevírat začleňovací okno 3.14, než se vrátím z cest.

Stabilní aktualizace: verze 3.12.6, 3.10.25 a 3.4.75 vyšly 20. prosince.

Citáty týdne: Alan Cox, Ian Jackson, David Miller

Pokud nemáte ke svému firmwaru kompletní zdrojové kódy, pak nemáte systém, kterému můžete věřit.

-- Alan Cox

Možná, že naše existující nelinuxové porty nejsou moc používané, dostatečně udržované nebo nemají produkční kvalitu. Ale myslím si, že je důležité si tyto možnosti ponechat. To samozřejmě dává lidem prostor, aby na nich pracovali a používali je, ale hlavně to ponechává Debianu do budoucna otevřená vrátka. A konkurence pomáhá Linuxu v tom, aby byl nadále slušným systémem, což je důležité, protože Linux je v podstatě neforknutelný, jsou s ním špatné zkušenosti co do reakcí na obavy jeho uživatelů a má skoro nepoužitelnou hierarchii řízení.

-- Ian Jackson

A i když to ve výchozím stavu vypneme, někdo začne křičet a poví distribucím, aby to u nich zapnuli v /etc/sysctl.conf, jako se to stalo u rp_filter. A oni to zapnou. Nemám sílu a čas bojovat s každým, kdo taková rozhodnutí ve velkých distribucích dělá, a vysvětlovat každému z nich, jak hloupé to je.

Žádný koncový hostitel by neměl mít zapnuté rp_filter. Zbytečně to značně komplikuje vyhledávání ve směrovací tabulce a na koncových hostitelích to nemá žádné výhody. Ale lidé přesvědčili distribuce, že zapnutí ve výchozím nastavením je správná věc, a ujalo se to.

-- David Miller

Žádná nová .bz2 na kernel.org

Administrátoři kernel.org oznámili, že už nebudou do archivu přidávat další soubory komprimované pomocí bzip2, ačkoliv stávající soubory budou dále dostupné. Od nynějška budou všechny patche a tarbally stejně jako další soubory nesouvisející s jádrem komprimované gzipem nebo xz.

Hypervizor Jailhouse

Jailhouse je nový hypervizor určený k fungování s Linuxem a k běhu aplikací přímo na hardwaru (bare-metal) nebo k běhu upravených hostovaných systémů. Navzdory této spolupráci je Jailhouse samostatný a Linux používá jen ke spuštění a ke své (pozdější) správě. Hypervizor je svobodným softwarem od Siemensu vydaným pod GPLv2; projekt byl veřejně ohlášen v listopadu 2013 a je v ranném stádiu vývoje. Aktuálně podporuje jen 64bitové systémy x86; v plánu je ale i podpora ARM a vzhledem k přenositelnosti kódu můžeme časem vidět i další architektury.

Linux má mnoho plnohodnotných hypervizorů (jako KVM a Xen), tak proč se obtěžovat s dalším? Jailhouse je jiný. Především jde o „partitioning“ hypervizor, který se více zabývá izolací než virtualizací. Jailhouse je lehkotonážní a nenabízí řadu funkcí, které byste od virtualizačních systémů očekávali. Například nemá žádnou podporu pro overcommitment (přehnané slibování) prostředků, hosté nemohou sdílet CPU, jelikož tam není žádný plánovač, a Jailhouse nemůže emulovat zařízení, která nemáte.

Namísto toho Jailhouse umožňuje asymetrický multiprocesing (AMP) nad stávajícím systémem s Linuxem a rozděluje systém do izolovaných částí nazvaných „buňky“. V každé buňce běží jeden host a má svou sadu přidělených prostředků (CPU, oblasti paměti, zařízení PCI), které plně ovládá. Hypervizor má za úkol spravovat buňky a udržovat jejich vzájemnou izolaci. Tento přístup je nejužitečnější pro virtualizaci věcí, jež vyžadují plnou kontrolu nad CPU; mezi takové věci patří řízení v reálném čase nebo dlouhoběžící výpočetní kód (HPC). Mimo to má i bezpečnostní využití: například pro vytváření sandboxů.

Běžící systém s Jailhouse má alespoň jednu buňku známou jako „linuxová buňka“. Obsahuje linuxový systém použitý k počátečnímu spuštění hypervizoru a k jeho dalšímu řízení. Smysl této buňky se podobá dom0 v Xenu. Linuxová buňka ale nemá plnou kontrolu nad hardwarovými prostředky jako dom0; při vytváření nové buňky linuxová buňka předá kontrolu nad částí CPU, zařízeními a paměťovými prostředky nové buňce. Tomuto procesu se říká „zmenšování“ (shrinking).

Jailhouse závisí na hardwarové virtualizaci poskytované cílovou architekturou; na procesorech Intel (jen ty jsou teď podporované) jde o VT-x a VT-d. Díky těmto požadavkům má hypervizor čistý návrh, jeho kód je kompaktní a poměrně jednoduchý; cílem je udržet Jailhouse pod 10 000 řádek kódu. Obvykle bývaly hypervizory buď velké a komplexní, nebo schválně jednoduché, pokud byly stavěny jen na ukázku. Jailhouse je někde mezi tím: jde o skutečný produkt zacílený na produkční nasazení a současně je dostatečně jednoduchý na to, aby bylo možné ho popsat ve dvou článcích.

Nejsnazším způsobem, jak si teď pohrát s Jailhouse, je spustit jej v KVM s jednoduchou bare-metal aplikací apic-demo.bin (dodáváno spolu se zdrojovým kódem Jailhouse) jako hostem. V tomto případě se VT-d nepoužívá, protože jej KVM (zatím) neumí emulovat. README detailně popisuje, jak toto nakonfigurovat; pomoc naleznete na mailing listech.

Jailhouse je možné spustit i na skutečném hardwaru, ale aktuálně to není tak jednoduché. Musíte popsat Jailhousu prostředky, co má k dispozici; začít se dá s /proc/iomem na vašem linuxovém systému. Toto je proces náchylný na chyby, ale snad díky tomuto článku dostatečně pochopíte, jak Jailhouse funguje, abyste jej dokázali rozjet na libovolném hardwaru.

Dobrý úvod do Jailhousu (včetně slajdů) najdete v počátečním oznámení. Nebudeme to tady opakovat a raději se hned podíváme na vnitřnosti hypervizoru.

Datové struktury

Než Jailhouse může rozdělit skutečný systém, tak se musí dozvědět, z čeho se tento systém sestává. Na to Jailhouse používá struct jailhouse_system (definované v cell-config.h) jako popisovač systému, na kterém běží. Tato struktura obsahuje tři pole:

• hypervisor_memory, které definuje umístění Jailhouse v paměti.
• config_memory, které ukazuje na oblast, kde je uložná hardwarová konfigurace (na x86 jde o tabulky ACPI).
• system je popisovač buňky, který nastaví počáteční linuxovou buňku.

Popisovač buňky má na začátku struct jailhouse_cell_desc, které je rovněž definované v cell-config.h. Tato struktura obsahuje základní informace jako název buňky, velikost sady jeho CPU, počet oblastí paměti, linky IRQ a zařízení PCI. Se struct jailhouse_cell_desc se pojí několik polí o proměnné délce, která ji v paměti hned následují. Jde o:

• Bitmapu s CPU dané buňky.
• Pole, které ukládá fyzické adresy, fyzické adresy hosta (virt_start), velikost a příznaky pro přístup k oblastem paměti buňky.
• Pole, které popisuje IRQ linky buňky. Nyní se nepoužívá a v budoucnu může být odstraněno.
• I/O bitmapa, která řídí, které I/O porty jsou z buňky dostupné (nastavení bitu znamená zakázání přístupu). Toto se týká jen x86.
• Pole, které mapuje zařízení PCI na domény VT-d.

Jailhouse aktuálně nemá žádné konfigurační soubory. Místo toho se výše uvedené struktury kompilují pomocí příznaku -O binary v objcopy, aby byly vyrobeny surové binárky místo objektů ELF a nástroj jailhouse (vizte tools/jailhouse.c) je v této podobě načte do paměti. Vytváření popisovačů je pracná záležitost, ke které je nutná rozsáhlá znalost hardwarové architektury. Mimo základní validaci neprobíhají žádné kontroly, takže můžete snadno vytvořit cosi nepoužitelného. Nic Jailhousu nebrání v tom, aby v budoucnu používal XML nebo textové konfigurační soubory – jen to ještě není implementované.

Další častou datovou strukturou je struct per_cpu, které je specifická pro architekturu a pro x86 je definovaná v x86/include/asm/percpu.h. Popisuje CPU přiřazené k buňce. V rámci tohoto textu se na ni budeme odkazovat jako na cpu_data. Pro každý procesor, který Jailhouse spravuje, existuje jedna taková struktura a je uložená v paměťové oblasti nazvané per_cpu. cpu_data obsahuje informace jako logický identifikátor CPU (pole cpu_id), identifikátor APIC (apic_id), zásobník hypervizoru (stack[PAGE_SIZE]), zpětný odkaz na buňku, do které toto CPU patří (cell), a režim CPU (stojící, čekající na SIPI apod.) Obsahuje také oblasti VMXON a VMCS potřebné pro VT-x.

No a konečně tu pak máme struct jailhouse_header definované v header.h, které popisuje hypervizor jako celek. Nachází se na úplném začátku binárního obrazu hypervizoru a obsahuje informace jako počáteční adresu hypervizoru (entry point), jeho velikost paměti, offset stránek a počet možných/online CPU. Některá pole v této struktuře mají statické hodnoty, zatímco jiné jsou nastaveny při spuštění Jailhouse.

Povolujeme Jailhouse

Jailhouse pracuje v souvislé oblasti paměti. Aktuálně je nutné tuto oblast vyhradit při bootu pomocí parametru jádra memmap=; v budoucnu místo toho možná bude používán alokátor souvislé paměti (CMA). Jakmile povolíte Jailhouse, tak zavaděč (loader) lineárně namapuje tuto paměť do virtuálního adresního prostoru jádra. Jeho offset od počáteční adresy paměťové oblasti je uložený v poli page_offset v hlavičce. Díky tomuto je převod mezi virtuálními adresami hosta a fyzickými adresami triviální.

Aby byl hypervizor povolený, Jailhouse musí inicializovat své subsystémy, vytvořit linuxovou buňku podle nastavení systému, povolit VT-x na každém CPU a přesunout Linux do jeho vlastní buňky, aby dále běžel v režimu hosta. Od této chvíle má hypervizor plnou kontrolu nad prostředky systému. Jailhouse nepotřebuje Linux k tomu, aby hostům poskytoval služby. Linux je používán jen pro inicializaci hypervizoru a jeho pozdější ovládání. Pro tyto účely nástroj jailhouse provádí ioctl() nad /dev/jailhouse. Modul jailhouse.ko (zavaděč) zkompilovaný z main.c tento uzel zařízení registruje při svém načtení do jádra.

Aby byl zahájen výše popsaný sled událostí, tak nástroj jailhouse pošle povel JAILHOUSE_ENABLE přes ioctl(). Dojde k načtení kódu hypervisoru do vyhrazené paměti pomocí volání request_firmware(). Pak dojde k namapování vyhrazené paměti a tak dále. Nakonec je zavoláno enter_hypervisor() na každém z CPU a čeká se na návrat z této funkce. Pak se dá Jailhouse považovat za spuštěný.

enter_hypervisor() je jen tenké obalení, které skočí na počáteční adresu (entry point) dle hlavičky – entry point sídlí v x86/entry.S. Chová se jinak u prvního inicializovaného CPU a u zbytku. První CPU je nazváno „master“; je zodpovědné za celkovou inicializaci systému. Nastaví stránkování, namapuje config_memory, pokud je přítomno, ověří paměťové oblasti definované v popisovači linuxové buňky a jejich zarovnání a přístupové příznaky, inicializuje APIC, vytvoří IDT pro Jailhouse, nastaví přístup hosta k x2APIC a inicializuje linuxovou buňku. CPU, která nejsou „master“, obvykle jen inicializují sebe sama.

Inicializace CPU

Inicializace CPU je dlouhý proces, který začíná funkcí cpu_init(). Nejprve je CPU zaregistrováno jako „linuxové CPU“: jeho ID je ověřeno a pokud je součástí systémové sady CPU, tak je přidáno do linuxové buňky. Zbytek postupu je platformně závislý a pokračuje v arch_cpu_init(). Na x86 jsou uloženy aktuální hodnoty registrů ve struktuře cpu_data. Tyto hodnoty budou obnoveny při prvním vstupu do VM. Pak Jailhouse zamění hodnoty v IDT, GDT a CR3 (ukazatel na adresář stránek).

Nakonec arch_cpu_init() nastaví pole cpu_data->apic_id a nastaví rozšíření VMX na CPU. To probíhá ve vmx_cpu_init(), které nejprve ověří, zda CPU poskytuje všechny požadované funkce. Pak připraví řídící strukturu virtuálního stroje (VMCS), která je v cpu_data, a povolí CMX na CPU. Oblast VMCS je konfigurována ve vmcs_setup(), aby při každém vstupu nebo opuštění VM:

• Host (jailhouse) získá příslušné hodnoty řídících a segmentačních registrů. Odpovídající pole VMCS jsou okopírována z hardwarových registrů v arch_cpu_init(). Bity LMA a LME jsou nastaveny v hostově IA32_EFER MSR, což znamená, že procesor je ve 64bitovém režimu, a ukazatel zásobníku je nastaven na konec cpu_data->stack (nezapomeňte, že zásobník roste směrem dolů). Registr RIP hosta je nastaven na vm_exit() definované v x86/entry.S a přerušení jsou zakázána v hostově RFLAGS. Díky tomu jsou při každém opuštění VM přerušení zakázána a řízení je následně na předávací funkci, která prověří důvod ukončení a podle toho zareaguje. MSR pro SYSENTER jsou vyčištěny, jelikož Jailhouse nemá žádné aplikace v uživatelském prostoru, nemá žádná systémová volání a jeho hosté pro přepnutí na hypervisora používají jiné způsoby.
• Host obdrží své řídící a segmentační registry z cpu_data->linux_*. RSP a RIP jsou vzaty z rámce na zásobníku jádra (stack frame) vytvářeného pro volání arch_entry(). Díky tomu při vstupu do VM bude linuxový kód pokračovat, jako kdyby volání entry() v hypervisor_enter() už skončilo; takto je jádro transparentně přesunuto do buňky. IA32_EFER MSR je také nastaven na svou linuxovou hodnotu, aby byl 64bitový režim při vstupu do VM zapnut. Ostatní buňky svá CPU vyresetují hned po inicializaci, čímž přepíší hodnoty, které tam jsou.

Po inicializaci všech CPU entry() zavolá arch_cpu_activate_vmm(). Z tohoto místa není návratu: RAX je nastaveno na nulu, načtou se všechny zbylé obecné registry a vyvolá se instrukce VMLAUNCH pro vstup do hosta. Díky dříve popsanému nastavení registrů hosta a jelikož RAX (které ukládá návratovou hodnotu) je nulové, Linux považuje volání entry() za úspěšné a pokračuje dál jako host.

Konec první části.

       

Komentáře

[petr_p]

Loader se tradičně překládá jako zavaděč.

[Luboš Doležel (Doli)]

Pravda, nějak jsem si nemohl vzpomenout na to správné slovo.

[Michal Kubeček]

No end host should have rp_filter on. It unnecessarily makes our routing lookups much more expensive for zero gain on an end host. But people convinced the distributions that turning it on everywhere by default was a good idea and it stuck.

…a i na routerech to nezřídka nadělá víc škody než užitku.

[Sten]

Na multi-homed a default-free routerech to je nepoužitelné, ale na ostatních je reverse-path filter docela užitečný.

Ale mám dojem, že hlavní důvod je, že reverse-path filter by měl řešit firewall a ne síťový subsystém. Firewall totiž kromě jiného funguje na pakety s IPSec nebo IPv6 a umí logovat.

[Jendа]

ale na ostatních je reverse-path filter docela užitečný

Nějak mě nenapadá moc případů, kde by se to hodilo (a nešly by snadněji řešit obyčejným firewallem, jako např. filtrace paketů zvenku do sítě za maškarádou). Nápady?

[Sten]

Nějak mě nenapadá moc případů, kde by se to hodilo (a nešly by snadněji řešit obyčejným firewallem, jako např. filtrace paketů zvenku do sítě za maškarádou). Nápady?

Třeba že to rozdělení sítí je uvedeno jenom jednou? I firewall umí používat reverse-path filter.

[Ondrej 'SanTiago' Zajicek]

Na multi-homed a default-free routerech to je nepoužitelné, ale na ostatních je reverse-path filter docela užitečný.

Reverse-path filtering muze zlobit i u vnitrniho routeru v podnikove siti ci siti ISP, pokud tam jsou redundandni cesty (ostatni routery mohou zvolit cestu k tobe jinou, nez ty volis cestu k nim).

Obecne je tu ale problem - zatimco routovaci tabulka urcuje kam maji jit pakety (a bez ECMP typicky jen jeden z moznych smeru), u reverse path filtering by takova tabulka mela specifikovat odkud *mohou* ci *smeji* prijit ty pakety.

Ale mám dojem, že hlavní důvod je, že reverse-path filter by měl řešit firewall a ne síťový subsystém.

Ono je otazka, co z toho je efektivnejsi, pokud bys takovych pravidel mel treba pul milionu. Routovaci tabulka s takovou zatezi pocita.

[Sten]

Ono je otazka, co z toho je efektivnejsi, pokud bys takovych pravidel mel treba pul milionu. Routovaci tabulka s takovou zatezi pocita.

No vzhledem k tomu, že iptables používají routovací tabulku (pro -t rpfilter), tak je to celkem jedno.

[asdacsac]

"Pokud nemáte ke svému firmwaru kompletní zdrojové kódy, pak nemáte systém, kterému můžete věřit."

Ked ste si HW nevyrobili sami, tak nemate system, ktoremu mozete verit (http://people.umass.edu/gbecker/BeckerChes13.pdf)

[Bystroushaak]

Ked ste si HW nevyrobili sami, tak nemate system, ktoremu mozete verit

Pokud jste si sami nevyrobili HW, kterým vyrábíte váš HW, tak nemáte systém, kterému můžete věřit. Goto 1.

[Michal Kubeček]

A i pak je stejně ještě potřeba zkusit roztočit setrvačník (*) a pro jistotu dávat pozor i na deja vu (*). :-)

[Mti.]

Jak moc se da verit pazourkovemu kamenomlatu? At vim, jak daleko musim zajit, nez se do toho pustim.

[student]

"Backdoornuty pazourek :D"

[frr]

Ten citát od Iana Jacksona se týká volby defaultního "init" démona pro Debian Jessie (systemd vs. upstart), tzn. "naše nelinuxové porty" mluvi o Debianu s kernelem jiným než linuxovým (Hurd, BSD). A výraz "honest system" bych přeložil spíš jako systém čestný nebo poctivý. Já vím, je tu pár lidí, kterým tohle pozadí dojde (na rozdíl ode mne), aniž by četli celý ten mail...