Hvorfor ikke skrive om Java-maskinen i Java?

[leafmaybe]

I lys av Javas sikkerhetsproblemer, tenkte jeg kanskje at siden Java selv regnes som et ganske "sikkert" språk (noe jeg selv kan bekrefte til en høyere grad), vil det ikke være en god ide for si Oracle, å levere neste Java-maskinen skrevet i Java?

 

Mine argumenter er:

 

1. Java er lettere å sjekke feil for enn C++, pga automatisk minnehåndtering, streng-klasser osv.

 

2. Java sies å produsere programmer som kan være raskere enn C++, grunnet JIT- og HotSpot- kompileringsstrategier og andre greier noen gode Java compilere kan få til.

 

3. Av en eller annen grunn så har det vært en standardpraksis for språkdesignere å skrive compilere for deres språk i samme språk. Såkalte "eat your own dogfood"-tankegangen.

 

Jeg vil gjerne høre om deres meninger om dette .-)

 

Endret 31. januar 2013 av Amn

[Topguy]

Hvis JVM skal skrives i Java så må jo JVM kjøres i en JVM, hvilket språk skal den JVM'n skrive i da ?

 

[Terrasque]

Hvis JVM skal skrives i Java så må jo JVM kjøres i en JVM, hvilket språk skal den JVM'n skrive i da ?

 

Java, vel! Følger du ikke med, eller?

[weebl]

Det er ikke i selve språket sikkerheten til java ligger men i JVM (Java Virtual Machine) hvor java programmer kjører. I motsetning til f.eks C/C++ programmer som kjører direkte på maskinvaren så kjøres java i en virtuell maskin, det er JVM som tar seg av garbage collection, automatisk minnehåndtering osv, ikke compileren såvidt jeg har forstått det, så de sikkerhetshullene som fins i Java vil også finnes i Jython, Scala og andre JVM språk.

[jonny]

Hvorfor ikke bare bruke ordentlig hardware ?

[GeirGrusom]

Hvorfor ikke bare bruke ordentlig hardware ?

 

ARM Cortex A-serien har jo dette i form av ThumbEE

 

edit: deprecated

 

edit2: on-topic ser jeg ikke helt problemet med å skrive JVM i Java. Det ligner på tankegangen bak Cosmos og Microsoft Singularity.

Endret 31. januar 2013 av GeirGrusom

[Foxboron]

PyPy? Python skrevet i Python? Det er faktisk raskere en CPython som er standar.

Verdt å merke dem la til JIT kompilering tho.

[efikkan]

I lys av Javas sikkerhetsproblemer, tenkte jeg kanskje at siden Java selv regnes som et ganske "sikkert" språk (noe jeg selv kan bekrefte til en høyere grad), vil det ikke være en god ide for si Oracle, å levere neste Java-maskinen skrevet i Java?

Ingen av problemene som har blitt belyst i senere tid er knyttet til programmeringsspråket Java, det handler om Java Runtime Environment. x86 kan ikke kjøre javas bytecode, så JVM må implementeres i noe native. Enten dette er assembly eller C++ er totalt likegyldig, språkvalget gjør det ikke sikkert av den grunn.

 

Antagelsen din er et stjerneeksempel på hvordan folk misforstår når sikkerhet nevnes f.eks. i java-sammenheng. Det som det refereres til er safety, ikke security. F.eks. innebygde mekanismer i språket for å hindre at utvikleren gjør dumme designvalg. Ada er et eksempel på et språk som har tatt safety mye lengre enn Java, uten at det sikrer programmer mot slike hull.

[quantum]

x86 kan ikke kjøre javas bytecode, så JVM må implementeres i noe native. Enten dette er assembly eller C++ er totalt likegyldig, språkvalget gjør det ikke sikkert av den grunn.

Dette kan vel illustreres greit på følgende måte: Der hvor gcc er den foretrukne kompilatoren - f.eks. linux - blir JVM'en kompilert med gcc. Så det ville være fullt mulig å implementere en JVM i Java og kompilere denne med gcc istenden. Spørsmålet blir da hva dette eventuelt hadde tilført. Ville det vært færre minnelekkasjer pga. gc? Tja, man kan da ha gc i C++ også hvis man vil ... er gcc's java runtimebiblioteker bedre og tryggere enn c++ runtimebibliotekene i gcc? Og kan man si at det eventuelt er egenskaper ved språkene c++ og java? Nope, det er egenskaper ved implementasjonen gcc. Osv.

 

Og til slutt, for å frike det helt ut: Om ikke lenge har vel Oracle solgt inn Java Card hos bankene, så kan vel bare glede oss til å se hvorledes det vil påvirke tekno-paranoiaen I mellomtiden kan vi spørre oss hvorfor ikke den forbanna bankid-kodebrikka bare kan stappes inn i et usb-interface på pc'en så kunne man kjørt bank-id-app'en derfra, det ville eliminert behovet for å tillate browseren å kjøre potensielt utrygg kode nedlastet fra et nettsted.

[Capitalist Hippie]

x86 kan ikke kjøre javas bytecode, så JVM må implementeres i noe native. Enten dette er assembly eller C++ er totalt likegyldig, språkvalget gjør det ikke sikkert av den grunn..

 

Det er riktig å si at JVMen må generere noe native, men JVMen kunne i seg selv vært skrevet i mer-eller-mindre ("turing complete") hva som helst.

Endret 1. februar 2013 av nostdal.org

[efikkan]

Dette kan vel illustreres greit på følgende måte: Der hvor gcc er den foretrukne kompilatoren - f.eks. linux - blir JVM'en kompilert med gcc. Så det ville være fullt mulig å implementere en JVM i Java og kompilere denne med gcc istenden. Spørsmålet blir da hva dette eventuelt hadde tilført. Ville det vært færre minnelekkasjer pga. gc? Tja, man kan da ha gc i C++ også hvis man vil ... er gcc's java runtimebiblioteker bedre og tryggere enn c++ runtimebibliotekene i gcc? Og kan man si at det eventuelt er egenskaper ved språkene c++ og java? Nope, det er egenskaper ved implementasjonen gcc. Osv.

F.eks. OpenJDK er implementert i C++, men du vil ha et alternativ implementert i ren Java og kompilert til native x86- og ARM-maskinkode. Du vil støte på en rekke problemstillinger her:

- Kompilering av Java ville generert veldig mye maskinkode, som vil være forskjellig på hver plattform, og kan potensielt inneholde mange feil. Implementasjonen av garbage collector og annen minnehåndtering måtte kontrolleres på assembly-nivå,

- "Safety-gevinstene" for kjøring i JVM må implementeres, her er det rom for fatale feil.

- Prosjektet har vært dødt siden 2009, runtimes er mildt sagt utdaterte.

- Påliteligheten til det nye JRE vil hvile på kvaliteten til runtimes, med mindre dette implementeres manuelt via inline C++,C eller assembly (det er mulig).

 

For GCC vil assemblykoden fra GCJ bli kjørt gjennom GCC sine optimaliseringer, der mer assemblykode gir rom for flere feil. GCC sine runtimes for C(ISO) er solide, og jeg tørr påstå at runtimes for C++ har vist seg å være bra.

 

Det er mulig å lage kode som er teoretisk feilfri. I 99.99% av tilfellene skyldes minnelekkasjer logiske feil i koden, og alle disse kunne vært unngått med god nok kode. Problemet med å skrive i høyere nivå er at det genereres betydelig mer komplisert assemblykode for å implementere minnehåndtering. Problematikken kan "unngås" ved å overlate dette til runtimes og eventuelt tredjeparts biblioteker, forutsatt at de har håndtert problematikken for deg og du bruker bibliotekene helt korrekt.

 

Uansett er problemstillingen irrelevant, siden ingen av JRE sine problemer er knyttet til implementasjonsspråket eller bruksspråket(Java). Hovedproblemet har vært knyttet til sandboxing, og det handler om et designvalg. For at dette skulle vært tryggere måtte JVM vært adskilt fra user space(gjennom brukerrettigheter i kernel) og ikke ha noen tilgang til f.eks. filsystemet.

 

Og til slutt, for å frike det helt ut: Om ikke lenge har vel Oracle solgt inn Java Card hos bankene, så kan vel bare glede oss til å se hvorledes det vil påvirke tekno-paranoiaen I mellomtiden kan vi spørre oss hvorfor ikke den forbanna bankid-kodebrikka bare kan stappes inn i et usb-interface på pc'en så kunne man kjørt bank-id-app'en derfra, det ville eliminert behovet for å tillate browseren å kjøre potensielt utrygg kode nedlastet fra et nettsted.

Jeg mener jeg så noe om at danske banker skulle kutte ut java applets Endret 1. februar 2013 av efikkan

[Occi]

I lys av Javas sikkerhetsproblemer, tenkte jeg kanskje at siden Java selv regnes som et ganske "sikkert" språk (noe jeg selv kan bekrefte til en høyere grad), vil det ikke være en god ide for si Oracle, å levere neste Java-maskinen skrevet i Java?

Java som et programmeringsspråk er ikke usikkert.

Når du finner Java i såpass mange forskjellige former er det viktig at man skiller på hva man snakker om (Java som i språket, JRE, applets osv).

 

I mellomtiden kan vi spørre oss hvorfor ikke den forbanna bankid-kodebrikka bare kan stappes inn i et usb-interface på pc'en så kunne man kjørt bank-id-app'en derfra, det ville eliminert behovet for å tillate browseren å kjøre potensielt utrygg kode nedlastet fra et nettsted.

En liten digresjon:

 

BankID-appleten oppdateres fra tid til annen, så det ville fungert dårlig siden du uansett måtte oppdatetert din lokale klient på USB (like utrygt), eller sendt ut nye USB-brikker hver gang det skjedde (uhyre upraktisk). Nå nylig fjernet de f. eks maskeringen av engangspassordet. Det står nå i klartekst når du plotter det inn.

 

Her er forøvrig en ganske fin diskusjon ang. bruken av Java applets vs. SSL og html forms. Kort sagt handler det om tradeoffs, men om Java som plugin var sikkert ville det nok kunne sies å være tryggere totalt sett. Det som er litt interessant er at (u)sikkerheten i større grad går på klientens side.

 

BankID-appleten gjør nok også litt mer enn å servere et par input-felter, uten at jeg vet om det er noen offentlig info på dette (så dette er spekulasjoner). Sikkerhetssjekker vil kunne gjøres uten påvirkning i en applet vs. vanlig JS. Tenk f. eks på trojanere. Man kan i alle fall gjøre litt av hvert i en applet, og BankID-appleten er signert slik at den har rimelig godt med rettigheter.

 

Litt ironisk er det nå da at slike sjekker er egentlig kun relevant om man blir infisert av trojanere og lignende, hvor Java er en stor kilde

Endret 1. februar 2013 av Occi

[quantum]

...men du vil ha et alternativ implementert i ren Java...

For å si det enkelt; Nei, det er feil.

[quantum]

 

BankID-appleten oppdateres fra tid til annen, så det ville fungert dårlig siden du uansett måtte oppdatetert din lokale klient på USB (like utrygt),

 

...

 

BankID-appleten gjør nok også litt mer enn å servere et par input-felter, uten at jeg vet om det er noen offentlig info på dette (så dette er spekulasjoner). Sikkerhetssjekker vil kunne gjøres uten påvirkning i en applet vs. vanlig JS. Tenk f. eks på trojanere. Man kan i alle fall gjøre litt av hvert i en applet, og BankID-appleten er signert slik at den har rimelig godt med rettigheter.

 

 

Det er ikke akkurat heksekunst å lage et program som laster ned oppdateringer av seg selv automatisk. Og om så oppdateringer måtte sendes rekommandert i posten, slik man må med kodebrikken, så ser jeg ikke helt hvordan det blir så veldig utrygt?

 

Du går jo også glipp av hele pointet her, problemet er ikke sikkerheten i bank-id-appleten, den kan være så signert og fin den bare vil, den, problemet er at den forutsetter at folk har javplugin installert.

[blackbrrd]

Hvis JVM skal skrives i Java så må jo JVM kjøres i en JVM, hvilket språk skal den JVM'n skrive i da ?

 

C-kompilatoren er skrevet i C, så ser ikke helt problemet.

[Occi]

Det er ikke akkurat heksekunst å lage et program som laster ned oppdateringer av seg selv automatisk. Og om så oppdateringer måtte sendes rekommandert i posten, slik man må med kodebrikken, så ser jeg ikke helt hvordan det blir så veldig utrygt?

Du oppdaterer kodebrikken sjeldent, sannsynligvis sjeldnere enn BankID-appleten blir oppdatert. Oppdaterer bør gjerne gjøres raskt (dvs. ikke post). Om man uansett måtte koble seg opp mot nett for å oppdatere, vil noe av samme problematikken oppstå, ved mindre du da i kjører oppdateringen helt adskilt fra appleten.

Hovedpoenget er uansett at det er veldig upraktisk. BankID kunne blitt gjort sikrere, men det er gjort noen endringer på et standard PKI-system for at det skal være litt mer praktisk.

 

Du går jo også glipp av hele pointet her, problemet er ikke sikkerheten i bank-id-appleten, den kan være så signert og fin den bare vil, den, problemet er at den forutsetter at folk har javplugin installert.

Hehe nei det vil jeg ikke si, jeg skrev nå at det var en digresjon. En diskusjon om du vil.

Alt jeg skrev var ikke ment som noe argument mot din post.

[quantum]

Du oppdaterer kodebrikken sjeldent, sannsynligvis sjeldnere enn BankID-appleten blir oppdatert. Oppdaterer bør gjerne gjøres raskt (dvs. ikke post). Om man uansett måtte koble seg opp mot nett for å oppdatere, vil noe av samme problematikken oppstå, ved mindre du da i kjører oppdateringen helt adskilt fra appleten.

 

 

men igjen, det er ikke oppdatering av bank-id som er problemet her, problemet er bindingen til java-plugin. kanskje du kan forklare hvilke sikkerhetsproblemer knytta til oppdatering av software over nett du egentlig snakker om?

[quantum]

C-kompilatoren er skrevet i C, så ser ikke helt problemet.

 

Koker det i hodet?

 

Det er ingen som lurer på om det er mulig å skrive en java-kompilator i java. Den ville jo bare vært et helt vanlig java-program som eksekverer akkurat som alle andre java-programmer, f.eks. på en helt vanlig JVM.

 

Deler av en JVM kunne også være skrevet i Java og bare kompilert til bytecode, men den ville behøve nok bootstrappingkode i maskinkode til å kunne oversette "resten" av seg selv til maskinkode også.

Endret 1. februar 2013 av quantum

[Occi]

men igjen, det er ikke oppdatering av bank-id som er problemet her, problemet er bindingen til java-plugin.

Du misforstår. Jeg prøver ikke å si noe annet, kun diskutere implementasjonen/bakgrunnen for BankID-appleten, og sikkerheten rundt bruk av Java-plugin i nettlesere.

 

kanskje du kan forklare hvilke sikkerhetsproblemer knytta til oppdatering av software over nett du egentlig snakker om?

Merk "ved mindre du da i kjører oppdateringen helt adskilt fra appleten.".

Det er ikke noe problem å ha en sikker oppdatering om oppdateringen foregår uten innblanding av noen Java-plugin.

 

Du har også oversett hovedpoenget. Jeg legger bare frem litt hvorfor det kanskje er slik som det er. Nets (leverandør av BankID) har prøvd å finne en balanse mellom sikkerhet og en praktisk løsning. Hvorvidt en Java-applet er et svar på denne problemstillingen er noe av det som kan diskuteres.

[quantum]

 

Du har også oversett hovedpoenget.

 

 

Ok, hovedpoenget ditt er altså at om du oppdaterer en applet over nett så får du de sikkerhetsproblemene som er forbundet med å oppdatere en applet over nett. Det poenget er ganske smalt, så det var vel derfor jeg ikke så det :o)