Kapsi BLOG

$ uname -a
Linux lakka 3.2.46-grbfs-kapsi #1 SMP Wed Jun 5 19:48:35 EEST 2013 x86_64 GNU/Linux

Niin mistä puhe?

Ydin eli kerneli (engl. kernel) on tietokoneen käyttöjärjestelmän alin osa, joka mahdollistaa kaikkien muiden tietokoneen ohjelmien toiminnan. ( Wikipedia )

Mikäli olet sinut Kapsin tarjoamien palveluiden kanssa oletan, että tiedät vähintäänkin pääpiirteissään mistä tässä kaikessa on kyse. Nyt vajotaan ihan vähäisesti pintaa syvemmälle niihin periaatteisiin ja perusteisiin, jotka ovat olleet Kapsin Linux-käyttöjärjestelmäytimen kasauksen ja konfiguraation pohjana.

Yleistä Kapsin kerneliarkkitehtuurista

Ensimmäinen huomionarvoinen seikka Kapsin järjestelmiä tarkastellessa on se, että vaikka käytössä on pääosin Debian-distribuution mukaisia järjestelmiä, käytetty käyttöjärjestelmäydin ei ole Debian-projektin tarjoama. Kapsin ylläpito on varsin varhaisessa vaiheessa yhdistyksen historiaa alkanut ylläpitää omaa versiota Linux-kernelin käännöksestä. Tämä ei tarkoita sitä, että käytössä olisi  mitenkään suuresti normaalista Linux-ytimestä eroava versio, vaan pikemminkin lähtökohdiltaan Kapsin käyttämän laitteiston sekä tarpeiden mukaan säädetty versio kulloinkin vakaaksi todetusta ”vanilla”-versiosta.

Ymmärtääksemme nykyisen tilanteen kunnolla, täytyy tarkastelussa palata historiassa taaksepäin, aikaan vuosia ennen kuin itse liityin tähän kirjavaan joukkoon ylläpitäjiä, joiden prioriteetti on pitää Kapsin järjestelmät turvassa ja toimivina. Kapsin historia alkoi vuonna 2003.

Linux 2.6 joulukuussa 2003 lisäsi XFS- ja JFS-tiedostojärjestelmät, sisälsi uudet ALSA-ääni- ja syöttölaitteiden ajurit, NPTL-säikeistyksen tuen ja tehosti käyttöä suurissa järjestelmissä.

Linux 2.6 oli Kapsin ensimmäisten toimintavuosien ajan ”uusi juttu”. Mentiin Debianinkin käyttämän 2.4-sarjan voimin hyvin pitkään. Nykyään  käytössä on vielä 3.2-sarjan kerneli, jota päivitetään eteenpäin käytännössä Kapsin käyttämien patchien sekä muun mahdollisen tarpeen mukaisesti.

Kernelin päivitykset ovat yhdistyksen toimintojen kannalta aika voimakkaasti käyttäjille näkyviä operaatioita ja aiheuttavat varsinkin shellipalveluihin ikävän käyttökatkon. Tästä syystä toimivaa ja turvallista kerneliversiota pyritään ajamaan mahdollisimman pitkään.

Kapsin käyttämät kernelipatchit

Kapsin kernelin suunnittelussa on otettu huomioon useita erityisesti yhdistyksen toimintaa koskettavia tekijöitä. Haasteina on ollut erityisesti tietoturva, suorituskyky sekä järjestelmien vakaus pitkänkin yhtäjaksoisen päälläolon jälkeen.

Käydään hieman läpi Kapsin käyttämiä patcheja sekä niiden taustoja ja osuutta kokonaisuudessa.

HA-patch

Kapsin historian alkuaikoina käytetyistä spesiaalisäädöistä tiedän vain sen verran, että käytössä oli jo tuolloin niinsanottu HA-patch. Nimi ei viittaa ”High Availabilityyn” kuten äkkiseltään voisi kuvitella, vaan patchin tekijöiden sukunimien ensimmäisiin kirjaimiin. Patchin kirjoitti Jaakko Heusala, yhdistyksen alkuvuosien puheenjohtaja ja ylläpitäjä usean vuoden ajalta. Jaakko osasi kertoa kommenteissa tämän historiasta sekä nimeämisestä, joten lainaan Jaakkoa tähän: 

”Tuo HA-pätsin nimi tulee ”huoh access limit” lyhennyksestä, koska käytin silloin nimimerkkiä huoh. Osittain se ehkä viittasi myös siihen fiilikseen, että oli etsitty toimivaa ratkaisua simppeliin ongelmaan maailmalta kuitenkaan hyvää ratkaisua löytämättä ja se pätsi oli vähän sellainen tulos ”nyt se kernelin koodi tänne, korjaan sen itse!” (Kernelin muokkaaminen oli melkeinpä niitä viimeisiä juttuja joita halusin ruveta tekeen silloin.)”

HA-patch on pohjimmiltaan hyvin yksinkertainen. Sen tarkoitus on pitää käyttäjien tiedostot piilossa toisilta käyttäjiltä chmod-määreistä riippumatta. Tämä on käyttäjille näkyvin muutos Kapsin kernelin osalta. HA-patch on myös koodillisesti erittäin yksinkertainen ja on siten tominut lähes muutoksitta aina versioista 2.4 asti.

Grsecurity

Toinen merkittävä virstanpylväs yhdistyksen kernel arkkitehtuurissa on grsec. Se on laaja patchset, jonka tarvoite on antaa lisäsuojaa erilaisia mahdollisia käyttöjärjestelmäytimen haavoittuvuuksien hyödyntämisyrityksiä vastaan. Kapsin tietoturva-arkkitehtuurissa grsecistä on pitkään käytetty sellaisia osia, jotka eivät vaadi suuria järjestelmäriippuvaisia konfiguraatioita. Esimerkiksi RBAC (Role Based Access Control) ei ole ollut toistaiseksi laajassa käytössä.

Grsecin ajatus tietoturvan kannalta on toimia yhtenä monista muuttujista, joita mahdollisen haavoittuvuuksia hyödyntävän hyökkääjän on vaikea ottaa huomioon yhdistyksen järjestelmiin suunnattuja toimia pohtiessaan. Lähtökohtaisesti grsec ei koskaan pysty täydellisesti estämään muun kernelin osa-alueen haavoittuvuuden hyödyntämistä, vaan aiheuttaa lähinnä tarpeen kohdistaa hyökkäystä juuri tätä kyseistä ympäristöä vastaan. Toisinsanoen yleisesti saatavilla olevat hyökkäyskoodit eivät välttämättä, toivottavasti, toimi sellaisenaan sopivin grsecin tarjoamin optioin varustettua järjestelmää vastaan. Käytännön kannalta grsec parhaimmillaankin ostaa ylläpidolle vain aikaa järjestelmän päivityksen valmisteluun.

Grsecin ja HA-patchin lisäksi kernelin suojauksessa on käytössä yksi vähemmän ”hieno”, mutta enemmän käytännönläheinen ajatusmalli turvallisuuteen liittyen. Pohjimmaisena on periaate, jonka mukaan kerran käynnistettyä järjestelmäydintä ei tule voida peukaloida. Grsec tarjoaa itsessään jonkin verran erilaisia kernelin muistialueen suojauksia tähän liittyen, mutta haittaohjelmien ja rootkittejen kannalta yleisin toimintamalli riitävät oikeudet hankittuaan on puuttua suoraan käytössä olevan kernelin toimintaan.

Kernelimoduulituki

Helpoin ja toimivin tapa muuttaa kernelin toimintaa järjestelmän ollessa käynnissä on ladata moduuli, joka toteuttaa hyökkääjän kannalta oleellisia toimintoja. Nämä voivat olla esimerkiksi kyseisen modulin olemassaolon ja tiettyjen hyökkääjän käyttämien palveluiden ja verkkoliikenteen piilottaminen koko muun järjestelmän näkyviltä. Tällainen palikka tunnetaan myös nimellä rootkit.

Kapsin lähestymistapa rootkiteiltä suojautumiseen on tehdä kernelistä mahdollisimman vaikeasti muutettava ajon aikana. Linux-järjestelmissä tähän on olemassa erittäin helppo ja yksinkertainen keino. Kernelistä on jätetty moduulituki kokonaan pois, jolloin kernelin muuttamiseksi vaaditaan koneen uudelleenkäynnistys. Kapsin kerneli on rakennettu juurikin näin.

Schedulointi ja BFS

Tästä aiheesta voisi ja ehkä pitäisikin kirjoittaa ihan oma blogiposti – tai kirja. Sen verran tuntuu olevan vaikeasti lähestyttävä kokonaiskonsepti kyseessä. Käydään nyt kuitenkin asia läpi popularistisellä tasolla ja yksinkertaistettuna niin ettei aiheuteta lukijoille välttämättä päänsärkyä.

Isoa shell-käyttäjämäärää palvelevan linux-koneen haasteena on väistämättä suoritettavien prosessejen suuri määrä. Kapsi ei ole toiminnassaan koskaan pyrkinyt asettamaan tiukkoja rajoja, vaan käyttäjien toimille asetetut järjestelmätason rajat pyrkivät vähentämään mahdollisten väärinkäytösten, tahattomien tai tahallisten, aiheuttamaa haittaa järjestelmän muille käyttäjille.

Yhdeksi merkittäväksi haasteeksi linuxin ja suuren prosessimäärän kanssa nousee interaktiiviset prosessit, jotka käyttävät yleensä hyvin pienen määrän suoritinaikaa kerrallaan, mutta todella usein. Esimerkkejä tällaisista interaktiivisista prosesseista ovat vaikkapa verkkoliikennettä vastaanottavat prosessit, jotka heräävät käsittelemään saapuneita paketteja tai SSH tai irssi, jotka ottavat käyttäjän syötteitä vastaan ja pitävät yllä aktiivisia yhteyksiä internettiin.

Suuri määrä interaktiivisia prosesseja on luonteeltaan haastava kuorma kernelille koska kernelin prosessischeduleri joutuu pitämään kirjaa ja tekemään päätökset siitä, mikä prosessi milloinkin saa suoritinaikaa ja mitkä prosessit joutuvat odottamaan pääsyä suoritukseen. Tämä kernelin sisäinen prosessi vie myös itsessään suoritinaikaa ja koneen resursseja riippuen kernelin sisäisen schedulerin toimintaperiaatteesta ja tehokkuudesta päätöksenteossa sekä seurannassa.

Linux-kernelin oletusarvoinen prosessischeduleri tunnetaan nimeltä CFS (Completely Fair Scheduler). Se pyrkii tarjoamaan tasa-arvoa prosessien suoritinajan suhteen ja päästää vähäisesti suoritinaikaa käyttävät prosessit suoritettavaksi useammin kuin pitkään suoritettavat prosessit. Tämä periaate on sinänsä hyvä ja toimiva, mutta Kapsin kaltaiesssa ympäristössä CFS:n toteutus aiheesta jätti huomattavasti toivomisen varaa.

Kapsin pääasiallinen shellipalvelin, Lakka, kärsi huomattavasta hitaudesta aina iltapäivisin ruuhka-aikaan talvella 2010. Tuolloin käytössä oli vielä HP DL380 G5 -sarjan palvelinkone, jossa oli kaksi fyysistä neljän ytimen suoritinta ja 16 Gt muistia.

VMstat-kuvaaja kertoo suoritusta odottavien prosessejen määrän arvona ”running” ja levyoperaatioita odottavien prosessejen määrän arvona ”I/O sleep”. Running-arvon tulisi olla kaikissa tilanteissa pienempi kuin käytettävien prosessoriytimien määrä parhaan suorituskyvyn takaamiseksi. Kuvaajan vasen laita on ajalta ennen siirtymistä BFS-scheduleriin.

Ylläpidolla oli kaksi vaihtoehtoa hitailun ratkaisemiseksi. Joko hankkia uusi, järeämpi palvelinkone tai yrittää löytää resurssiongelmaan jokin muu ratkaisu. Käyttäjien toimien rajoittaminen ei kuulunut edes tuolloin harkittuihin vaihtoehtoihin.

Havaittiin eräänlainen ristiriita prosessejen suoritusjonon ja koneen CPU:n käyttöasteen välillä.

Kuvassa Lakka-palvelimen CPU-käyttö. CFS:n ollessa käytössä (kuvan vasen laita) CPU-resursseista oli käytössä yhteensä vain noin 25 %. Kuvaajan ”hassut” arvot oikealla johtuvat kyseisten kerneliversioiden epävakaudesta sekä lukuisista käyttökatoista vuoden 2010 aikana.

Suoritusjonon ja CPU-käytön välinen ristiriitatilanne antoi viitteitä siitä, että ehkä kernelin toiminnassa voisi olla parantamisen varaa prosessien scheduloinnin suhteen. Tutkittiin vaihtoehtoja ja päädyttiin kokeilemaan BFS-patchia Kapsin kernelissä. Muutos oli aika radikaali ja hitailuongelmat kerralla poissa.

Tässä vielä muutama kuva, jotka antavat käsitystä koneen yhtäaikaisten käyttäjien määrästä.

Context switches -arvo kertoo sen, kuinka usein suoritettava prosessi vaihtuu sekunnin aikana. Oikealla olevat piikit ovat jälleen kerneliongelmien aiheuttamia vääristymiä kuvaajissa.

Tämä kuvaaja on lähinnä referenssiksi siitä, että CFS:sta BFS:iin vaihtaessa koneen käyttöaste ei juuri muuttunut. Vuosien 2010 ja 2011 aikana yhdistys kuitenkin sai paljon uusia jäseniä ja toisaalta shellikoneella alettiin myös ajamaan entistä raskaampia palvelinprosesseja kuiten Minecraft-palvelimia.

SSHd-prosessien määrä Lakka-palvelimella CFS:sta BFS:iin siirryttäessä ja sen jälkeen.

SSHd-prosessien määrä kertoo yhtäaikaisesti palvelimella kirjautuneena olevat sessiot. Vaaleamman vihreä alue näyttää vuorokausivaihtelun kirjautumismäärissä. Käyttäjämäärien nousu vuoden 2011 alkuun mennessä on kohtuu huomattava.

Kokonaisuudessaan siirtyminen Kapsin kernelissä CFS-schedulerista BFS-scheduleriin ei ollut helppo tie. Epävakaus oli vuoden 2010 aikana todellinen riesa ja vasta Linux-kernelin VM (Virtual Memory) -kokonaisuuden suurempi korjaus toi lopulta helpotuksen vakausongelmiin. Suorituskyky nousi kuitenkin vaihdoksen myötä aivan uudelle tasolle, kun prosessien schedulointi ei enää ollut pullonkaula järjestelmän toiminnassa.

 

Teknisempää settiä voi seurata tai olla seuraamatta riippuen blogaajien mielenkiinnosta, käytettävissä olevasta ajasta sekä kuun asennosta. Kuulostellaan myös lukijoiden mielenkiintoa aiheeseen. 😉

Avainsanat: bfs, cfs, grsec, grsecurity, ha-patch, kerneli, linux, scheduler

Tämä artikkeli on kirjoitettu perjantaina 30. elokuuta 2013 klo 0:10 ja sen aiheena on Sekalaista. Voit seurata tähän merkintään tulevia kommentteja tilaamalla RSS 2.0-syötteen. Voit vastata tai tehdä paluuviitteen omalta sivustoltasi.