Intel ontwikkelt op veiligheid gerichte Linux-distributie voor drones en robots

Imad Sousou, die bij Intel aan het hoofd staat van het Open Source Technology Center, heeft aangekondigd dat de chipmaker werkt aan een Linux-distributie binnen het zogenaamde Intel Safety Critical Project for Linux. Het OS is onder meer bedoeld voor industriële drones en robots.

In een aankondiging schrijft Sousou dat het project gebaseerd zal zijn op Clear Linux. Dat is een door Intel ontwikkelde distributie die zich richt op aanpasbaarheid en gebruikmaakt van bundles in plaats van individuele packages, waarbij een dergelijke bundel bestaat uit meerdere upstream opensourceprojecten. Ook verloopt updaten anders dan gewoonlijk. Het is bijvoorbeeld niet mogelijk om een deel van het systeem te updaten zonder een volledig nieuwe OS-versie te installeren. Die versies hebben versienummers bestaande uit één getal, waarbij releases met hetzelfde getal precies dezelfde softwareversies draaien, aldus Intel.

Volgens Sousou moet de nieuwe distributie zich verder onderscheiden door het snel kunnen uitbrengen van updates en een 'sterk geautomatiseerd releaseproces'. Het is de bedoeling dat het OS wordt gebruikt in systemen als industriële drones, fabrieksrobots en zelfrijdende voertuigen. Uiteindelijk is het de bedoeling dat er twee releases per dag plaatsvinden, net als bij Clear Linux. Intel vraagt ontwikkelaars en andere bedrijven zich bij het initiatief aan te sluiten. De broncode ervan is open source, met uitzondering van informatie met betrekking tot Intels eigen hardware. Er is een mailinglijst in het leven geroepen, al zijn daar tot nu toe nog geen berichten op verschenen.

Reacties (39)

[jpsch]

Het is bijvoorbeeld niet mogelijk om een deel van het systeem te updaten zonder een volledig nieuwe OS-versie te installeren

'sterk geautomatiseerd releaseproces'.

Uiteindelijk is het de bedoeling dat er twee releases per dag plaatsvinden,
=============
Dus je krijgt een systeem waarbij je (grotendeels) geautomatiseerd twee maal per dag je het volledige OS vervangt? Is dat juist niet een kwetsbaarheid?

[M14]

Waarom denk je dat het een kwetsbaarheid is? Het alternatief is delen updaten en hopen dat het allemaal compatibel met elkaar is.

[Bor]

Het alternatief is inderdaad gedeeltelijk updaten of niet updaten. Ik zie ook niet in waarom dit juist kwetsbaar zou moeten zijn. Je hoeft elke update natuurlijk niet te installeren. Deze behoor je zelf ook nog te testen. Hierbij gaat het om een OS voor redelijk beperkte systemen zoals drones en robots. Daar is het nu ook al niet gebruikelijk om slechts gedeeltelijke updates uit te voeren of patch jij bij een drone bv drivers voor hardware afzonderlijk? Kijk dus ook naar de toepassing.

[scsirob]

Dan vraag ik me eerder af of het handig is om een monolitisch general purpose O/S als Linux met alle bagage en daarmee potentiele security issues in te zetten. Juist bij dit soort toepassingen zie ik meer in een microkernel en strak gedefinieerde services die in sandboxes hun ding kunnen doen. Als er dan eens iets lek blijkt, dan hoeft alleen die service een update te krijgen.

[janbaarda]

Misschien is CircuitPython voor dit soort toepassingen een betere oplossing? Direct een hogere programmeertaal in microcode. (en met een Nederlandse oorsprong)

[jpsch]

Zelf denk ik dat 't kwetsbaarder is, juist omdat je zo vaak kunt updaten en het grotendeels geautomatiseerd is. Lijkt me dan zo routinematig te worden, dat het het zwakke punt wordt wat bij een eventuele aanval door kwaadwillenden. Dat staat los van delen of geheel updaten, hoewel bij geheel updaten je natuurlijk ook de beschermingsconstructies van het OS gemakkelijker getroffen kunnen worden, die stuur je inmiddels mee.

[M14]

Continuous delivery is volgens mij het principe wat hier wordt gebruikt. Wanneer een bug wordt gevonden is direct duidelijk welke combinatie van software is gebruikt, wat het vinden en fixen ervan een stuk makkelijker maakt.

Alles in een volgende release moet compatibel met elkaar zijn. Is dat niet, dan heb je een volgende bug te pakken.

[Verwijderd]

Het releasen van een update wil niet zeggen dat je die update ook door moet voeren op je systeem.

[jpsch]

Klopt, maar als je een maandje niet update, lig je dus 60 releases achter. Die 60 releases lijken me niet allemaal cosmetisch voor een OS dat juist veilig moet zijn.

[tweaknico]

maar je hoeft niet 60 maal te updaten om weer een consistente set te krijgen.

[jpsch]

Klopt, Windows95 van de installatie cd-rom is ook nog steeds consistent.

[spNk]

Je kan toch ook gewoon van Windows 10 1507 naar 1803 updaten?

[Euwas]

Nee dat zie ik niet als een kwetsbaarheid, eerder een sterk punt wat in de industrie vaker voorkomt. Je kan dan een A en een B systeem hebben waarbij je altijd een volledig systeem op één kant hebt. De bootloader kiest A of B afhankelijk van welke nieuwer is. Mocht na de update het systeem niet starten (bijvoorbeeld door watchdog detectie oid) schakel je terug naar de vorige versie. Het wordt daamee atomic updaten.

Als je bedoelt dat door de grote hoeveelheid updates meer kansen aanwezig zijn om software te injecteren valt dat ook mee denk ik, alles kan natuurlijk gesigneerd zijn en alleen starten als het van Intel zelf afkomstig is.

Ofwel, het systeem wordt stabieler (nooit dependencies die verschillend van elkaar getest zijn) en snelle opties voor updaten

[zarex]

Mee eens, als je dit combineert met A/B in de bootloader is het prachtig.

[Jaap deLux]

Nee, dat lees ik daar niet. Er komen twee releases per dag, en het releasen gaat sterk geautomatiseerd.

Maar die hoef je niet te installeren. Die kan je installeren, wanneer je daar een reden voor hebt.
Zoals altijd.

[Jerie]

Het aantal releases per dag zegt niets over de kwaliteit van de software of hoe goed de software is getest. Het betekent in dit geval eerder dat je, nadat een kwetsbaarheid gefixed is, je maximum 12 uur zonder security patch zit.

Waarschijnlijk gebruiken ze gewoon Jenkins of Travis https://en.wikipedia.org/wiki/Continuous_delivery

[Reactie gewijzigd door Jerie op 23 juli 2024 04:31]

[toro]

Intel en veiligheid?

Sorry, dat gaat bij mij wel even duren voor dat ik dat serieus ga nemen weer

[Sandor_Clegane]

Snap niet dat je een min krijgt, dit was ook mijn eerst gedachte. Helemaal als je ziet wat nota bene Linus over Intel te zeggen heeft over de kwaliteit van Intel patches voor de Linux kernel.

[toro]

Raar van die min inderdaad

Linus was furieus er over. Intel heeft het probleem qua CPU lekken afgeschoven op de kernel hackers van de BSD/Linux community. Het is een behoorlijke schande wat er gaande is.

Ik denk dat dit met deze distro schone schijn is en dat men damage control aan het doen is.

[FreezeXJ]

Intel is best wel groot, en de marketing-afdeling, hardware-optimalisatie en software-afdeling hebben allemaal hun eigen agenda, die behoorlijk verschillend is. Intel draagt flink bij aan de Linux kernel, maar op sommige vlakken meer dan andere. Qua CPU-lekken hebben ze heel weinig gedaan, wellicht deels omdat zij ook overvallen werden door het probleem, of omdat de hardware-afdeling te weinig informatie gaf. Marketing en voorlichting gaat er ook hard achteruit (zie Anandtechs EdOp van vandaag)...

Clear Linux van de andere kant komt van hun software-afdeling, en begint langzaam maar zeker op stoom te komen. Ja het wordt gepushed door een groot bedrijf, maar datzelfde geldt voor Android... of Microsoft (die ook flink aan de Linux-weg timmeren). Ik schrijf ze nog niet af.

[tweaknico]

Het probleem is dat je niet "even" alle CPU's kan vervangen..., dan moeten die ook nog eerst ontwikkeld
getest en gebouwd worden. En de CPU's die je dan krijgt zullen wat trager zijn dan de huidige generatie....
De problemen die door "Speculative Execution" ontstaan zijn moeten dus zoveel mogelijk in een laagje erboven aangepakt worden. (Firmware staat ook boven HW overigens).. maar Speculative Execution uitschakelen zul je niet willen.... en niet alle instructies kunnen aangepast worden.

Zoals wel vaker blijkt is speculatief handelen niet altijd even bedrijfszeker.

[Cerberus_tm]

Idealiter zou je speculatieve uitvoering per proces aan- en uitzetten; dan zou je het standaard uit kunnen zetten en alleen toestaan voor bepaalde, vertrouwde processen, zoals alles van Microsoft, bepaalde spellen, je IDE, Photoshop (ik heb geen idee bij wat voor toepassingen het de meeste tijdswinst geeft), maar het niet toestaan voor de browser of andere programma's.

[tweaknico]

En dan via een DLL injectie er toch nog gebruik van kunnen maken?....
En dan moet je bij elke context switch ook een firmware reload doen... ouch...

[Cerberus_tm]

Ik weet ook niet of het practisch zou zijn. Je kunt misschien van een DLL twee versies maken, één die alleen door vertrouwde processen gebruikt mag worden, en één die door alle andere processen gebruikt wordt en die niet mag speculeren? Zo zoiets althans in theorie mogelijk zijn?

[MSalters]

Dat is compleet onlogisch, sorry. Het probleem is nu dat er informatie van het ene proces naar het andere proces lekt, ook al draaien die processen met andere Security Credentials. Dat komt omdat security op OS nivo geregeld wordt, en de CPU dus niet weet wanneer de Speculative Execution informatie afgeschermd moet worden bij een process switch. Binnen een enkel proces is er geen security risico.

(Dat wil zeggen, onder de aanname dat je third-party Javascript in een sandbox proces draait. Oude browsers blijven een risico apart; met hun Javascript VM zijn ze een soort mini-OS.

[Cerberus_tm]

Daarom lijkt het mij dus ideaal als dat wel zo kunnen, wanneer de processor dat dus wel zou weten. Dan zou je de winst van de speculaties kunnen behouden.

[MSalters]

Het probleem daarmee is dan weer dat je het security model in silicium vastlegt, en het OS geen keus geeft. Dat is misschien weer een groter risico; een OS is veel makkelijker te patchen.

Als deze Speculative Execution issues zouden óók opgelost kunnen worden door een Ring-0 instructie om alle caches e.d. te legen. Het OS kan dan zelf beslissen bij welke task-switch die instructie nodig is, terwijl de CPU niets van de precieze processen hoeft af te weten. Misschien zou er ook een Ring-3 variant moeten zijn voor VM's, of een syscall die hetzelfde doet, dat zou je nader moeten bekijken,

[GiLuX]

snap ik.
maar clear linux is ook heel erg geoptimaliseerd voor snelheid en veegt wat dat betreft de vloer aan op vele vlakken met bv ubuntu en fedora:
https://www.phoronix.com/...1804-fedora28-clear&num=1

[Sandor_Clegane]

Lees die zin nog eens door Intel, optimaliseren.......
Misschien kunnen ze zo de performance drain van die spectre fixes weer ongedaan maken.

[ELD]

Dit OS is dan niet voor Intel processors neem ik aan

[zarex]

Meh - het zal open source zijn, *want* GPL-licentie. Ik verwacht niet dat er heel veel zal zijn wat je tegen gaat houden om dit te compileren voor ARM. Of misschien komt intel met een ARM implementatie???

Daarnaast heeft intel ook andere producten dan CPU's. Ik ben sowieso wel benieuwd wat voor verdien model hier achter zit.

[Reactie gewijzigd door zarex op 23 juli 2024 04:31]

[MSalters]

Het kan wel Open-Source zijn, maar als Intel de code vol met AES-NI instructies heeft gepropt dan gaat het niet veel op ARM doen.

[Euronitwit]

Toen ik de titel las dacht ik aan de wetten van de robotica van Isaac Asimov
Die veiligheid vind ik eigenlijk belangrijker.

Eerste Wet
Een robot mag een mens geen letsel toebrengen of door niet te handelen toestaan dat een mens letsel oploopt.
Tweede Wet
Een robot moet de bevelen uitvoeren die hem door mensen gegeven worden, behalve als die opdrachten in strijd zijn met de Eerste Wet.
Derde Wet
Een robot moet zijn eigen bestaan beschermen, voor zover die bescherming niet in strijd is met de Eerste of Tweede Wet.

[Noxious]

En vergeet niet: "Asimov once added a "Zeroth Law"—so named to continue the pattern where lower-numbered laws supersede the higher-numbered laws—stating that a robot must not harm humanity."

Allemaal leuk en aardig natuurlijk voor sci-fi, maar in de praktijk betekenen deze wetten dat een AI een begrip moet hebben van heel veel zaken om dit te kunnen laten werken (waaronder een 'ik', mensen/mensheid, enz..). Zo ver zijn we nog lang niet.

[WienerBlut]

Klinkt spannend! Maar vanuit het perspectief van Safety Critical en Software Assurance ben ik heel benieuwd hoe 2 releases per dag ermee te rijmen valt... Weet iemand dit? Vindt het testen van kwaliteit en integriteit ook "rock solid" geautomatiseerd plaats?

Ik doel hier bijv. op DO-178B https://en.wikipedia.org/wiki/DO-178B

Edit: extra zin voor aviation

[Reactie gewijzigd door WienerBlut op 23 juli 2024 04:31]

[davekok]

Doet Debian niet ongeveer hetzelfde!?

[tweaknico]

Er zijn best wel veilige Intel CPU's
4004, 8008, 8080, 8085, 8088, 8086, 80188, 80186, 80286, 80386, 80486... en enkele van de eerste Pentiums.
Naast wat ARM en andere architecturen zoals Itanium, en 432. Allen zonder issues met betrekking tot Speculative Execution.

[Reactie gewijzigd door tweaknico op 23 juli 2024 04:31]