Win8/ARM - M$ på rette spor ?

Microsofts beslutning om ikke at lave plads til andre browsere på Win8/ARM får en del exposure lige nu. men jeg synes der mangler en dimension i debatten.

Microsoft står for første gang siden NT/Alpha overfor en CPU der virkelig adskiller sig fra X86.

Det er ikke sjovt, det er overhovedet ikke sjovt.

I FreeBSD overvejede vi seriøst slet ikke at supportere andet end x86 og vi slap kun Alpha ind i en paria-rolle det tog år at slippe ud af.

Det er en meget stor omvæltning og da vi endelig tog fat på multi-arkitektur problematikken, brugte vi chancen til at lave en masse ting om ved samme lejlighed.

Men hvad nu hvis Microsoft bare på samme måde prøver at bruge chancen for at at undgå at nissen flytter med ?

En af de faciliteter som Microsoft ikke vil tilbyde andre processer end IE adgang til er at gøre et stykke hukommelse exekverbart.

Man kan ikke skrive en Just-In-Time compiler uden disse systemkald.

Vi kan med andre ord glemme alt om hurtig javascript og alle mulige andre teknikker der bruger JIT-compilere.

Men de præcis samme systemkald er utroligt brugbare for alle former for malware og ved simpelthen at lukke af for dem, er rigtig mange malware producenter blevet skudt i foden, inden de nogensinde kom igang med at skrive noget til den ny platform.

Specielt i windows-verdenen er der en tendens til at glemme, eller slet ikke at forstå, at computersikkerhed i bund og grund handler om at afveje hvilke faciliteter der gavner modstanderne mere end en selv og så bide i det sure æble og leve uden dem.

Hvis jeg var ansvarlig for sikkerheden for en eller anden kæmpe organization, ville jeg ikke have ret svært ved at vælge imellem en mere modstandsdygtig platform med kun en browser og en mere udsat platfrom med valgfrig browser.

Der kan med andre ord være tale om en intelligent og velovervejet afvejning, der skal gøre Microsofts nye platform mere sikker.

Når det så er sagt...

Jeg ville nok ikke vælge at fjerne enhver mulighed for JIT compiling, specielt ikke på et OS der sigter efter batteridrevne enheder.

Det har jeg egentlig også svært ved at se Microsoft gøre, bare for at forbedre sikkerheden.

Derfor må jeg desværre nok tilslutte mig at Microsoft stadig ikke har forstået det med monopoler.

Men hvis Microsoft har, eller vil komme med, en officiel udmelding om at det virkelig handler om at forbedre sikkerheden drastisk, så vil jeg ikke alene tro på dem, jeg vil også rose dem for det.

phk

Poul-Henning Kamps billede
Poul-Henning er selvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.

Kommentarer (18)

Torben Mogensen

Jeg så forleden et foredrag om Googles Native Client (NaCl), som går ud på at lave en validering af maskinkode med visse begrænsninger. I denne model var der også mulighede for at generere ny kode, som bliver valideret, inden det udføres. Ideen var, at koden bliver genereret i et ubeskyttet område, og derefter kopieret ind i kodearealet (som ellers er read-only) men med en HALT instruktion kopieret ind i starten af hver blok kode (jump targets er modulo 32 bytes), som sikrer at koden ikke bliver udført, inden den er valideret. Når koden så er valideret, bliver HALT instruktionerne overskrevet med NOP, så koden derefter kan eksekveres.

En sådan model kunne MS sagtens sætte til rådighed for alle browseres JIT oversættere. Hvis ikke de vil bruge Googles model direkte, kan de lave noget tilsvarende selv. Det har de jo gjort adskillige gange før.

Med hensyn til motivet, så har jeg Intel mistænkt for (med pisk eller gulerod) at presse MS til at gøre Win8 på ARM mindre attraktiv end Win8 på x86. De er før blevet taget i at lave den slags aftaler -- dog mod AMD mere end mod ARM, men ARM er jo ved at blive hovedfjenden nu.

Casper Bang

Men dét som MS vil, er der vel sat præcedens for hos Apple. Det er ikke lang tid siden, man heller ikke kunne installere alternative browsere på iOS. Og dén dag i dag, tillader de ej heller JIT (hvorfor Ruby, Python etc. har det svært på platformen). Apple gør dog nok dette af filosofiske, frem for sikkerhedsmæssige, grunde (de bruger LLVM compileren og foretrækker native ting).

Men lad os nu se, .NET har jo DLR'en oven på CLR'en, og understøttelse i selve C# sproget (via dynamic keyword bl.a.), så det vil stadig være muligt at få JIT fordele i managed kode, man må blot ikke komme med sin egen "motor" som security manageren ikke har kontrol over.

Set ud fra dét synspunkt, synes jeg måske man skal lade tvivlen komme MS til gode. Nye smartphones har 4+ kerner, overhead associeret med managed kode (og dermed højere sikkerhed) er hurtigt hentet ind via Moores lov.

Martin Andersen

Kunne man ikke forestille sig at kode på en måde kunne bliver certificeret til at tilgå hukommelsen direkte?
Det ansvar må vel følge med, når man har sådan en stor del af markedet?

Brian Matzon

ikke for at afspore debatten, men MS har ikke problemer med andre browsere - de skal bare bruge det nye metro API.
Svjv, så er den eneste undtagelse til denne regel Office pakken.

Daniel Udsen

MS UEFI-light specifikation er nok det der her bider dem i haserne, hvor OS'et som planlagt begrænser visse API kald til "betroede applikationer".

I UEFI specifikationen er udgangspunktet at system ejer selv instalere rod certifikatet via et hw overide interface, så har MS lagt op til en light version hvor rod certifikatet er preloaded og brugeren altså ikke kan definere hvad der er "trusted".

For x86 har de måttet indgå et kompromis hvor MS lover de vil sikre "firefox/chrome/opera" lige adgang Mugligvis ved at signere/distriburere binære filer fra firefox/google/opera.

Bjarke I. Pedersen

Du roder lidt rundt i det.

På x86 kan man installere alt hvad man kan idag, der er ingen forskel.
Selvom UEFI Secure Boot er slået til, så kan man stadigvæk installere normale desktop applikationer på præcist samme måde som idag.

Det man ikke kan, er at installere desktop applikationer på Windows RT, da det er forbeholdt de indbyggede programmer der følger med (de fleste standard Windows programmer, og så Word, Excel, Powerpoint og Onenote) .

Det som Secure Boot sikrer på tablets er, at man ikke kan skifte operativ systemet ud, det har ikke noget med hvad der kører efter systemet er bootet op at gøre - det er systemet selv som står for det.

Thomas Hansen

MS lukker vel bare af og begrænser 3 part.
Jeg har altid haft lidt svært ved at forstå, hvorfor MS skal "tvinges" til, at være åbne over for 3 part. Dermed pålægger man jo også MS et ansvar for om der er åbent til sikkerhedsbrister i den SW 3 part kører under MS, og det virker forkert i mine øjne.

Peter Jensen

Hvis MS kun havde 10-30% af marked kunne de gøre som de ville, problemet opstår når de har 80%, så må de finde sig at blive behandlet som et monopol. Mig bekendt har MS ikke 80% af arm marked. Næste problem er at hvis "samfundet" (det offentlige banker mm) kun understøtter et bestemt program/OS (som i gamle dage med IE) så har vi igen balladen. Personligt bruger jeg ikke software jeg ikke kan få sourcekoden til, og slet ikke et system der ikke kan køre python ;-)

Martin Bøgelund

Hvis MS kun havde 10-30% af marked kunne de gøre som de ville, problemet opstår når de har 80%, så må de finde sig at blive behandlet som et monopol. Mig bekendt har MS ikke 80% af arm marked.

Nu er vi vant til at sige monopol om Microsoft, men den rette betegnelse i denne sammenhæng er "markedsdominans"; man behøver ikke have et vaskeægte monopol for at kunne ødelægge konkurrencen på et marked - derfor vil man se på om der er tale om markedsdominans, og ikke monopol.

Jeg har set forskellige procentsatser for hvornår der er tale om en dominerende stilling på markedet. Så vidt jeg husker er 30%-50% nok til at at blive kaldt dominerende.

Så er der også en udfordring i at afgrænse markedet. Du kalder det "ARM markedet", men overfor forbrugere vil du nok ikke kunne afgrænse på den måde - almindelige forbrugere tænker ikke over om der sidder en ARM processor i, når de køber maskinen.

Mere forbrugernære markedsdefinitioner er her nødvendige - "tablet-markedet", "desktop-markedet" eller "personal computing-markedet" kunne være relevante afgrænsninger.

Microsoft ser klart ud til at udfordre denne afgrænsning - MS påstår at Win8/ARM ikke er Windows, og at de derfor ikke er underlagt lovgivningen om misbrug af markedsdominans på det område.

Men et af argumenterne for at bruge Windows er jo kompatibiliteten over til alle de andre Windows-applikationer som man allerede har købt og bruger - holder MS fast i at Win8/ARM ikke er Windows, vil de heller ikke kunne markedsføre Win8/ARM som en Windows, uden at konkurrencehammeren falder. Det bliver spændende at se hvordan de vil skære den kage.

Finn Christensen
Nikolaj Brinch Jørgensen
Casper Bang

Man kan ikke skrive en Just-In-Time compiler uden disse systemkald.

Men hov, siger du dermed indirekte, at Microsoft har tænkt sig at forbyde Java (JRE/JVM/HotSpot)? Det vil da får store politiske konsekvenser og skaffe Microsoft endnu en monopolsag på halsen?!

Casper Bang

Man kan godt lave en JVM uden JIT-compiler.

Ja men den vil køre af h...... til. Oracle's OpenJDK er jo ret unik ved altid at starte som fortolker, for således at lade HotSpot (deres JIT motor) trace metoder, kompilere disse, og erstatte koden i ClassLoaderen.

Ja faktisk er dette designvalg lækket igennem selve Java specifikationen, hvor du f.eks. har separate instruktioner for hver primitiv operand-type. Der er int, long, double og float -versioner af add, store, sub, div, mul, neg, rem, shr osv. netop fordi det gør fortolkning hurtigere (skal ikke udledes).

...så netop på ARM kan JVM køre rimeligt hurtigt uden JVM.

Dén tror jeg altså ikke helt jeg kan følge, kan du uddybe? Hvis Microsoft forbyder JIT, og fjerner adgang til disse instruktioner, så er det vel kun 3 muligheder.

1) At benytte sig af en officiel sanktioneret JIT provider, stillet tilrådighed af platformen (.NET kompatibelt AST via IL).

2) Fortolkning (a la OpenJDK med HotSpot slået fra), men det vil være for langsomt i praksis.

3) Precompile AOT (a la hvad Mono og Android's odex tillader).

Log ind eller opret en konto for at skrive kommentarer

IT Businesses