Nem linux alapú a Google új, android gyilkos rendszere, a Fuchsia, de akkor micsoda ?

2016 augusztusában minden különösebb felhajtás és céges trombitaszó nélkül, egy óvatlan pillanatban megjelent a Google új generációs operációs rendszerének forráskódja, ami a Fuchsia OS nevet kapta és bár eleinte nem is  nagyon lehetett hallani érdemi dolgokat, az elmúlt években már gyakorlatilag mindenki csak úgy beszél róla, mint az új android gyilkos rendszerről.

Bár ebben érzek némi túlzást, de az mára tény, hogy a Google ezt a rendszert szánja az android utódjának és már a Samsungról többen biztosan állítják, hogy az új rendszert fogja a közeli jövőben használni.

A Fuchsia OS wikipédia oldala és további információk: https://en.wikipedia.org/wiki/Fuchsia_(operating_system)

De mi az amit biztosan tudunk?

Nézzünk be a motorháztető alá !

Ami a mi számunkra talán érdekes lehet, az az hogy a Fuchsia nem linux alapú rendszer lesz, hanem egy Zircon elnevezésű kernelt fog használni.

Egy új üzenettovábbító, vagy mondhatnánk azt is, hogy üzenetváltásos rendszermagon alapul, amely a cirkon ásvány után a Zircon nevet kapta.
A kódbázisát a beágyazott eszközökre szánt Little Kernel (LK) kódbázisából származtatták, amelynek célja az alacsony erőforrás-felhasználás a legkülönbözőbb eszközök számára. Az LK-t Travis Geiselbrecht fejlesztette, aki a Haiku által használt NewOS kernel társszerzője is volt, amely a BeOS szabad szoftveres újraimplementációja.

A Little Kernel GitHub oldala: https://github.com/littlekernel/lk

A Zircon nagyrészt C++ nyelven íródott, helyenként assembly nyelven és elmondhatjuk, hogy nagyon sokat merít a Unix kernelek alapjaiból, de nagyban különbözik azoktól, például az erőforrásokat a hagyományos Unix és linux rendszerekkel ellentétben nem fájlokként, hanem objektumokként reprezentálja.
A Zircon kernel forráskódja és dokumentáció: https://fuchsia.dev/fuchsia-src/concepts/kernel

A projekt weboldalán elolvashatjuk, hogy milyen alapvető különbségek vannak és miben merít az új kernel az alapokból: https://fuchsia.dev/fuchsia-src/concepts/kernel/zx_and_lk

A felsorolt, lényegesebb pontok:

  • az LK  32 -bites rendszerekn is fut, míg a Zircon csak 64 -bites
  • a Zirconnak van first class user-mode támogatása, míg az LK -nak nincs
  • a Zircon képesség alapú biztonsági modellel bír (capability-based security model) viszont az LK trusted módú

First class user-mode

Ez röviden annyit jelent, hogy a hagyományos operációs rendszer funkciókat, például az eszközillesztőket, a protokollkötegeket és a fájlrendszereket általában eltávolítják a mikrokernelből, és helyette a felhasználói térben futnak, így egy alprogram, vagyis ez esetben szerver meghibásodása nem hat katasztrofálisan a fő rendszerünkre, az továbbra is működőképes marad.

Na most, ha nagyon csúnyán akarunk beszélni, mondhatjuk azt is, hogy a Fuchsia egy mikrokerneles, képesség alapú biztonsági mechanizmusra építő, valósidejű operációs rendszer (capability-based, real-time operating system RTOS).

Na ezzel aztán elleszünk egy darabig.

A Google tényleg nem aprózta el, de vegyük szépen sorra az elnevezéseket.

Monolitikus vagy Mikrokernel ?

  •         A hagyományosnak tekintett és általunk is sokat használt rendszerek alapvetően monolitikus szerkezetű kernelt használnak.
    Ez nagy általánosságban annyit tesz, hogy a kernel egyetlen bazi nagy, böhöm medve, ami szinte minden folyamatot kezel és egymaga irányít, minden driver és folyamat itt fut össze és a kernel kezeli azokat és iszonyatos mennyiségű összetevővel rendelkezik, amit esetenként egy saját fordítás esetén szoktunk kiválogatni, ezért van annyi kernel például egyetlen Puppy linux kiadáshoz is.
  •       A mikrokernel alapú rendszerek ezzel szemben csak nagyon minimális összetevőből állnak, egy kernelből, címtár kezelés és a folyamatkezelő IPC -ből, az elnevezés is innen származik, nem pedig a méretéből és itt egy új elem is megjelenik, a szerver: ez adja a mikrokernelek tényleges funkcionalitását, egy szerver tesz lehetővé egy felhasználó számára is elérhető funkciót (pl. FAT32 típusú állományrendszer elérése), amely úgy működik akár egy normális UNIX folyamat: elindítható, leállítható, vagy akár újra is indítható. Ezekben (a mikrokernel kevés funkciója és a szerverek alkalmazása) rejlik az igazi erő és lehetőség: a monolitikus kerneleknél megszokott rendszerhívások bármelyike helyettesíthető egy-egy szerverrel, akár még még a memóriakezelés is (egy ún. “memóriaszerverrel”).

    Ezek a szerverek párhuzamosan futnak egymás mellett, mint folyamatok. Az egész mikrokerneles filozófiát tekinthetjük objektum-orientáltnak is, ha a szervereket objektumoknak tekintjük, amelyek üzenetekkel kommunikálnak egymással. Ez a legkézenfekvőbb módszer, mert így a szerverek nincsenek programozási nyelvhez kötve, csupán egyetlen dologra, az úgynevezett interfészre kell figyelnünk, mivel ezeken keresztül zajlik a kommunikáció.

A mikrokernel meghatározása a wikipédián: https://en.wikipedia.org/wiki/Microkernel

Kernel módú vagy User módú ?

  • A makrokernel esetén, mivel mindent a kernel irányít, így minden kernel folyamat is szükségszerűen kernel módban fut, bár itt is tetten érhetőek változások, az újabb kernelekben már igyekeznek bizonyos nem létszükségszerű folyamatokat user módú szintre helyezni.
  • A mikrokernel esetén a kernel az egyetlen olyan szoftver, amely a legelőkelőbb szinten fut, amelyet általában felügyeleti vagy kernel módnak neveznek.
    A vezérlés sem adódik át neki közvetlenül, hanem csak egy üzenetet küldünk: erre később válaszol a kernel. Minden ilyen taszk beágyazódik a kernel által létrehozott hardver memória területére. Ezen kívül más részeket csak kernel mechanizmusok révén befolyásolhat, tipikusan üzenetek küldésével.
    Ezek
    az ún. messagepassing mechanizmusok (Inter Process Communication, IPC)

A lényeges, architekturális különbség az, hogy a kernel és az eszközmeghajtók, ún. driver-ek memóriaterülete egymástól elszigetelt, ezért egy driver hibája nem okozhatja a teljes kernel sérülését.

Képesség alapú biztonsági mechanizmus

    A képesség-alapú biztonság a biztonságos számítástechnikai rendszerek tervezésében alkalmazott fogalom, a meglévő biztonsági modellek egyike.
Olyan kifejezésre utal, amely egy objektumra hivatkozik a hozzá tartozó hozzáférési jogokkal együtt.

A képesség alapú operációs rendszer felhasználói programjának egy ilyen megoldást kell használnia egy objektum eléréséhez . A képesség alapú biztonság arra az elvre utal, hogy a felhasználói programokat úgy kell megtervezni, hogy azok közvetlenül megosszák egymással ezeket a lehetőségeket (képességeket) és így megvalósuljon  a legkevesebb privilégium elve, tehát minimalizáljuk a kockázatokat a lehető legjobban.

Bár a legtöbb operációs rendszer olyan szolgáltatást valósít meg, amely a ehhez hasonlít, ám általában nem nyújtanak elegendő támogatást ahhoz, hogy lehetővé tegyék a képességek cseréjét az esetlegesen kölcsönösen megbízhatatlan felek között. Ezzel szemben a képességalapú rendszert ennek a célnak a szem előtt tartásával tervezték.

Egy hagyományos linux rendszeren különböző listák biztosítják a hozzáférést a rendszer erőforrásaihoz, ezeket ACL, Acces Control List -eknek nevezzük általánosan, de ebben az esetben nem kell minden eszköz vagy program esetén a különféle jogokkal és listákkal bajlódni, elég a megfelelő objektum-hozzáférés alapján elkészíteni az új alkalmazásokat és eszközöket.

Egy kis angol nyelvű olvasnivaló a rendszerrel kapcsolatos biztonsági megoldásokról: https://www.linux.com/training-tutorials/redefining-security-technology-zephyr-and-fuchsia/

Trusted mód – megbízhatóság

A trusted módra a legjobban a google saját Trusty projektjén keresztül tudunk betekintést nyerni, így engedjétek meg nekem, hogy azt idézzem a témával kapcsolatban, mint autentikus forrást:

A Trusty egy biztonságos operációs rendszer (OS), amely megbízható végrehajtási környezetet (TEE) biztosít az Android számára. A Trusty OS ugyanazon a processzoron fut, mint az Android OS, de a Trusty hardveresen és szoftveresen is el van szigetelve a rendszer többi részétől. A Trusty és az Android párhuzamosan fut egymással. A Trusty hozzáfér az eszköz fő processzorának és memóriájának teljes teljesítményéhez, de teljesen elszigetelt. A Trusty elszigeteltsége megvédi a felhasználó által telepített rosszindulatú alkalmazásoktól és az Androidban esetlegesen felfedezett sebezhetőségektől.

A Trusty kompatibilis az ARM és Intel processzorokkal. ARM rendszereken a Trusty az ARM Trustzone™-t használja a főprocesszor virtualizálására és egy biztonságos, megbízható végrehajtási környezet létrehozására. Hasonló támogatás érhető el Intel x86-os platformokon is az Intel virtualizációs technológiáját használva.

A Trusty a következőkből áll:

  • A Little Kernelből származó kis operációs rendszer
  • Egy Linux kernel-illesztőprogram a biztonságos környezet és az Android közötti adatátvitelhez
  • Android felhasználói tér könyvtár a megbízható alkalmazásokkal (azaz a biztonságos feladatokkal/szolgáltatásokkal) való kommunikációhoz a kernel-illesztőprogramon keresztül.

A Trusty leírásának közvetlen linkje:  https://source.android.com/docs/security/trusty

Valós idejű OS-ek

                Felépítésükből adódóan adott szolgáltatások képesek valós időben futni, például egy megszakítás esetén a Callback függvény adott időintervallumon belül lefut.
Nem csak az OS-nek, hanem az adott alkalmazásnak és kódnak is valós
idejűnek kell lennie. Linux és Windows esetében nem beszélhetünk ilyen garanciáról, viszont vannak olyan kiterjesztések, amik ezt lehetővé teszik (pl. RTLinux, Ardence RTX Windowshoz).
Valós idejű rendszerek esetében a rendszernek adott időn belül adott valószínűséggel válaszolni kell, másképpen a válasz hibás lesz.
Főként a multimédiás alkalmazások esetén, például a zeneszerzők, stúdiómunkák esetén kritikus, hogy a rendszer lagmentesen rögzítsen minden egyes hangot, de akár az egészségügy, akár az autóiparról beszélünk, minden esetben rendkívül fontos, hogy az operációs rendszerünk a lehető leggyorsabban hajtsa végre, lehetőleg késlekedés nélkül az adott feladatot.

Tehát összefoglalva egy kicsit a dolgokat, a Fuchsia OS Zircon kernellel egy valóban izgalmas és érdekes projektnek tűnik, bár még sok téren kell fejlődnie és a biztonsági problémákra is nagyon nagy figyelmet fordítanak a fejlesztők, hiszen akadnak még azokból is bőven, de ha minden összejön, egy valóban pofás kis rendszer lehet belőle, majd kiderül, addig az elmaradhatatlan linkek:

A Fuchsia OS projekt hivatalos weboldala, fejlesztőknek szóló SDK és további technikai részletek a téma iránt érdeklődőknek: https://fuchsia.dev/

A Fuchsia OS kiadások és az azokkal kapcsolatos hírek és részletek: https://fuchsia.dev/whats-new/release-notes

Aki még nem hallott volna esetleg a Flutter -ről, annak egy kis olvasnivaló: https://skamilinux.hu/mi-az-a-flutter/


Továbbra is várunk mindenkit nagy szeretettel csevegő oldalunkon élőben:
https://skamilinux.hu/chat/

Aktív fórum témák:
https://skamilinux.hu/phpBB3/search.php?search_id=active_topics

Legutóbbi PuppySzoftverek:
https://sourceforge.net/p/puppyszoftver/activity

Leave a Reply

Translate »

Weboldalunk cookie-kat használ annak érdekében, hogy megkülönböztesse Önt weboldalunk többi felhasználójától. Ez segítséget nyújt számunkra, hogy weboldalunk böngészése során jobb élményt nyújthassunk Önnek, valamint az oldalunk fejlesztéséhez is hasznosak. további információ

Ha hozzájárult a cookie-k használatához, a böngésző cookie-kat tárol az Ön számítógépén vagy egyéb eszközén, hogy rendszerünk felismerje beállításait. A hozzájárulás érvényessége időnként lejár. Azonban, hogyha szeretné visszavonni hozzájárulását, a böngészője cookie beállításai között bármikor megteheti.

Bezár