Ze komen er ook een keer achter. Eindelijk. Alleen, wat gaan ze eraan doen?

Dit probleem is groot, iedereen met een beetje verstand die weet ervan, maar nog een veel groter probleem is dat het allemaal closed source is. Maar of ze daar ooit achter komen, dat betwijfel ik omdat er nogal wat belangen zijn.

No shit, Sherlock!

En ondertussen moet alles maar 'smart' en hebben we in Nederland zelfs een digibeet voor digitalisering.
Toch fijn dat mijn TV gewoon niet aan internet hangt. En mijn wasmachine en koelkast ook niet. Net zo min als de thermostaat, CV, auto of voordeurbel.

Vind je het gek, dat het closed source is? De firmware is bedoeld om de hardware te laten communiceren met het OS en bevat dus informatie die te maken heeft met het ontwerp van de hardware. Ieder bedrijf dat zijn eigen hardware ontwerpt, zal de kennis daarover willen beschermen, om hun voorsprong te bewaren.

En wat is het voordeel, wanneer dit open source is? Je eigen firmware ontwerpen, zodat alles beter werkt? Dan moet je eigenlijk al bij het bedrijf werken, om te weten wat nog mogelijk zou zijn, maar nu niet gebruikt wordt.
Het met een review van de firmware vinden van lekken? Goed bedoeld, maar ook dat vergt veel kennis van de hardware, want een commando kan alleen een lek bevatten, wanneer de hardware ook kan reageren op een manier die anders is, dan de bedoelde manier.

Ken jij de Linux kernel of de OpenBSD kernel? Die zijn gebouwd op onder andere de X86 of ARM hardware. De specificaties daarvan zijn gepubliceerd en daarom werkt het geheel. Was dat niet het geval (zoals bij nvidia bv) dan moet je inderdaad maar wat aanklooien. Maar de vele mensen die werken aan bv de Linux kernel die zijn allemaal specialisten en worden zelfs geholpen door de leveranciers van diezelfde hardware. En dat heeft ook serieuze consequenties voor de specialisten want op Linux zitten wel veel bugs natuurlijk, maar daar is wel een stringente controle op.

Maar goed, zo kijk ik op de gang van zaken.

Dat zijn instructiesets die nog niets zeggen over hoe de instructies geïmplementeerd zijn in de CPU. CPUs gebruiken technieken als microcode en micro-operaties. Bij microcode worden instructies vertaald in instructies op het niveau van elektronische circuits, denk aan bitmaskers die aangeven welke circuits op de CPU geactiveerd moeten worden voor een bepaalde instructie. Bij micro-operaties worden instructies uit de gepubliceerde instructieset vertaald naar een of meerdere instructies die de buitenwereld niet te zien krijgt, dan ga je van een CISC- naar een RISC-achtige instructieset. Hoe het intern werkt kan per processor of processorfamilie verschillen. ARM werkt met micro-operaties, X86 met een combinatie van microcode en micro-operaties.

De instructieset van een CPU is dus eigenlijk niets anders dan een communicatieprotocol om met de CPU te communiceren. Het is een interface. Het geheel werkt omdat deze interface-specificaties zijn gepubliceerd en voor vele CPUs worden hergebruikt. Wat voorbij de instructieset gebeurt, hoe de CPU de instructies afhandelt, is bedrijfsgeheim, closed hardware.

Dat is heel vergelijkbaar met hoe een closed source besturingssysteem een publieke API (application programming interface) heeft zodat ontwikkelaars software voor dat besturingssysteem kunnen maken. Dat maakt het besturingssysteem niet open, en een gepubliceerde instructieset maakt de hardware niet open.

Open source besturingssystemen hebben net zo goed een API, een publieke API staat los van de vraag of het onderliggende besturingssysteem open of closed source is. Op dezelfde manier staat een publieke instructieset los van de vraag of de achterliggende hardware open of closed is.

Ja, want de hardwarefabrikanten hebben er baat bij als hun hardware goed presteert in combinatie met besturingssystemen. Dat levert gebruikers en dus klanten op.

Ze werken ongetwijfeld ook nauw samen met Microsoft zodat Windows goed werkt. En de vergelijking met APIs van besturingssystemen gaat ook hier weer op: Microsoft werkt ook nauw samen met allerlei leveranciers van applicaties om het geheel goed te laten werken. Alweer omdat dat gebruikers en dus klanten oplevert.

Zie je de overeenkomst? De instructieset van een CPU en de API van een besturingssystem zijn allebei interfaces. Een goede, publieke specificatie van een interface maakt dat dingen goed samenwerken (als ze verder ook goed geïmplementeerd zijn, natuurlijk), ongeacht of wat er achter die interface zit open of closed is.

Als je bij software (bijvoorbeeld een besturingssysteem) redeneert dat het pas open is als de broncode zelf open is en bij hardware (bijvoorbeeld een CPU) het al open vindt als alleen de interfacespecificatie open is dan meet je met twee maten. Dat doe je niet bewust, vermoed ik, ik denk dat je nog wat inzichten miste over hoe dingen eigenlijk in elkaar zitten.

Ik snap niet wat je hiermee wilt zeggen.

Ik hoop dat ik je kijk op de gang van zaken iets heb kunnen verhelderen met mijn uitleg.

Dit staat er in het document, waarschijnlijk uit de koker van Microsoft want daar luisteren ze naar.
Gaat natuurlijk om log4j wat weinig schade heeft veroorzaakt itt tot het niet genoemde grote closed source incident: solarwinds
Ongelooflijk de lack of a single responsible entity (met een onbereikbaar 06 nummer) zou een nadeel zijn!
Dit komt zeker uit koker van de closed source lobbyisten.
Ze willen niet weten dat er een heel mooi initiatief is:
https://www.linuxfoundation.org/press-release/the-openssf-and-the-linux-foundation-address-software-supply-chain-security-challenges-at-white-house-summit/

Lijkt erop dat in dit artikel met firmware voornamelijk UEFI wordt bedoeld en de stelling dat veel leverancier die programmatuur zelden bijwerken, ook al zijn er problemen in aangetroffen, klopt wel in grote lijnen (macOS updates werken de firmware overigens wel vaak bij). De verbinding met OSS en het voortbrengingsproces gaat echter mank: vrijwel alle UEFI implementatie zijn namelijk closed source.

Waar firmware (en OS) wel als OSS wordt ontwikkeld biedt het voortbrengingsproces juist vaak uitgebreide procedurele waarborgen: vier-ogen, multiple review vereisten, CI-test, organisational governance, aan disclosure voorgaande informering van downstream implementatoren enz enz enz. Blijkens aantoonbaar gebrekkige UEFI implementaties heeft veel closed source systeemontwikkeling wat dat betreft haar zaken minder goed voor elkaar.

Kortom, het onderstaande stukje tekst moet worden afgedaan als lariekoek.

Dat komt omdat de overheid alleen met machtige closed source bedrijven rond de tafel zit en OSS een bedreiging is voor die bedrijven.

Diezelfde grote bedrijven maken ook graag te pas en te onpas gebruik van open source als het ze zo uitkomt.