Modernare programmeringsspråk ska göra Windows säkrare

ReFS är inte nytt, det är 10 år gammalt. Jag har kört det på diskar som inte är systemdisken i perioder, men någon av Win 10-uppdateringarna tog bort stödet.

Sen skall det sägas att det de gjort hittills är att byta ut kernel-kod som är C++ mot Rust. De har inte bytt ut någon C-kod, vad jag kan se.

Problemet är väl att Rust är minnessäkert och valideras när kompilationen sker, det ger språket möjlighet att ta bort massor med kontroller och checkar från när processen kör (och därmed göra körningen snabbare)

Men det är väl ganska långt från samma sak som att det inte skulle gå att attackera program skrivna i Rust, eftersom hela idén är att lita på att binären är säker och inte kontrollera i realtid borde det inte vara omöjligt att få den att göra helt andra snedsteg efter att man skrivit om lite minne eller så, och sällan är ju en hel tech-stack enskilt skriven i Rust

På tal om stabilitet i Windows 11. Såg av en slump att Microsoft Edge hade typ 37 processer öppna i bakgrunden i Task Manager, när jag stängde processerna så fick jag BSOD. Happ.

Är inte det onödigt när det kommer en ny version snart...?

Eftersom vi så snabbt sket i Windows 10 (som faktiskt fungerar till skillnad från Vista 2.0), så varför lägga den energin på W11 när man faktiskt kan göra om och göra rätt med Windows...14(?)

Du menar att varje Windows-version är omskriven från början?

Givetvis kommer mycket av den refactoring som sker i Windows 11 föras vidare till Windows 12.

Windows 11 fungerar alldeles utmärkt! Att påstå något annat... ptja... vill man vara snäll kallar man det placebo, vill man vara ärlig kallar man det dumheter.

Man skriver inte om en kärna hel varje gång man släpper en ny version av Windows. Kärnan i Windows 12 har fortfarande kod från windows NT-tiden. Och kod som skrivs idag kommer finnas i Windows de nästkommande 20 åren också.

Menar du att C++ har dessa "kontroller och checkar" under runtime? C++-kompilatorer kollar också syntax och annat under kompilering. Jag förstår inte din första mening eller vad som är ett problem.

Har därtill inte läst "säkert" nånstans, i absoluta termer, utan snarare att det är enklare att koda bra minneshantering och ex multitrådat med Rust än C++ eftersom mycket modernare språk, med bibehållen prestanda. Jag vet inte vilken "kontroll i realtid" som finns iom C++ eller "inte omöjligt att göra helt andra snedsteg", som att det inte är nån vits att byta till ett tjugo år modernare språk, trots att Linux-kernel lutar åt samma håll (om än långsamt) och att MS är ett stort företag.

Nja, men det har väl chans att bli det. Senast jag kollade fanns det fortfarande rätt många områden där de inte rekommenderade att köra det här filsystemet.

Men om de äntligen bestämt att filsystemet är redo för massorna är det väl bara att säga grattis och välkommen till 00-talet, Microsoft, där riktiga filsystem vet vad de skrivit! 🙃

Det är så Chromium funkar som driver Edge, Chrome osv. Det är en multi-process arkitektur där varje tab o extension lever som egen process. BSOD är ju skit såklart men 37 processer för Edge är inget att direkt oroa sig för egentligen om man har lite tabbar o några extensions, om de nu var oklart.

Misstänker att @Yoshman kan ha en del intressant input här 😎

Om man inte har hårdvarufel ska inte ett program i user space kunna få en modern operativsystemskärna att balla ur. Den alternativa förklaringen, som jag hoppas inte stämmer, är att Microsoft inte lärt sig av sin historia av säkerhetshål och av någon idiotisk anledning gett en webbläsare en bakdörr in i operativsystemets allraheligaste…

Man får ju naturligtvis inte bort alla buggar och säkerhetshål bara för att man skriver i Rust, men många av de vanligare felen i C program som ofta leder till säkerhetsproblem slipper man om man använder Rust, varpå man kan lägga mer energi på att hitta och fixa de återstående typerna av problem.

Det är ju knappt så att grafikdrivrutiner gör detta nu mer, spelen kraschar inte äns när detta händer.

Hade en Twitch stream på sammtidigt som jag satt och spelade Quake här om dagen.
Rätt som det var så laggade spelet till och streamen kraschade, varpå jag fick meddelande om att drivrutinen hade kraschat.
Jaha, tänkte jag, startade streamen igen, tabbade in i spelet och fortsatte spela.

Njae? Tycker det känns väldigt bakvänt med ingångsvinkeln att detta skulle vara "problemet".

Jag skulle snarare se det som att språk, exempelvis just Rust men även andra liknande initiativ, som faktiskt säkerställer säker minneshantering verkar vara en i praktiken nödvändig, men kanske inte i alla lägen tillräcklig, del av lösningen om vi nu ska få en förändring av den beklämmande trenden vi haft i decennier.
Utgår här från "facit" sett till hur det ser ut i dagsläget, där sårbarheter orsakade av minnesfel i främst C++- och C-kod fullkomligt dominerar.

I teorin går det förstås utmärkt att skriva säker kod även i t.ex. C eller C++, men eftersom det som krävs är i princip "tänk på att göra rätt i varje situation, överallt, hela tiden, annars är du rökt" så ser det också ut som det gör... Eftersom folk gör misstag hela tiden så är vi också allihopa kollektivt rökta hela tiden, och är beroende av en aldrig sinande ström av säkerhetsuppdateringar.

Sedan är ju mycket av det Rust gör att faktiskt se till att principer för säker minneshantering är en strukturell del av själva språket och därmed faktiskt efterlevs som en naturlig följd av hur koden skrivs. Man har en definierad livscykel för minnesallokeringar t.ex., inte adhoc-hantering där det inte bara är fullt möjligt att göra fel, det är samtidigt jättesvårt att identifiera alla tänkbara fel eftersom de språkens faktiska regler tenderar att vara väldigt tillåtande.
Man har då t.ex. ownership-konceptet som är fundamentalt för hela språket, som väl kan ses som RAII-upplägget och några principer till, alltihop taget till nästa nivå.

Så jag tycker inte riktigt att det känns riktigt rimligt att få det till att mycket av minnessäkerheten säkerställs redan vid kompileringstillfället skulle vara ett problem. Det är snarare till stor del att man eliminerat adhoc-hanteringen där folk hela tiden hittar vägar att skjuta sig i foten tusen och åter tusen ggr i olika varianter på samma tema, snarare än att man tagit bort en massa validering som gör nytta i runtime.

En enskild komponent skriven i Rust löser ju dock självfallet inte alla problem i ett jätteprojekt som Windows. Men en strategiskt vald komponent kan ju vara extra viktig att den är robust och kan i bästa fall göra en större skillnad än dess andel kod sett till helheten, även om det finns en massa fel på andra håll fortfarande.

Vill minnas att Edge autostartas (i bakgrunden) för att upplevas som snabbare, såvida man inte aktivt stänger av detta.

Som jag förstår stödet för Rust i Windows-kärnan handlar det i första läget att överhuvudtaget möjliggöra/tillåta att man använder det programspråket för att skriva som körs i kernel-context.

Kod som körs i kärnan har en del restriktioner som "vanliga" program inte behöver tänka på, t.ex. brukar det inte vara tillåtet med vissa språkkonstruktioner (t.ex. C++ exceptions) och rätt vanligt att man bara får använda heltal (flyttal och SIMD är inte generellt tillåtet, men går att använda i speciella kontext).

Det som gör Rust rätt unikt är att det som i andra språk är "undefined behavior" är hanterat på ett sätt som ger kompileringsfel i Rust. Ett riktigt otrevligt problem som finns i de flesta populära programspråk, inklusive C, C++, C# och Java, är data-race vid användning av flera CPU-kärnor / trådar. I Rust blir ett sådant fel ett kompileringsfel, vilket är otroligt värdefullt.

Ovanpå det kan detta göras på ett sätt med prestanda som är helt jämförbar med kod skriven i t.ex. C och C++.

Sen ska man vara medveten att Rust inte är en magisk silverkula. Rust kan göra sina garantier om allt är skrivet i Rust, vilket definitivt inte är fallet för Windows (eller Linux som numera också tillåter Rust i kärnan). Rust kan också upprätthålla sina garantier om all kod som inte är skrivet i Rust inte innehåller någon bug som orsakar odefinierat beteende, vilket i praktiken inte är fallet (om det vore sant skulle vi t.ex. inte ha off-by-one-or-more buggar som många säkerhetshål kommer från).

Men ändå värdefullt att veta att vissa typer av buggar, om de finns, måste ligga i kod som inte är skrivet i Rust utan i så fall anropas från Rust. Det utesluter delar av systemet man inte behöver analysera i jakten på att hitta felet.