Jaderné noviny 300

31. 3. 2005 | Robert Krátký

Články - Jaderné noviny 300  

Linux 2.6.11-rc3-mm2; diskuze o bezpečnosti. Nový hotplug projekt; zkrácení doby startu. Licence BitKeeperu; vývojáři jádra nejsou nadšeni. Pokus o /proc/cpumem.

Linux 2.6.11-rc3-mm2; diskuze o bezpečnosti, 51 e-mailů

10. úno - 18. úno

Andrew Morton oznámil Linux 2.6.11-rc3-mm2:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/

• Přidal jsem Linux Security Module (mlock a !SCHED_OTHER) pro lidi od audia. Vypadá to, že nic lepšího se neobjeví, a tohle je plně zapouzdřené.

Ohledně patchů bezpečnostního modulu [security module] řekl Christoph Hellwig: I kdybychom přijali modul, který skupinám přiděluje možnosti [capabilities], tak takhle by vypadat neměl. Podporuje totiž pouze dvě specifické funkce (a ty ještě různými způsoby!), místo aby přidal obecnou podporu pro přidělování možností skupinám. Olaf Dietsche poznamenal:

Pokud jsem ten kód pochopil správně, tak tohle řešení je k dispozici už dlouho: <http://www.olafdietsche. de/linux/accessfs/>. Nebo nová, samostatná verze: <http://lkml.org/lkml/2005/1/11/ 221>.

Nebo byste mohli použít skutečné řešení - možnosti filesystému: <http://www.olafdietsche .de/linux/capability/>. A pokud se vám tohle nelíbí, je k tomu i alternativa: <http://www.stanford.edu/~ luto/linux-fscap/>.

Andrew Christophovi napsal: Jsem si jistý, že se o tom někde v těch 1000 emailech, které o tom minule proběhly, diskutovalo. Jacku? A Jack O'Quin odpověděl:

Většina lidí si myslela, že mít modul s obecnými možnostmi by bylo fajn. Ale nikdo nenabídl žádný kód, ani se nepřihlásil, že by na tom pracoval.

Já proti takovému přístupu nic nemám, ale nejsem ochoten ani schopen to dělat sám. Podle mého názoru by rozšíření funkčnosti LSM výrazně zvýšilo bezpečnostní riziko. Muselo by se to udělat velmi opatrně.

Christophův návrh by se mohl stát částí obecnějšího modulu, který by RT-LSM nahradil v 2.8. Náš LSM je skromným řešením určeným k zažehnání aktuálních problémů audio vývojářů a uživatelů a s minimálním dopadem na bezpečnost nebo korektnost.

Nový hotplug projekt; zkrácení doby startu, 76 e-mailů

10. úno - 16. úno

Greg KH napsal:

Chtěl bych oznámit další projekt pro uživatelský prostor založený na hotplug. Tahle kolekce kódu nahrazuje existující balík linux-hotplug velmi malými, zkompilovanými programy. Ty jsou místo stávajících bash skriptů.

V současné době poskytuje následující:

• /sbin/hotplug multiplexer. Funguje totožně se stávajícím bashovským /sbin/hotplug.
• Programy pro automatické natahování USB, SCSI a PCI modulů. Tyhle programy určují, který modul má být natažen, když jádro vyšle zprávu o daném druhu zařízení. S několika výjimkami to funguje stejně jako současné skripty linux-hotplug.

Ale proč to vše předělávat v .c? Co je špatného na shellových skriptech? Na shellových skriptech není špatného nic, pokud vám ovšem nevadí interpretr v initrd/initramfs, když chcete poskytovat funkce /sbin/hotplug a automatického natahování modulů. A nebo pokud náhodou nemáte velký stroj, který najednou spustí milión hotplug událostí, a vy je potřebujete všechny zpracovat co nejrychleji a za použití co nejméně paměti.

Takže, jak malé jsou ty programy? Podívejte se:

   text    data     bss     dec     hex název souboru
   4669      32     124    4825    12d9 hotplug
   5077       8     348    5433    1539 module_pci
   4925       8     412    5345    14e1 module_scsi
   5349       8     348    5705    1649 module_usb

Všechno jsou to statické binárky linkované s klibc (která je v balíku hotplug-ng obsažena, stejně jako udev).

Bash skripty pro srovnání:

-rwxr-xr-x  1 root root  4412 Feb 10 15:28 /sbin/hotplug
-rw-r--r--  1 root root   702 Sep 24 08:04 /etc/hotplug/blacklist
-rw-r--r--  1 root root  5293 Sep 24 08:04 /etc/hotplug/hotplug.functions
-rwxr-xr-x  1 root root  3739 Sep 24 08:04 /etc/hotplug/pci.agent
-rwxr-xr-x  1 root root  1459 Sep 24 08:04 /etc/hotplug/scsi.agent
-rwxr-xr-x  1 root root 13466 Sep 24 08:04 /etc/hotplug/usb.agent
-rw-r--r--  1 root root 39306 Sep 24 08:04 /etc/hotplug/usb.distmap
-rw-r--r--  1 root root  4364 Sep 24 08:04 /etc/hotplug/usb.handmap
-rw-r--r--  1 root root   189 Sep 24 08:04 /etc/hotplug/usb.usermap

Všechny jsou do paměti nataženy pro každou hotplug událost (u specifických hotplug událostí se natahuje pouze soubor s typem sběrnice).

Ale co rychlost? Podle naprosto nevědeckého měření na mém starém, pomalém laptopu to trvá 2 vteřiny, než se po připojení USB zařízení natáhne příslušný modul. S hotplug-ng to zabere méně než vteřinu.

Pro ty, kteří by se chtěli podívat, je kód ke stažení zde:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-ng-001.tar.gz.

Pořád ještě zbývá napsat pár dalších programů, aby bylo docíleno stejné funkčnosti jakou mají současné hotplug skripty (firmware, ieee1392 atd.). Ale ty budou dokončeny brzy. Rád bych znal vaše názory; uvítám návrhy, a dokonce i patche :).

Vývoj hotplug-ng probíhá v BitKeeper repozitáři na:
bk://linuxusb.bkbits.net/hotplug-ng

Patrick McFarland odpověděl:

Tohle je bezvadné. Zrovna nedávno jsem si říkal "Proč je hotplug psáno v sh? Cožpak to není nechutně neefektivní způsob řešení něčeho, co musí být provedeno rychle a s co nejmenší spotřebou zdrojů?" Vypadá to, že jsi četl moje myšlenky.

Licence BitKeeperu; vývojáři jádra nejsou nadšeni, 159 e-mailů

13. úno - 23. úno

Larry McVoy napsal:

Chci připomenout, že BK strom jádra má v současné době plus mínus 59 000 changesetů. BK, který máte, využívá pro interní názvy každé delty unsigned shorts [jak se to řekne česky?], což znamená, že přibližně za 100 dní to přestane fungovat.

Dobrá zpráva je, že openlogging strom jádra má changesetů 135 000, takže je zřejmé, že chyba už je dlouho napravena.

Špatná zpráva je, že pro překonání hranice 64 tisíc changesetů budete muset upgradovat binárku BK. Data je na disku uloženo v ASCII, takže je jedno, jestli ten upgrade provedete před nebo po, ale jednou to udělat budete muset.

Oprava bude v bk-3.2.4, který by měl vyjít do konce února. Až to vydáme, rozešleme oznámení a bylo by fajn, kdyby to lidi otestovali, protože za pár měsíců budou muset upgradovat všichni.

Je možné, že licenci pozměníme tak, aby více odpovídala naší komerční licenci. Ale neuděláme to, dokud ji neprobereme s Linusem a spol., abychom se ujistili, že je přijatelná. Jednou z věcí, kterou bychom chtěli udělat, je objasnění otázky nekonkurování. Několik lidí naznačilo, že používáním BK souhlasí s tím, že už nikdy nebudou smět pracovat na jiném SCM systému. Chápeme, že tak někteří lidé licenci interpretovali, ale to nebyl náš záměr. Rádi bychom znění změnili tak, aby bylo zřejmé, že používáním BK souhlasíte s tím, že na vývoji jiného SCM nebudete pracovat 1 rok po ukončení používání BK. Tak jsme to mysleli původně, ale nebylo to řečeno jasně.

Různí lidé protestovali a tvrdili, že by bylo absurdní mít licenci, která by na rok zakazovala pracovat na konkurenčním projektu. Další říkali, že by nešlo kontrolovat dodržování, nebo že to na mnoha místech světa nebude nic znamenat. Alan Cox poznamenal: Skutečným řešením by bylo nahradit BK něčím svobodným a lepším, ale to není snadný úkol.

Pokus o /proc/cpumem, 11 e-mailů

16. úno - 17. úno

Itsuro Oda napsal:

Připojuji implementaci /proc/cpumem. /proc/cpumem ukazuje platné rozsahy fyzické paměti.

• i386 a x86_64.
• Implementovat a použít valid_phys_addr_range() (první argument i386 verze je trochu nepohodlný).
• /dev/mem v i386 verzi by mělo být upraveno. Ale zatím ne.

Příklad: amd64 8GB Mem

# cat /proc/cpumem
0000000000000000 000000000009b800
0000000000100000 00000000fbe70000
0000000100000000 0000000100000000
#

Počáteční adresa a velikost. Hex číslo.

Eric W. Biederman odpověděl: Zajímavé. Když jsem to navrhoval, tak jsem si představoval něco založeného na struct zdroji, co by fungovalo jako /proc/iomem na x86, ale mohlo by být rozumně použito na systémech, kde žije RAM v adresním prostoru odděleném od IO paměti zařízení. I tak měl pocit, že vhodnějším řešením by bylo přidat do /proc/cpumem typové pole, ačkoliv říkal, že pro x86 stroje by to nutné nebylo, protože ty informace už jsou dostupné na jiném místě.

---

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

• New yaird Replacement For mkinitrd
• Extended Attribute Support For JFFS3
• Linux 2.4.30-pre2 Released
• yaird 0.0.4 Released

Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.

Diskuse k tomuto článku

[VícNežNic]

Unsigned short je podle mého nejlépe přeložit jako unsigned short

[Michal Marek (twofish)]

Nebo "16-bitové číslo bez znaménka". Tak je to vlastně ještě přesnější než originál

[Michal Čihař]

short nemusí být 16-bitový...

[Michal Marek (twofish)]

Ale BK klient má problém s 16-bit číslem, resp. s tím, že short je právě 16 bitů.

[VícNežNic]

Ano, ale obecně překládat usigned short jako číslo o 16 bitech asi není ono, že?

[jm]

No, obecne urcite ne...

int
main()
{
  printf("sizeof(char) == %d\n", sizeof(char));
  printf("sizeof(short) == %d\n", sizeof(short));
  printf("sizeof(int) == %d\n", sizeof(int));
  printf("sizeof(long) == %d\n", sizeof(long));
  printf("sizeof(long long) == %d\n", sizeof(long long));

  return 0;
}

[VícNežNic]

Zní to neuvěřitelně, ale sizeof znám

[jm]

Ty jo... to jses dobrej!

[VícNežNic]

Jenom doufám, že si ten kód nepsal ty, protože ty složený závorky jsou úplně jetý

[Michal Marek (twofish)]

Že já vůbec něco psal

Máš samozřejmě pravdu, jenom mi přišlo, že je vlastně (už v originálu) řeč spíš o 16-bitovém integeru (který se snáze přeloží) než o shortu (který přeložit nejde). Just my 2 cents

[Michal Marek (twofish)]

Prostě kdyby p. McVoy napsal, že za pár dní jim přeteče 16-bitové kladné číslo, tak má Robert po starostech

[jm]

Hlavne, aby jim nepretekla treba vana.

[VícNežNic]

No, dobře, ale já to zase pochopil tak, že se Robert ptal obecně jak přeložit unsigned short (po tom co dostal za nepodepsané číslo ), na což to už moc nepasuje.

[Roman Plášil]

Unsigned short jsou podle mě neposkvrněné kraťasy.

[Pavel Stárek]

k 300 stým jaderným novinkám. Rád si je čtu.

[egg]

Proboha!... Chtěl jsi říct: „Blahopřeji k 300. jaderným novinkám.“ Copak tady už nikdo neumí česky?

[Petr (DotaZ) Jakubec]

Je to dobry pocit, vedet, ze budu pravidelne, _dlouhodobe_(*) a v mem temer rodnem jazyce ve zkratce informovan o tom, co se deje uvnitr vyvojarske komunity. DEKUJI.
Diky, je to velky kus dobre odvedene prace.
Petr J.
* dlouhodobost a pravidelnost tohoto vaseho pocinu je asi nejvetsi devizou. to na ceskem internetu neni videt casto.

[Leoš Literák]

od roku 1999, a cislo 42 nebylo uplne prvni prelozene cislo. To uz je let ..

[Michal Marek (twofish)]

Za první překlad "možnosti" bych dal do závorky capabilities. Jinak taky gratuluju ke kulatinám

[Robert Krátký]

Jo, bude to tak lepší. I tak jsem dlouho zvažoval, jak v tomto kontextu slovo "capabilities" překládat.