Sorry, aber die wichtigen Fragen werden kaum gestellt, stattdessen eine alternativlose Sprache beschuldigt:
a) Die Rust Unterstützung für Windows Treiber gibt es, wenn ich das auf github richtig gesehen habe, seit Sept. letzten Jahres (Version 0.1). Soll nun so ein kritischer Treiber mal schnell in 9 Monaten auf Rust portiert und ins Feld geschmissen werden? Basierend auf einem preliminary DDK (driver development kit)? Da sind dann garantiert weniger Fehler drin, ist ja dann wenige Tage getestet... -> C++ aktuell noch alternativlos...
b) Jede Software hat Fehler, und damit muss man spätestens bei kritischer Infrastruktur rechnen. Wo ist also spätestens da das Staging? In welcher Risikobetrachtung hat man fehlerhafte Treiberupdates übersehen?
c) Schnelle Updates schön und gut, aber bitte für Virus definitions in user space. Also wo ist die Trennung zwischen dem (unverzichtbaren) Kernel Treiber, rocksolid, alle paar Monate mit einem Update, getestet mit Staging und langsamer Einführung ins Feld und dem schnellen Updates der Virus definitions, die aber nichts im Kernel Treiber zu suchen haben (in meinen Augen). Oder werden neue Virus-definitions direkt händisch in C++ gehakt und in den Kernel Treiber geschmissen? Ernsthaft?
d) Endpoint Security vs. Schlangenöl: Ich hab mich für meine Firma lange damit auseinander gesetzt und finde: Die Filter gehören vor den Endpoint, nicht auf den Endpoint. Bescheuerte Terminals, die am Ende nicht mal mehr machen als im Browser Infos von einem firmeninternen Browser anzuzeigen, die müssen einfach in ein VPN / VLAN etc. ohne Zugriff von außen. Stattdessen schmeißt man alles in ein Netz, aber dann Endpoint security... Umgekehrt werben die sogar damit, permanent Portscans auf alle Rechner im Netz zu machen, Adminkonsole etc. Äh, toll, lieber mache ich mein Netz dicht, hab keinen solchen Single point of failure und grenze die Ausbreitung ein. Aber ist ja viel praktischer. Netz offen wie ein Scheunentor, jeder hat Zugriff auf alles, aber Endpoint Security wird es richten, muss halt nur alle 2h den Treiber updaten.
e) Wie zur Hölle können die einen so tief liegenden Treiber ohne Neustart aktualisieren? Das muss doch schief gehen, oder übersehe ich was? Das waren *.sys Dateien, also Treiber? Oder laden die Code zur Viruserkennung die ganze Zeit in den Kernel nach? Mir ist die Architektur nicht ganz klar. Ein Filtertreiber soll nur filtern / ausleiten, aber bitte nicht alles im Kernel machen. Oder hatten nur Kisten den BSOD, die neu gestartet sind? Oder hat man nur auf 'frischen' Kisten bei Crowdstrike getestet, die den Treiber im Bootprozess geladen haben? (aber naja, da hat es den ja auch abgeschossen...)
f) Bin mal gespannt wie viele Hackergruppen nun überlegen, irgendwie eigene Updates in so einen weltweiter SPOF (single point of failure) einzuschleusen. Das wäre der Jackpot für jeden staatlichen Akteur... Muss ja so oft aktualisiert werden, dass man kein staging macht, nix prüft etc. Sorry, aber Risikomanagement sieht anders aus. Schnelle updates der Virus definitions dürfen NIEMALS in der Lage sein, einen Kernel Treiber zum Absturz zu bringen. Und Kernel Treiber müssen zigfach getestet sein, bevor sie solche Verbreitung finden und durch Staging gehen. Sowas müsste aus jeder Risikobetrachtung heraus kommen. Spätestens aus der von Crowdstrike, sonst haben sie sich wirklich zum Schlangenöl degradiert!
Aber C++ kann da am wenigsten dafür, da muss man ganz andere Dinge hinterfragen!
Und die richtigen Fragen scheint man sich nicht mal bei kritischer Infrastruktur zu machen.