Google brengt KataOS voor iot-apparaten uit op basis van Rust en met seL4-kernel

Google heeft een nieuw besturingssysteem voor embedded iot-apparaten uitgebracht. KataOS draait volledig op Rust en is op de seL4-microkernel gebouwd. Het OS is gemaakt voor apparaten die zelf machinelearningtoepassingen kunnen draaien.

Google schrijft in een blogpost dat het KataOS specifiek heeft gebouwd voor slimme apparaten die veel gebruikersdata verwerken en op het apparaat zelf aan machinelearning doen, met nadruk op apparaten op een RISC-V-architectuur. Volgens het bedrijf moeten die apparaten extra veilig zijn, maar is de huidige hardware dat niet. Ook toevoegingen zoals die van een asic zouden niet voldoen aan veel veiligheidseisen, zegt Google. Het bedrijf heeft daarom gekozen voor de seL4-microkernel, die specifiek voor veiligheidsdoelen is gemaakt. Ook is het besturingssysteem 'nagenoeg volledig' in Rust geschreven. Dat voorkomt volgens Google veel veelvoorkomende bugs zoals buffer overflows.

Verschillende onderdelen van KataOS staan inmiddels op GitHub. Dat zijn de core-onderdelen van het OS, Rust-frameworks, een alternatieve rootserver en kernelaanpassingen voor seL4.

KataOS kan volgens Google thirdpartyapplicaties dynamisch laden. Deze draaien buiten het gebruikte framework voor seL4 om. Google heeft naast het besturingssysteem ook een implementatie uitgebracht voor secure-hardwareplatformen. Dat is gebaseerd op het opensourceplatform Open Titan.

Reacties (41)

[beerse]

In de maand dat matter uit komt (nieuws: Connectivity Standards Alliance brengt smarthomestandaard Matter 1.0 uit) en dat Google er ook iets mee gaat doen (nieuws: Nieuwe versie Google Home-app ondersteunt Matter). En dan een product uit brengen voor IoT en met geen woord het over matter hebben?

Als matter wel onderdeel is van dit IoT product, dan zou het wel een opsteker zijn voor beide kanten. Als matter niet onderdeel is van dit IoT product, dan zou dat naar mijn idee wel een gemiste kans zijn. In beide gevallen had ik wel verwacht dat matter genoemd zou worden.

[graey]

Het lijkt me niet zo heel gek, je kan vast wel Matter-dingen op dit OS bouwen, maar niet alles wat IoT is, is Matter-materiaal. Ter vergelijking: als er een nieuwe linux-release is, is er ook niet altijd groot OpenGL-nieuws aan gekoppeld.

[Verwijderd]

Zoals @graey al aangeeft staat dit los van Matter. Dit is namelijk een besturingssysteem (OS) waar je bovenop je applicatie kan bouwen. Die applicatie zal dan Matter kunnen ondersteunen (of niet, dat laat je lekker aan de applicatie over).

Het probleem is nu dat er geen veilig of bewezen opensource OS gespecialiseerd voor IoT is. Natuurlijk kun je Linux gebruiken (wat men nu ook doet) maar dat is niet geoptimaliseerd voor IoT hardware.

Het dichtste wat ik ken dat in de buurt komt is ESPhome…Maar:
Our team in Google Research has set out to solve this problem by building a provably secure platform that's optimized for embedded devices that run ML applications
Dit OS is dus ook geoptimaliseerd voor machine learning. Iets dat steeds meer populair wordt (zie Google corel devices). En ze willen ook nog eens alle hardware designs vrijgeven (waarschijnlijk allemaal RISC designs).

Ik zeg dus: helemaal prima. Zolang het open-source is (waar Google best goed in is) heeft iedereen er profijt van.

[84hannes]

in Rust geschreven. Dat voorkomt volgens Google veel veelvoorkomende bugs zoals buffer overflows.

De brontekst gaat nog een stap verder:

since it eliminates entire classes of bugs, such as off-by-one errors and buffer overflows.

Heeft iemand enig idee hoe Rust zou kunnen voorkomen dat je een off-by-one error doet? Een for-each loop lijkt me niet iets dat uniek is voor Rust.

edit:
Voor de duidelijkheid: ik ken Rust, ik heb het gebruik en ik vind het geheugenbeheer geniaal, maar ik zie niet hoe het kan garanderen dat off-by-one errors plaatsvinden.

[Reactie gewijzigd door 84hannes op 22 juli 2024 19:49]

[RvR__]

Als je in rust iterators gebruikt (https://doc.rust-lang.org...-expr.html#iterator-loops) kan dat niet gebeuren. Natuurlijk kun je er ook voor kiezen (en in sommige gevallen noodzakelijk) om ‘gewone’ for loops te gebruiken.

[84hannes]

Als je in rust iterators gebruikt (...) kan dat niet gebeuren.

Als je in C++ iterators gebruikt kan dat ook niet gebeuren. Ik kan hetzelfde voor een heleboel andere talen zeggen, maar er zijn natuurlijk maar weinig talen geschikt voor een embeded-systeem, dus daar ben ik bereid Google ene klein beetje gelijk te geven.

Natuurlijk kun je er ook voor kiezen (en in sommige gevallen noodzakelijk) om ‘gewone’ for loops te gebruiken.

Ik ben wat gaan experimenteren, maar een gewone (indexed) for loop (uit C/C++/Java etc.) is in Rust eigenlijk alleen te implementeren met een while. Dan ben je wel door hoepels aan het springen om jezelf in de voet te kunnen schieten.
Bij een for range loop kun je makkelijk per-ongeluk bij 1 beginnen (in plaat svan 0), dat is een off-by-one.
In mijn eenvoudige voorbeeld is een iterator natuurlijk voor de hand liggend, maar ja, in mijn simpele voorbeeld is een fold of zelfs gewoon sum nog logischer.

Ik zoulwe willen concluderen dat Rust off-by-one-errors iets lastiger maakt dan C (al dan niet gecompiled met een C++-compiler), maar voorkomen is wel heel erg kort door de bocht.

[Reactie gewijzigd door 84hannes op 22 juli 2024 19:49]

[GertMenkel]

Ik denk dat het verschil is dat een off-by-one index bij Rust een ander effect heeft dan bij C++, tenzij je expliciet unsafe code aanzet.

Bij C++ zul je een stuk arbitrair geheugen terugkrijgen dat, afhankelijk van hoeveel geluk je hebt, gewoon 0 bevat. Bij Rust zal je programma met een panic() sterven. Hiermee zul je veel sneller bugs en problemen tegenkomen tijdens het debuggen omdat de code niet met foute waardes door gaat en per ongeluk een null meeneemt die tijdens het testen toevallig werkt. Ook meen ik dat de Rust vector iterators, mits op de juiste manier geschreven, wat veel mensen nog wel eens vergeten, een zero cost abstraction zijn. Dat wil zeggen: de compiler pakt je iterator en maakt er simpele array indices van. Bij C++ wordt die garantie voor zover ik weet niet gegeven. Wil je de performance van een directe lookup dan zul je in C++ eerder grijpen naar for loops met eventuele bound checks.

Bij C++ is een index out of bounds undefined behaviour, wat betekent dat als de compiler dit doorheeft je zal worden gewaarschuwd (mits je die waarschuwingen aan hebt staan) en de waarde die eruit komt zowel gelijk als kleiner dan als groter dan 0 is, want de compiler kan er niet meer over redeneren. Dat kan weer leiden tot hele rare optimalisaties.

Een gewone for loop kan middels "for i in 0..x {}" als je over een vector of array wilt itereren. Een foreach kan met "for x in lijst".

Voor embedded systemen zou ik de indexfouten niet zo op de voorgrond zetten, ik denk dat het voorkomen van use-after-frees op zulke apparaten eens stuk meer waarde zullen hebben.

[MSalters]

ALs je naar een populaire C++ implementatie kijkt als Visual Studio, dan zie je dat die ook range-checked iterators heeft. Alleen heet de snelle unchecked mode daar niet "Unsafe" maar "Release". En de build met range-checked iterators is " Debug".

Dat is ook ergens wel logisch. C++ code wordt nogal eens op miljoenen apparaten gedraaid, en om dan triljarden overbodige range-checks te doen is zelfs een milieu-probleem. Die call naar panic() kán niet zero-cost zijn; al was het alleen maar omdat je L1c cache gebruikt.

C++ (als standaard) garandeert inderdaad helemaal niets over de precieze implementatie van iterators. Dat is ook waarom een Debug build een range-check kan uitvoeren - het is meer dan een index. Een meer gebruikelijkere keuze is tussen array index en pointer - wat het beste is, kan van CPU tot CPU verschillen.

"Undefined behavior" betekent zeker niet dat de C++ compiler je waarschuwt. Dat is letterlijk wat de C++ standaard erove zegt: "No Diagnostic Required".

Use-after-free is overigens een typisch C probleem. Je ziet het ook al in de naam; free() is de C functie die bij malloc hoort. C++ heeft nog steeds new/delete, maar met std::make_shared<> en vector<> is dat hard overbodig geworden.

[84hannes]

Dat is ook ergens wel logisch. C++ code wordt nogal eens op miljoenen apparaten gedraaid, en om dan triljarden overbodige range-checks te doen is zelfs een milieu-probleem.

Dat er miljoenen apparaten zijn is een milieuprobleem, ik betwijfel of een paar promille meer energie gebruiken het verschil gaat maken.

maar met std::make_shared<> en vector<> is dat hard overbodig geworden.

Deze lijst gaat niet compleet worden, maar in mijn ervaring is een unique_ptr vaak genoeg en is een shared_ptr zelde nodig. Dat komt ook overeen met mijn Rust-ervaring, waarin je bijna altijd weg komt zonder het gebruik van Rc<T> een uitzondering is.

[Reactie gewijzigd door 84hannes op 22 juli 2024 19:49]

[VanStino]

Deze vraag stelde ik mezelf ook. Ik heb nog nooit bij een off-by-one bug gezegd "dammit Javascript!", want zo'n bug heb ik altijd enkel aan mezelf te danken. Hoe kan een programmeertaal inherent dergelijke issues voorkomen? Lijkt me onmogelijk.

(EDIT: en bij JS is er genoeg andere weirdness om op te vloeken, maar dat is naast de kwestie)

[Reactie gewijzigd door VanStino op 22 juli 2024 19:49]

[rubanooo]

Zie deze interessante video over hoe rust er voor zorgt dat je code altijd werkt:

https://www.youtube.com/watch?v=Q3AhzHq8ogs

[brrrbaybay]

Geen Rust expert hier, maar voor zover ik kon vinden:

Prevent off by one errors:
"It can't really.. however the preference for "zero cost" iterators lessens the frequency with which you work with raw indices, so there's less opportunity to bungle things."

Klinkt logisch, en zoals altijd blijft de developer verantwoordelijk om geen domme dingen te doen

[Reactie gewijzigd door brrrbaybay op 22 juli 2024 19:49]

[berchtold]

al zijn domme dingen doen bijna niet mogelijk in Rust.

[brrrbaybay]

Ben heel benieuwd. Rust staat sowieso nog op m'n lijst om een keer mee te spelen, en als je het zo zegt ben ik geneigd om die uitdaging aan te gaan

[Sandor_Clegane]

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

[Sjekster]

Dank voor het lachen!

[Raymond Deen]

Van mij ook een dank je wel

[beerse]

.... Start counting at 0?

[MiesvanderLippe]

Ik vond deze video verhelderend over dit onderwerp:

Rust is not a [faster] horse
https://www.youtube.com/watch?v=4YU_r70yGjQ

Gaat in op waarom het niet een verbetering is van een andere taal maar sommige concepten (waarin ook veel cruciale fouten gemaakt worden) fundamenteel anders aanpakt.

[GeertBoer]

Rust forceert ook exception handling: Je moet variabelen namelijk 'uitpakken'. Bij dat uitpakken moet je aangeven hoe je je eventuele exceptions handlet, je kan dat niet niet doen. Heel kort door de bocht...

Rust is echt een prachtige programmeertaal. De compiler is streng, het dwingt bepaalde syntaxen af, maar als je eraan gewend bent kan je eigenlijk geen memory fouten meer maken. Ik ben fan.

[Reactie gewijzigd door GeertBoer op 22 juli 2024 19:49]

[m3gA]

Iemand een praktijkvoorbeeld waar dit geschikt voor zal zijn? Kan me even niks voorstellen.

[joost00719]

Slimme deurbel/camera/alarmsysteem. Genoeg toepassingen hiervoor.

[m3gA]

Beeldherkenning oa dus.

[84hannes]

Uit de bron:

If the devices around us can't be mathematically proven to keep data secure, then the personally-identifiable data they collect—such as images of people and recordings of their voices—could be accessible to malicious software.

Dat klinkt inderdaad als slimme deurbellen/beveiligingscamera's, zoals @joost00719 al aangeeft, en microfoons/camera's voor Google Assistent. Die zouden met behulp van machine learning wellicht grotendeels offline kunnen werken.

[zenlord]

Naast de beveiligingscamera's en slimme deurbellen die al aangehaald zijn, is het toch een trend dat meer en meer devices slim worden, en eens ze slim zijn, zal er ML aan toegevoegd worden om ze nog slimmer te maken: koffiezet, microgolf, frigo, maar waarom ook niet garagedeur, fiets, vaas of straatverlichting?

[Timvddriesschen]

Kan iemand mij een voorbeeld geven van een concrete toepassing? Ik ben erg benieuwd!

[novasurp]

Is dit voor apparaten waar Fuschia te zwaar voor is?

[n0np3r50n]

Ik dacht eerst seL4 is een 'secure linux iets' maar dat is helemaal niet zo.

L4 microkernel family
http://os.inf.tu-dresden.de/L4/
L4 is a family of second-generation microkernels, used to implement a variety of types of operating systems, though mostly for Unix-like, Portable Operating System Interface compliant types. L4, like its predecessor microkernel L3, was created by German computer scientist Jochen Liedtke as a response to the poor performance of earlier microkernel-based OSes

The seL4® Microkernel, https://sel4.systems/

[Reactie gewijzigd door n0np3r50n op 22 juli 2024 19:49]

[-=bas=-]

Al bekend wanneer zit dit project op de schroothoop gooien?

[CH4OS]

Staat eigenlijk al een beetje in het artikel, maar wanneer men de hardware veilig genoeg vindt.

[MarvinMaker]

Idd, maf dat ze daar nu mee beginnen, ze hebben net EOL van hun IOT platform aangekondigd..

Maar misschien juist dat de reden om het open source te maken.

[Yzord]

Geen haar op mijn hoofd dat ik een iot os gemaakt door Google op mijn iot devices ga zetten.

Ik hou het liever op open source, maar vooral ook zo lang mogelijk buiten mijn huis. Het is nu al niet bij te benen in welk apparaat een mic heeft zitten.

[TheVivaldi]

Maar dit OS van Google is toch ook open source? Of is GitHub ineens geen opensourcebron meer?

[luxebenen]

Her is niet helemaal open source:

Internally, KataOS also is able to dynamically load and run third-party applications built outside of the CAmkES framework. At the moment, the code on Github does not include the required components to run these applications, but we hope to publish these features in the near future.

[TheVivaldi]

"At the moment" "but we hope to publish these features in the near future". Dus ze zijn er wel mee bezig om de resterende delen te open sourcen.

[bons]

Heeft dit project dan wel een houdbaarheid van meer dan 2 jaar, of staat dit dan ook op het lijstje van Killed by Google ?

Edit: ik kan wel een -1 krijgen, maar het is wel een reëel kans dat dit werkelijk kan gebeuren. Voor een degelijke IOT-OS is zijn (security )updates zeer belangrijk, anders wat is het toegevoegde waarde dan de andere 99.999 dat ook al op de markt aanwezig zijn?

[Reactie gewijzigd door bons op 22 juli 2024 19:49]

[PageFault]

Ik gaf je zeker een +1 omdat er al zoveel projecten op de Google Graveyard zijn geeindigd. En wat je zegt: straks stoppen ze binnen 3 jaar met security updates en dan hoor je iedereen huilen...

[maali]

zijn ze Fuchsia alweer vergeten?

[Rafe]

Ik was ook even in de war, maar na het bijlezen van nieuws: Google stelt Fuchsia OS voor Nest Hub Max beschikbaar lijken Fuchsia OS en KataOS net iets andere doelwitten te hebben (ARM vs RISC-V, wel of geen GUI, etc)