AbcLinuxu:/ Články / Jaderné noviny 265

Štítky: boot, C, CVS, distribuce, fdisk, Fedora, GCC, HTML, IDE, instalace, kernel, kompilace, LiLo, Linux, Microsoft, myš, parted, patch, programování, rozdělení disků, RPM, řadiče, SCSI, software, udev, urpmi, Version Control System, web, Windows

Jaderné noviny 265

7. 7. 2004 | Robert Krátký | Jaderné noviny | 5617×

Jak funguje geometrie disků v 2.4 a 2.6. Správcovství SysFS. Bezpečnostní 'NX' funkce v 2.6. Zdokonalení obsluhy tlačítek myši v mousedev. Podpora binárek SCO v Linuxu.

Do konference přišlo celkem 2035 emailů, nejvíce jich poslali Vojtěch Pavlík, Andrew Morton a Paul Jackson.

Jak funguje geometrie disků v 2.4 a 2.6, 33 e-mailů

30. kvě - 3. črv

Jeff Garzik napsal:

Vypadá to, že kód starající se ve 2.6 o geometrii znemožňuje duální bootování, protože Windows požadují "rozumné" hodnoty CHS. Viz slashdot a http://www.redhat.com/archives/fedora-devel-list/2004-May/msg00908.html.

Ačkoliv se to teď svádí na Fedora Core, řekl bych, že je to spíše problém 2.6.x kernelu.

Nepokusil se někdo dohledat csety, které způsobují takhle vážné narušení tabulky oddílů? Pokud ano, ušetřilo by mi to čas, kdy bych se po tom musel pídit.

Andries Brouwer řekl, že ta diskuze na slashdotu se týká pouze problémů v uživatelském prostoru, a že fdisk, kterého je Andries správcem, funguje bezvadně. K tomu dodal: O geometrii disků a o situaci v 2.4 i 2.6 ti mohu povědět do detailů. Jeff o ty detaily požádal a Andries odpověděl:

O těchto věcech už jsem napsal několik mnohostránkových textů. Viz např.: http://www.win.tue.nl/~aeb/linux/Large-Disk.html.

Pokus o krátké shrnutí:

Hardware:

V dávných dobách měly disky (MFM nebo RLL) geometrii popisující, kolik sektorů na stopu, kolik stop (cylindrů) a kolik hlav ta věc má.

S příchodem IDE už neplatilo, že by disk měl pevně stanovenou geometrii: ATA příkaz INITIALIZE DRIVE PARAMETERS disku dnes řekne, jakou geometrii by měl mít.

Na IDE disk může být přistupováno buď v CHS nebo LBA režimu a geometrie určená nebo načtená pomocí ATA příkazu IDENTIFY definuje význam příkazu CHS. U LBA přístupu nehraje geometrie žádnou roli.

SCSI disky nikdy žádnou praštěnou geometrii neměly.

Linux používá LBA a nemusí se o geometrii starat.
DOS / Windows:

Diskové rozhraní v DOSu používalo CHS. Používá-li disk LBA, ovladač musí CHS konvertovat na LBA, a proto potřebuje geometrii (alespoň H, S).

Protože DOS (BIOS INT 13) měl 10 bitů pro C a 6 bitů pro S, zatímco ATA používá 4 bity pro H, mohlo takové schéma adresovat pouze o něco méně než 2^20 sektorů. Limit 528 MB.

Byly vymyšleny nejrůznější druhy převodních schémat proto, aby daly rozhraní BIOSu jinou geometrii než jakou používalo ATA rozhraní. Uživatel si převodní schéma zvolí v nastavení BIOSu. Geometrie už není svázána s diskem, ale BIOS ji zná.

Existuje množství volání BIOSu, která hlásí různé verze geometrie.
Tabulky oddílů:

DOSová tabulka oddílů (viz např.: http://www.win.tue.nl/~aeb/partitions/partition_tables.html) udává umístění oddílů dvěma způsoby. Jeden způsob je ten, který používá Linux (počáteční sektor a délka, obojí ve 32 bitech). Ten druhý používá DOS a udává první a poslední sektor (obojí ve 24 bitech).

I když geometrie už nikoho nezajímá, stále je nutné tato CHS políčka vyplnit.

Pokud je na tom oddílu souborový systém FAT, boot sektor toho FAT filesystému také udává informace o velikosti oddílu.
Linux:

Existuje ioctl HDIO_GETGEO, které vrací geometrii disku a počáteční sektor (offset) oddílu. Dále ioctl BLKGETSIZE, které vrací velikost (v 512-bajtových sektorech) blokového zařízení v 32 bitech. A také ioctl BLKGETSIZE64, které vrací velikost (v bajtech) blokového zařízení v 64 bitech.

BLKGETSIZE je zjevně zastaralé - mělo by být všude nahrazeno BLKGETSIZE64. 2^41 B jsou 2 TB a některé RAIDy jsou větší.

HDIO_GETGEO ioctl udává hlavy, sektory a cylindry - pole o 1, 1, 2 bajtech. Na jednu stranu je to rozumné - neexistuje žádné rozhraní, které by mohlo pro počet cylindrů používat více než 16 bitů. Na druhou stranu však stále existuje vadný software, který počítá velikost disku jako C*H*S a C, H, S získává pomocí HDIO_GETGEO. Tak je to pochopitelně špatně a nepomůže zavedení nového ioctl - takový software musí být opraven, aby používal BLKGETSIZE64.
Používání geometrie pod Linuxem:

Zjednodušeně řečeno byla geometrie v Linuxu potřeba ze dvou důvodů: LILO (a podobné bootloadery) a *fdisk. Samozřejmě také programy, které se snaží emulovat aspekty DOSu/Windows, se zajímají o geometrii.

Důvod "LILO" už je pryč - s parametry jako linear nebo lba32 používá lilo při instalaci lineární čísla sektorů a na CHS je v případě potřeby převádí při bootu.

Důvod "fdisk" už je také pryč - když se to všechno kolem geometrie tak hrozně zkomplikovalo, nikdo se už nesnažil geometrii rozumět. Místo toho se pouze odhadlo z tabulky oddílů, jakou geometrii používal program, který ji naposledy zapsal.

Jak geometrii zjistil kernel? Především následujícími třemi způsoby: (i) z bootovacích parametrů, (ii) z tabulky oddílů, (iii) dotazem na BIOS při bootu před přepnutím do chráněného režimu.

Informace (i) - explicitní specifikace - a (ii) - tabulka oddílů - jsou dostupné i z uživatelského prostředí, není potřeba kernel. Zůstává otázka, jestli je (iii) dobrý nápad.

Nefungovalo to vždy, ale často ano. (A samozřejmě pouze na i386.) Příklady selhání: kód, který jsme měli, se ptal na informace pouze o prvních dvou discích. Často kladený dotaz zněl: Mám dva identické disky, jakto, že mají jinou geometrii? Ten kód také selhal, pokud byly v systému SCSI disky. Navíc si ten kód myslel, že první dva disky v BIOSu jsou hda a hdb. Ale proto existuje vysvětlení. Například mnoho lidí ponechávalo své velké disky mimo BIOS, protože ten by kvůli velkým diskům spadl.

Takže tohle (iii) bylo vždy trochu neuspořádané a byly s tím problémy. Ale pro většinu lidí to fungovalo.
Současnost

Linux už se nesnaží vynalézat geometrii. Pokud někdo geometrii potřebuje, je sám zodpovědný za zvolení jednoho z mnoha konceptů a za určení hodnot. Většina softwaru se obrací na tabulku oddílů, což funguje.

Parted možná ještě nebyl aktualizován, aby to tak dělal, a proto jsem usuzoval, že problémy Fedory mohou pocházet právě z používání parted.

Je to ztráta? Neřekl bych, ale existuje minimálně jedno využití staré situace, které dnes selže: instalace Windows z linuxového média na úplně prázdný disk.

Správcovství SysFS, 2 e-maily

1. črv - 4. črv

Christian Gmeiner se pokoušel kontaktovat správce SysFS, ale nepodařilo se mu najít žádné informace o tom, kdo by to mohl být. Greg KH odpověděl: Já jsem teď de-facto správce sysfs a hlavního kódu ovladačů. Asi bych to měl konečně přidat do souboru MAINTAINERS...

Bezpečnostní 'NX' funkce v 2.6, 66 e-mailů

02. črv - 08. črv

Ingo Molnar za společnost Red Hat napsal:

Rádi bychom oznámili následující patch pro kernel:

http://redhat.com/~mingo/nx-patches/nx-2.6.7-rc2-bk2-AE

Tento patch zavádí využití funkce 'NX' u x86 - poprvé se objevila u AMD64 a podpora byla oznámena i Intelem. (Další výrobci x86 CPU, Transmeta a VIA, rovněž oznámili, že budou funkci podporovat. Podporu ve Windows Microsoft oznámil na příští service pack.) Funkce NX se označuje také jako 'Enhanced Virus Protection' (vylepšená ochrana před viry). Patch zajišťuje pro Linux plnou podporu této funkce.

Co ten patch dělá? Formát tabulky stránek současných x86 CPU nemá bit 'execute' (spustit). To znamená, že i když aplikace namapuje oblast paměti bez PROT_EXEC, CPU stejně umožní, aby byl v této paměti spuštěn kód. Tato vlastnost bývá často zneužívána exploity, když se jim podaří umístit nepřátelský kód do takové paměti - např. díky přetečení bufferu.

Funkce NX toto mění a přidává do PAE formátu tabulky stránek bit 'dont execute' (nespouštět). Ale protože je výchozí hodnota nula (kvůli kompatibilitě), jsou všechny stránky při výchozím nastavení spustitelné a je potřeba jádro naučit tento bit využívat.

Je-li funkce NX podporovaná procesorem, opatchované jádro NX zapne a zavede omezení spustitelnosti v uživatelském prostoru - např. no-exec stack, no-exec mmap a datové oblasti. To znamená menší šanci, že přetečení stacku nebo bufferu způsobí exploity.

Dále ten patch také implementuje 'NX ochranu' pro kód kernelu: je spustitelný pouze kód kernelu a moduly - takže i přetečení v prostoru kernelu jsou těžší (v některých případech nemožná). Takhle je zastaven kód kernelu, který se pokouší spustit mimo stack:

 kernel tried to access NX-protected page - exploit attempt? (uid: 500)
 Unable to handle kernel paging request at virtual address f78d0f40
  printing eip:
 ...

Patch je založen na prototypovém NX patchi napsaném v Intelu pro 2.4 - zvláštní poděkování Sureshi Siddhovi a Junu Nakajimovi z Intelu. Existující podporu pro NX v 64-bitových x86_64 kernelech napsal Andi Kleen a tento patch je modelován podle jeho kódu.

Také Arjan van de Ven poskytl mnoho připomínek a byl to on, kdo patch integroval do jádra Fedora Core 2. Testovací RPM jsou k dispozici ke stažení zde:

http://redhat.com/~arjanv/2.6/RPMS.kernel/

RPM balíky kernel-2.6.6-1.411 už mají NX patch aplikovaný.

Rychlý návod, jak zkompilovat vanilla kernel ze zdrojáků s NX patchem:

http://redhat.com/~mingo/nx-patches/QuickStart-NX.txt

Následovalo mnoho technických připomínek a komentářů od lidí jako Christoph Hellwig, Andi Kleen, Rusty Russell a Gerhard Mack. Linus Torvalds se zeptal, nakolik tato funkce koliduje s funkčností starších programů, ale Ingo i Arjan potvrdili, že nežádoucí účinky tohoto typu jsou minimální. Linus tedy navrhl, aby byla NX automaticky zapnuta a pouze se přidal bootovací parametr, kterým by ji bylo možno v případě potřeby vypnout.

Zdokonalení obsluhy tlačítek myši v mousedev, 6 e-mailů

4. črv - 6. črv

Dmitry Torokhov napsal:

Mousedev v současné době kombinuje všechna hardwarová data o pohybu, která dorazí od chvíle, kdy uživatelský prostor naposledy data načetl, do jediného PS/2 paketu. Problém je, že při těžkém nebo i středním zatížení začneme data ztrácet, protože uživatelský prostor je nestíhá dostatečně rychle číst. Projevuje se to takto:

ignorované stisky tlačítek, protože ve chvíli, kdy se uživatelský prostor dostane k tomu, aby data přečetl, tlačítko už je uvolněno;
kliknutí se projeví na špatném místě - když se uživatelský prostor dostane k tomu, aby paket načetl, myš už se pohnula o půl obrazovky jinam.

Následující patch ten problém napravuje - začne shromažďovat nový paket pokaždé, když je uživatelský prostor pozadu a postavení tlačítek se změní. Velikost bufferu je 16 paketů, tj. až 8 párů událostí stisknutí/puštění, což by mělo být více než dost.

Patch je oproti Vojtěchově stromu a měl by být aplikovatelný i na -mm. Také jsem udělal kumulativní patch pro mousedev oproti 2.6.7-pre2:

http://www.geocities.com/dt_or/input/misc/mousedev-2.6.7-rc2-cumulative.patch.gz

Vojtěch Pavlík byl rád, že to někdo udělal.

Podpora binárek SCO v Linuxu, 5 e-mailů

6. črv - 9. črv

Steve Bergman chtěl spustit starší SCO binárku a povšiml si, že projekt linux-abi.sf.net se zdá být mrtvý. Zeptal se, jestli existují jiné projekty, které by pracovaly na spouštění cizích binárek pod Linuxem. Později napsal: Vypadá to, že existuje patch, vydaný právě dnes (a právě pro mě, hádám) na: http://sourceforge.net/tracker/index.php?func=detail&aid=968070&group_id=13130&atid=313130. Na jiném místě Mike Jagdis komentoval:

iBCS bylo ukončeno, když jsem usoudil, že "dost" výrobců již Linux považuje za platformu číslo 1 a ten zbytek jsou staré proprietární věci, které buď fungují nebo je příliš obtížné je opravit. Z iBCS se pak stalo linux-abi, které bylo portováno na novější jádra a byla přidána podpora UnixWare. Nemyslím, že by tu ještě bylo dost SYSV věcí na to, aby mělo smysl v linux-abi pokračovat...

SCO řeklo už dávno, že s linux-abi nemají žádný problém.

Což je docela zajímavé, jelikož iBCS začalo víceméně jako způsob pro Erica Youngdalea, jak otestovat svůj ELF loader kód, a postupně se dostalo až do hlavního jádra.

(iBCS CVS je pořád dostupné na http://sf.net/projects/ibcs - i kdyby nic jiného. Není to úplně od začátku. Mám pocit, že můj první import proběhl v roce 1993...)

V originálu Kernel Traffic 265 vyšla navíc ještě tato témata: