| garoeda | goed, laat ons de volgende talk beginnen |
|---|
| garoeda | onze volgende spreker is rik van riel, linux kernel hacker ++ |
|---|
| garoeda | ik ken rik van dit kanaal maar we hebben nog niet zoveel gesproken, de keren dat ik hem tegenkwam was hij altijd heel aangemaan, slim en inzichtrijk |
|---|
| garoeda | ik geloof dat hij momenteel werkt voor redhat in de VS, niet ? |
|---|
| garoeda | riel: idd |
|---|
| garoeda | jose_n: deze presentatie heet "cool things that missed 2.6" |
|---|
| garoeda | en nu, rik van riel :) |
|---|
| garoeda | riel: ok |
|---|
| garoeda | het voelt goed om terug te zijn op Umeet |
|---|
| garoeda | dit is nu de 4de keer dat ik meedoe |
|---|
| garoeda | en het is altijd leuk geweest |
|---|
| garoeda | vandaag ga ik spreken over een paar coole patches (en projecten) die bijna klaar zijn om in de 2.6 kernel te gaan |
|---|
| garoeda | ik heb geen tekst voorbereid dus ik ga live spreken |
|---|
| garoeda | dus, maak je geen zorgen wanneer je me wil vragen stellen |
|---|
| garoeda | je kan op elk moment vragen stellen in het #qc kanaal |
|---|
| garoeda | er gaat een vertaling naar het spaans zijn in #redes |
|---|
| garoeda | en een naar het nederlands in #taee |
|---|
| garoeda | i denk dat ik moet beginnen met te zeggen dat de 2.6 kernel stukken beter lijkt dan de 2.0.0, 2.2.0 of 2.4.0 kernels |
|---|
| garoeda | dus jullie zouden allemaal de 2.6 kernel moeten proberen en bugs rapporteren op linux-kernel@vger.kernel.org ;)) |
|---|
| garoeda | ik ga spreken over de volgende projecten |
|---|
| garoeda | - execshield |
|---|
| garoeda | - 4/4 split |
|---|
| garoeda | - CKRM (class-based kernel resource manager) |
|---|
| garoeda | - memery hotplug |
|---|
| garoeda | ... |
|---|
| garoeda | de eerste patch die ik ga bespreken is security related |
|---|
| garoeda | zoals jullie waarschijnlijk allemaal wel weten heeft de 2.6 kernel enkele security verbeteringen die de schade die kan gedaan worden door een security hole limiteren |
|---|
| garoeda | bijvoorbeeld, met selinux kan je de schade beperken die gedaan wordt wanneer sendmails NOGMAALS geexploit wordt |
|---|
| garoeda | of bind ;) |
|---|
| garoeda | met exec-shield kan je nog een stap verder doen om het systeem secure te maken |
|---|
| garoeda | eigenlijk wordt de layout van het process geheugen veranderd |
|---|
| garoeda | en de gegevens op de stack zijn bij default niet meer executable |
|---|
| garoeda | dit maakt het veel moeilijker om een normale buffer overflow te doen veranderen in een exploit |
|---|
| garoeda | op x86 CPUs hebben de page tables geen executable permissie bit, dus exec-shield moet nogal lelijke segmentatie hacks doen |
|---|
| garoeda | gelukkig hebben de andere cpu's waar linux op draait, inclusief AMD64, executable bits in hun page tables, waardoor de segmentatie trukken niet meer nodig zijn in de toekomst |
|---|
| garoeda | vraag: gaat dit proces de snelheid van dit systeem niet naar beneden brengen ? |
|---|
| garoeda | riel: ja, natuurlijk |
|---|
| garoeda | segmenatie doet het programma een beetje trager draaien |
|---|
| garoeda | de verhoogde veiligheid zal het verlies in snelheid wel waard zijn voor sommige mensen |
|---|
| garoeda | op dit moment moet ik ook zeggen dat exec-shield niet de meest goede geheugen management verandering is voor security |
|---|
| garoeda | PaX is waarschijnlijk meer flexibel |
|---|
| garoeda | maar heeft meer overheid dan exec-shield |
|---|
| garoeda | i denk dat exec-shield een redelijk compromis zal zijn tussen extra security en snelheid voor de meeste mensen |
|---|
| garoeda | het gaat gepaard met sommige truks zoals het randomisern van het start adrres van de stak, de heap en de exeuctables en libraries |
|---|
| garoeda | het gebruik van buffer overflows om naar een libc functie te jumpen wordt erg moeilijk |
|---|
| garoeda | integendeel, de aanvaller zal sendmail doen crashen ipv een root shell te krijgen |
|---|
| garoeda | of meer waarschijnlijk: de overflow zal niet eens een aanval zijn |
|---|
| garoeda | vraag: wat is de oplossing die het minste aantal resources nodig heeft ? |
|---|
| garoeda | wel, het beste zou zijn een AMD64 chip gebruiken ;)) |
|---|
| garoeda | deze hardware heeft de executable bit voor de page tables ingebouwd |
|---|
| garoeda | en er is geen performance verlies voor een non-exec stack of heap |
|---|
| garoeda | vraag: wat maakt dit beter dan bv een chrooted omgeving voor applicaties ? |
|---|
| garoeda | ok, exec-shield is niet "beter"... ik zou de 2 tesamen gebruiken |
|---|
| garoeda | je kan (en eigenlijk moet) named draaien in een chroot omgeving |
|---|
| garoeda | maar wanneer iemand inbreekt kunnen ze je computer nog altijd gebruiken om network packets te verzenden naar ergens anders. (bv meedraaien in een DDoS) |
|---|
| garoeda | het verkleinen van de kans dat een buffer overflow geexploit kan worden is dus een goed ding om te doen |
|---|
| garoeda | oh, en je kan de exec-shield verkrijgen als deel van Arjan's 2.6 kernel rpm |
|---|
| garoeda | op http://people.redhat.com/~arjanv/ |
|---|
| garoeda | ik heb dit nog niet gezien in andere kernel patch sets |
|---|
| garoeda | vraag: andere distro's zoals adamantix gebruiken rsbac en pax voor de security, wat met deze patches ? |
|---|
| garoeda | ok |
|---|
| garoeda | rsbac is een beetje zoals selinux |
|---|
| garoeda | it helpt heel veel in het verkleinen van de schade die men kan doen nadat men kan inbreken via een progromma |
|---|
| garoeda | maar het helpt de inbraak niet te voorkomen |
|---|
| garoeda | Pax helpt hierin wel maar komt aan een hogere kost dan execshield |
|---|
| garoeda | als je echt paranoide bent zal je waarschijnlijk wel PaX gebruiken |
|---|
| garoeda | maar persoonlijk denk ik dat de performantie impact van PaX (in het bijzonder het extra ruimte gebruik, dus dat je programma's minder adress ruimte hebben) het te "duur" gaan maken voor de meeste mensen |
|---|
| garoeda | zijn er andere vragen over exec-shield ? |
|---|
| garoeda | (anders ga ik over naar de 4/4 split) |
|---|
| garoeda | ... |
|---|
| garoeda | ok, 4/4 split |
|---|
| garoeda | ik ga nu uitleggen wat waarschijnlijk het grootste probleem is dat linux heeft op 32 bit x86 systemen |
|---|
| garoeda | het probleem is dat x86 systemen tot 64 gb fysiek geheugen kunnen hebben maar enkel 4 gb virtueel geheugen |
|---|
| garoeda | en de klassieke linux virtual memory layout houdt in dat de kernel maar 1 GB ruimte heeft ! |
|---|
| garoeda | dit betekent, 1 GB om 64 GB geheugen te beheren |
|---|
| garoeda | dit is simpelweg niet genoeg ruimte om het soort programma's te draaien dat je op een 64 GB server draait |
|---|
| garoeda | om een lang verhaal kort te maken, met 1 GB kernel space zal een systeem met meer dan 24 GB ram bijna onbruikbaar worden |
|---|
| garoeda | omdat je niet genoeg kernel geheugen hebt om de programm's te draaien die mensen met zo'n systeem draaien |
|---|
| garoeda | in 2.6 en latere 2.4 kernel werden de page tables verplaatst naar high memory |
|---|
| garoeda | dus, ze worden opgeslagen buiten de 1 GB kernel space |
|---|
| garoeda | dit verhoogde de limiet van 16 GB naar 24 GB of 32 GB |
|---|
| garoeda | maar nog altijd ver van de 64 GB die x86 systemen kunnen gebruiken |
|---|
| garoeda | natuurlijk, de oplossing voor mensen met echt grote server is het gebruik van een 64 bit CPU |
|---|
| garoeda | dus de kernel heeft dan alle ruimte die het maar nodig heeft |
|---|
| garoeda | maar nee, ze willen een goedkope server ;(( |
|---|
| garoeda | dus kopen ze x86 |
|---|
| garoeda | en natuurlijk, het zijn de software mensen die met het probleem blijven zitten ;) |
|---|
| garoeda | het eenvoudigste dat we kunnen doen is de kernel space verhogen naar 4 GB |
|---|
| garoeda | maar er is slechts 4GB aanwezig in Linux, verdeeld tussen kernel- en user space |
|---|
| garoeda | dus moeten we dat veranderen |
|---|
| garoeda | Ingo Molnar schreef een patch die iets heel vuils doet maar wel werkt en weinig verandering in de rest van de code vereist |
|---|
| garoeda | je weet dat een proces zijn eigen memory space heeft |
|---|
| garoeda | met Ingo's split 4/4 patch, heeft de _kernel_ ook zijn eigen 4 GB memory space |
|---|
| garoeda | en iedere keer je een system call doet of een interrupt optreedt doet het systeem een memory context switch |
|---|
| garoeda | in de 4 GB grootte kernel memory space |
|---|
| garoeda | op deze manier heeft de kernel genoeg geheugen om 64 GB fysieke ram te beheren en de processen die erin draaien |
|---|
| garoeda | het heeft echter wel zijn kostprijs |
|---|
| garoeda | gebruikelijk verlies je er 10 % prestatie mee |
|---|
| garoeda | omdat de CPU iedere keer van memory adress space moet wisselen |
|---|
| garoeda | op sommige benchmarks kan dit verlies zelfs oplopen tot 30 % |
|---|
| garoeda | en ook, dit is de laatste grote verandering die men kan doen op 32 bit systemen |
|---|
| garoeda | als Intel ooit uitkomt met een 32 bit chip die meer dan 64 GB geheugen kan adresseren is er geen andere truk meer die we kunnen gebruiken |
|---|
| garoeda | dat is de reden waarom ik denk dat de enige echte oplossingen is een 64 bit chip te gebruiken |
|---|
| garoeda | als je veel geheugen nodig hebt |
|---|
| garoeda | vraag: hoe lang denk je nog dat de mensen ia32 gaan gebruiken voor groote systemen ? |
|---|
| garoeda | ik denk dat ze ia32 gaan gebruiken totdat Intel een goedkope 64 bit CPU uitbrengt |
|---|
| garoeda | of tot wanneer ze meer dan 128 GB geheugen nodig hebben |
|---|
| garoeda | ik betwijfel wel of IA64 ooit goedkoop zal worden |
|---|
| garoeda | omdat het gedesigned is als een high-end chip |
|---|
| garoeda | hoewel, nu AMD zijn goedkope 64 bit chip market denk ik dat Intel met iets zal komen |
|---|
| garoeda | ik hoop het echt ... ;) |
|---|
| garoeda | nog andere vragen over de 4/4 split of geheugen management problemen ? |
|---|
| garoeda | ok, ik ga 1 minuut pauze houden om de vertalers de kans te geven in te halen |
|---|
| garoeda | dan ga ik verder gaan met CKRM, de class based kernel resource manager |
|---|
| garoeda | ... |
|---|
| garoeda | dit is in feite het project waar ik al van droomde sinds de 2.0 kernel ;) |
|---|
| garoeda | en enkele kleine aspecten ervan zitten in de kernel |
|---|
| garoeda | CKRM bestaat uit 2 delen: |
|---|
| garoeda | 1) een classifier, om tasks te groeperen in resource classes die gebaseerd zijn op |
|---|
| garoeda | - pied |
|---|
| garoeda | -gid |
|---|
| garoeda | - uid |
|---|
| garoeda | - name |
|---|
| garoeda | - resource class id |
|---|
| garoeda | - ... |
|---|
| garoeda | 2) resources control modules , die inpluggen in de CKRM core en |
|---|
| garoeda | - verdeel de cpu eerlijk tussen resource classes |
|---|
| garoeda | - leg memory limieten op tussen verschillende resource classes |
|---|
| garoeda | met CKRM kan je dingen doen zoals: |
|---|
| garoeda | "ik wil dat sendmail en alle processen die door sendmail gestart worden niet meer dan 10 % geheugen gebruiken en 20 % cpu" |
|---|
| garoeda | dus onafhankelijk van de belasting van je mail queue zal je systeem in het geheel niet overbelast worden |
|---|
| garoeda | op de universiteit kan je specifieren als volgt: "studenten krijgen tussen 10 % en 50 % van het geheugen, personeel tussen 30 % en 80 % en de systeembeheerder krijgt zoveel ie wil" |
|---|
| garoeda | de mogelijkheden van CKRM zijn bijna onuitputtelijk |
|---|
| garoeda | ik ben er zeker van de dat mensen met BOFH inspiraties zeker met creatieve ideeen zullen afkomen |
|---|
| garoeda | (en terug, als je vragen hebt stel ze in #qc) |
|---|
| garoeda | je kan informatie vinden over CKRM op http://ckrm.sourceforge.net/ |
|---|
| garoeda | maar natuurlijk, CKRM heeft ook enkele negatieve kanten |
|---|
| garoeda | het is zeer cool en flexibel maar is ook zeer complex |
|---|
| garoeda | ik zou niet verbaasd zijn moest CKRM te ingewikkeld zijn voor Linux |
|---|
| garoeda | het moet dus vereenvoudig worden eer het in de 2.7 kernel kan |
|---|
| garoeda | vraag: ok, stel dat je limieten instelt voor bv sendmail, wat gebeurd er dan wanneer deze bereikt worden ? stopt de geheugenallocatie ? |
|---|
| garoeda | in de meeste gevallen zal sendmail uitgeswapt worden |
|---|
| garoeda | het zou virtual memory krijgen, niet enkel fysiek geheugen |
|---|
| garoeda | bovendien, als het systeem nog vrij geheugen heeft dat niet gebruikt wordt op dat moment kan de resource class dat lenen |
|---|
| garoeda | vraag: en wat is de kostprijs qua performantie ? |
|---|
| garoeda | ik kan daar nog geen antwoord op geven daar CKRM nog in de ontwikkelfase zit |
|---|
| garoeda | de code is nog niet klaar en heeft nog oplapwerk nodig |
|---|
| garoeda | ik denk dat de performance overhead klein zal zijn voor de meeste resource schedulers |
|---|
| garoeda | vraag: kan CKRM enkel cpu en ram geheugen controleren of ook andere dinge nzoals fork()s en send()s per seconde ? |
|---|
| garoeda | momenteel kan CKRM enkel cpu, geheugen en IO controleren |
|---|
| garoeda | maar men plant meerdere modules |
|---|
| garoeda | voor cpu en IO, is de CKRM module een scheduler |
|---|
| garoeda | dus je kan zekere bandbreedte garanties geven of een maximum aan sommige groepen |
|---|
| garoeda | geheugen kan ongeveer hetzelfde, met 1 groot verschil |
|---|
| garoeda | je hebt een nieuwe seconde cpu tijd iedere seconde, maar geheugen kan niet groeien ;) |
|---|
| garoeda | in computerwetenschappen termen is geheugen een niet-vernieuwbare resource |
|---|
| garoeda | dus als een resource groep meer geheugen nodig heeft dan zijn limiet maar iets anders heeft het nodig moet het systeem werken om het weg te nemen (swapping out) |
|---|
| garoeda | voor CPU, IO bandwith or netwerk scheduling heeft het systeem zo geen werk te doen |
|---|
| garoeda | voor de systeembeheerders is er nog iets dat ze in de gaten moeten houden |
|---|
| garoeda | als je iedere resource groep in je systeem een minium van 10 % garandeert, wees er dan zeker van dat je niet meer dan 10 resource groepen hebt |
|---|
| garoeda | vraag: hoe ziet de system call interface naar CKRM eruit ? is het een hoop ioctl()s ? |
|---|
| garoeda | de interface naar userspace staat nog niet vast |
|---|
| garoeda | CKRM A0* gebruikte system calls maar CKRM B0* gebruikt een /proc interface |
|---|
| garoeda | dit kan nog veranderen in de toekomst, totdat Linus gelukkig is ;) |
|---|
| garoeda | vraag: ondersteunt Linus CKRM voor 2.7 ? |
|---|
| garoeda | ik denk niet dat men hem dat al heeft gevraagd |
|---|
| garoeda | het lijkt me moeilijk om hem te overtuigen dat CKRM cool is |
|---|
| garoeda | het houdt niet zo van server-only dingen |
|---|
| garoeda | Linus wil dat functinaliteit nuttig is voor iedereen |
|---|
| garoeda | ...en daar heeft hij gelijk in |
|---|
| garoeda | maar , CKRM kan ook goed zijn voor desktops |
|---|
| garoeda | bv, de desktop gebruiker kan een gegarandeerd minimum aan resources krijgen zodat updatedb het system niet traag maakt |
|---|
| garoeda | ja, het is een hack, maar het maakt de desktop beter ... ;) |
|---|
| garoeda | nog vragen of ga ik over naar "memory hotplug" ? |
|---|
| garoeda | ... |
|---|
| garoeda | ok, memory hotplug :) |
|---|
| garoeda | de serverfabrikanten werken aan een nieuwe functionaliteit |
|---|
| garoeda | het idee is dat systeembeheerders nieuw geheugen (DIMMs) in hun systeem kunnen pluggen terwijl het systeem nog draait |
|---|
| garoeda | sommigen willen zelfs dat de beheerder geheugen kan wegnemen |
|---|
| garoeda | het toevoegen van geheugen in 2.6 is doenbaar |
|---|
| garoeda | we hebben al NUMA ondersteuning in de kernel, om verschillende geheugen gebieden in een systeem te ondersteunen |
|---|
| garoeda | wanneer de beheerder nieuwe geheugen toeveoegt kunnen wij een nieuwe geheugenzone creeren ervoor |
|---|
| garoeda | en dan de nieuwe zone toevoegen aan de lijst van de andere zones |
|---|
| garoeda | daarna kunnen we het geheugen gaan gebruiken |
|---|
| garoeda | "eenvoudig" op een paar details na waar ik jullie nu niet mee ga lastig vallen |
|---|
| garoeda | vraag: hoe kan je geheugenverwijderen als er nog dirty pages inzitten ? |
|---|
| garoeda | ok, het verwijderen van geheugen is een GROOT probleem |
|---|
| garoeda | ik denk niet dat Linux dat zal gaan ondersteunen in de nabije toekomst |
|---|
| garoeda | als al het geheugen in een DIMM tot gebruikersprogramma's behoort kunnen we deze uitswappen wanneer de admin zegt dat hij de DIMM uit het systeem wil halen |
|---|
| garoeda | maar wat wanneer het geheugen mlocked is en we ze niet kunnen uitswappen ? |
|---|
| garoeda | of erger, als de DIMM kernel data structuren bevat die gereferenced worden door fysieke geheugen adressen ?! |
|---|
| garoeda | ik zie geen goede manieren om dit op te lossen |
|---|
| garoeda | ik ken enkele SLECHTE manieren, maar dat willen we niet ;) |
|---|
| garoeda | vraag: zelfs als een DIMM volledig kan leeggemaakt worden moet je nog altijd hopen dat de admin er doe goede module uithaalt |
|---|
| garoeda | ik denk dat er hiervoor de groene en rode lichtjes zijn ;)) |
|---|
| garoeda | memory hotplug kaarten hebben gelukkig genoeg allerlei soorten status lampjes op zich |
|---|
| garoeda | bovendien, waarom zou iemand geheugen uit een systeem willen verwijderen ? |
|---|
| garoeda | ik kan denken aan 2 dingen die een systeembeheerder zou moeten doen |
|---|
| garoeda | 1) meer geheugen toevoegen omdat het systeem meer nodig heeft |
|---|
| garoeda | 2) een slecht stuk geheugen vervangen door een correct werkend...maar dat kan gedaan worden in hardware, die het slechte geheugen mirrort op een stuk goed geheugen en dan de beheerder het slechte stuk er laat uithalen |
|---|
| garoeda | in dit geval is "slecht geheugen" geheugen dat corrigeerbare ECC errors heeft |
|---|
| garoeda | dus de data is nog altijd goed |
|---|
| garoeda | vraag: je kan geheugen vervangen door een soort met hogere snelheid ? of met hogere capaciteit ? |
|---|
| garoeda | ok, 2 goede punten |
|---|
| garoeda | vooral het hogere capaciteit DIMM argument is een goed |
|---|
| garoeda | ik was dat al even vergeten |
|---|
| garoeda | iemand van VALinux Japan werkt aan hot memory removal |
|---|
| garoeda | maar hij ondervindt de fundamentele problemen die ik zonet beschreven heb |
|---|
| garoeda | zijn code werkt dus niet altijd |
|---|
| garoeda | en hij kan alleen maar geheugen verwijderen dat geen kernel data structuren bevat |
|---|
| garoeda | in het kort, voor de 2.6 kernel kan je waarschijnlijk alleen maar memory hot-add verwachten |
|---|
| garoeda | hot-remove is zeer complex |
|---|
| garoeda | ... |
|---|
| garoeda | nog vragen hierover ? |
|---|
| garoeda | ok, den is deze presentatie over ;) |
|---|
| garoeda | ik wil de Umeet organisatoren bedanken om dit event te organiseren |
|---|
| garoeda | ik weet hoeveel werk het is en ben dankbaar dat ze een nieuwe Umeet georganiseerd hebben |
|---|
| garoeda | ik wil ook de vertalers bedanken, die hard werken om deze presentaties (live!) te vertalen |
|---|
| garoeda | als jullie nog steeds wakker zijn wil ik het publiek bedanken |
|---|
| garoeda | het zou niet hetzelfde zijn moest ik enkel tegen mezelf spreken |
|---|
| garoeda | *riel stapt van het virtuele podium |
|---|
| garoeda | <einde vertaling> |
|---|
