Java ist schneller als C++!
-
DEvent schrieb:
Ein Java Programm kann auch (bis auf Ausnahmen) nicht aus dem Speicherbereich der VM ausbrechen, da die VM ja den Speicher verwaltet, genauso wie das OS den Speicher der VM verwaltet.
Yo, leider wissen anscheinend die wenigsten hier über die Basics bescheid. ich ergänze mal deine Ausführung durch einen Link:
http://de.wikipedia.org/wiki/Speicherschutz
-
Junge Junge schrieb:
gegenfrage schrieb:
Du setzt einfach v******, dass es im OS keinen Bug gibt der es ermöglich irgendwas zu hacken und das geht nur wenn die Programmierer besser wären.
Das OS läuft in einem ganz anderen Modus, da hat eine Anwendung keinen direkten Zugriff. Die JVM ist eine ganz normale Anwendung genaugenommen läuft sie sogar für das OS anstelle der Anwendung, das heißt, wenn das Programm mit dem OS kommunizieren kann, dann kann es die JVM nach belieben manipulieren.
Die JVM ist zwar bemüht das zu verhindern, aber um sich selbst vor der Anwendung schützen zu können müsste sie wie ein Betriebssystem den eigenen Speicher durch Zugriffsrechte schützen können, welche durch die Hardware durchgesetzt werden.Du kannst nur was zerstören, wenn es einen Bug gibt der das zuläßt und Bugs kann es im OS oder in der JVM geben.
-
DEvent schrieb:
Ein Java Programm kann auch (bis auf Ausnahmen) nicht aus dem Speicherbereich der VM ausbrechen, da die VM ja den Speicher verwaltet, genauso wie das OS den Speicher der VM verwaltet.
Der große Unterschied ist, daß das OS via MMU den Speicher verwaltet und die JVM dies nicht kann. Kleinste Fehler in der JVM bedeuten daher den totalen Sicherheitsverlust. Vergleicbhare Fehler in anderen Anwendungen bedeutet nur, daß man mit den Nutzerrechten des Programms auf dem System etwas ausführen kann. Und dies ist insbesondere auf einem Server der nicht unter Windows läuft, so gut wie nichts. Die Sandbox wird vom OS bereitgestellt, ob die JVM da irgend etwas mitbringt oder nicht interessiert selbst SUN auf den Solaris Systemen überhaupt nicht.
Der ganze Sicherheitskram der JVM dient im Grunde nur dazu Java Browser Plugins nicht gleich den Nutzeraccount übernehmen zu lassen. Mit einem Trusted OS ist das Problem aber ebenfalls über die OS Ebene lösbar, so daß man nicht mehr auf interne unzureichende "Schutz"-maßnahmen der JVM mehr setzen muß.
-
john! Nur weil du dich wiederholst, wird es nicht richtig. Du hast einen denkfehler: java als Sprache an sich kann die JVM nicht "verlassen" und Schaden anrichten. Das hebt sich wieder auf, mit deinen komischen MMU-Vergleichen. Die MMU macht nur Sinn, wenn ich auch eine Maschinenfähige Sprache habe. Wir drehen uns hier wegen dir im Kreis.
-
DEvent schrieb:
Hat ... die ... VM nicht einen voellig anderen Vorteil...
Ja - das ist ein Vorteil einer VM ... egal, von welcher Sprache aus sie "bedient" wird.
... und ein Nachteil einer VM sind eben die Laufzeit- und Speicher"kosten", sowie die Abhängigkeit von den Möglichkeiten der VM: An besondere Plattformspezifika (OS, Hardware, ...) zu kommen, wird seeeehr kompliziert (und meistens nur unter Umgehung der VM-Vorteile möglich).Wem das wirklich wichtig ist, lässt seinen C++-Code in einer VM laufen...
Gruß,
Simon2.
-
~john schrieb:
-fricky- schrieb:
*räusper* http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-specTOC.fm.html
Eine Sandbox kann rein vom Prinzip her nicht die Sicherheitsfunktionen im OS ersetzen.
ob ein programm nun bugs einer vm oder eines betriebssystems ausnutzt, um böses zu tun, ist im prinzip das selbe. ich sehe da absolut keinen unterschied. ausser vielleicht, dass fehler im OS erheblich schlimmere folgen haben können, als sicherheitslücken einer VM. vielleicht ist das auch der grund, warum es nicht wirklich viele schlimme viren gibt, die in Java programmiert wurden.
-
Simon2 schrieb:
DEvent schrieb:
Hat ... die ... VM nicht einen voellig anderen Vorteil...
Ja - das ist ein Vorteil einer VM ... egal, von welcher Sprache aus sie "bedient" wird.
... und ein Nachteil einer VM sind eben die Laufzeit- und Speicher"kosten", sowie die Abhängigkeit von den Möglichkeiten der VM: An besondere Plattformspezifika (OS, Hardware, ...) zu kommen, wird seeeehr kompliziert (und meistens nur unter Umgehung der VM-Vorteile möglich).Wem das wirklich wichtig ist, lässt seinen C++-Code in einer VM laufen...
Ja, eine VM (z.B. VMWare) oder Sandbox? Na, da würde ich doch sagen, kann man doch C++-Programme sparsamerweise lieber in einer Sandbox (z.B. Sandboxie für NT) oder in einem Jail (in FreeBSD serienmäßig) laufen. Denn diese Varianten benötigen ggü. einer VM keine zus. Betriebssystem-Instanz. Zumindest ist der Resource-Verbrauch und die Startzeit geringer.
-
Knasti schrieb:
...
Na, da würde ich doch sagen, kann man doch C++-Programme sparsamerweise lieber in einer Sandbox (z.B. Sandboxie für NT) oder in einem Jail (in FreeBSD serienmäßig) laufen....Wenn einem das Betriebssystem selbst eine VM anbietet: Umso besser.
Ändert aber nichts a meinem Argument: Eigenschaften des "VM-Betriebs" sind nur sehr schwache Argumente für/gegen eine Sprache.Gruß,
Simon2.
-
Belegst Du das Argument noch oder ist es am Ende doch nur Deine persönliche Meinung?
-
byto schrieb:
Belegst Du das Argument noch oder ist es am Ende doch nur Deine persönliche Meinung?
Jeweils unter der Annahme einer "perfekten VM":
(Programm in der der Sprache X geschrieben) + (läuft in VM) => Laufzeitchecks durch die VM => größere "Sicherheit" (keine Beeinträchtigung von OS und -Ressourcen) + größere Laufzeit
(Programm in der der Sprache X geschrieben) + (läuft OHNE VM) => KEINE Laufzeitchecks durch die VM => Keine größere "Sicherheit" (keine Beeinträchtigung von OS und -Ressourcen) + keine höhere Laufzeit
Gruß,
Simon2.
-
Am Ende ist es eine Frage, wie die längere Laufzeit und die höhere Sicherheit zu bewerten ist - jeweils bezogen auf die spezfischen Anforderungen. Dementsprechend wichtig imo ist auch die Entscheidung für oder gegen eine Sprache mit VM.
-
byto schrieb:
Am Ende ist es eine Frage, wie die längere Laufzeit und die höhere Sicherheit zu bewerten ist - jeweils bezogen auf die spezfischen Anforderungen. Dementsprechend wichtig imo ist auch die Entscheidung für oder gegen eine Sprache mit VM.
Der Sicherheitsaspekt ist ja nur einer von vielen bei einer VM. Eine VM erleichtet z.B. die Portierung, Speichermanagment, Debuging, Profiling, uvm.
-
byto schrieb:
Am Ende ist es eine Frage, wie die längere Laufzeit und die höhere Sicherheit zu bewerten ist - jeweils bezogen auf die spezfischen Anforderungen. Dementsprechend wichtig imo ist auch die Entscheidung für oder gegen eine Sprache mit VM.
Ich würde sagen: "Dementsprechend wichtig ist die Entscheidung für oder gegen eine VM." !!
Denn das Vorhandensein irgendeiner VM bedeutet noch nicht die Lösung aller meiner Probleme - schlimmstenfalls bekomme ich eine VM vorgesetzt, die für meine Belange untauglich ist.
Und für die Frage der eingesetzten Sprache muss man dann auch die Möglichkeiten der favorisierten VM einbeziehen.
BTW: Es geht auch nicht um "Sicherheit" absolut, sondern um die speziellen Sicherheitsaspekte der jeweiligen Umgebung - hier entsteht ein wenig der Eindruck, als ob z.B. das Betriebssystem selbst überhaupt keinerlei Sicherheitsmechanismen böte.DEvent schrieb:
...
Der Sicherheitsaspekt ist ja nur einer von vielen bei einer VM. Eine VM erleichtet z.B. die Portierung, Speichermanagment, Debuging, Profiling, uvm.Sagen wir mal so: Diese Aspekte werden halt von der Entwicklung der Anwendung weg verlagert - hin zu der Entwicklung der VM.
Prima, wenn sich jemand schon diese Arbeit (und sie gut) gemacht hat: Man muss das Rad nicht neu erfinden.
Blöd, wenn jemand diese Arbeit schlecht/für mich unpassend erledigt hat: Man muss sich vermutlich die Finger brechen.;)Gruß,
Simon2.
-
Simon2 schrieb:
BTW: Es geht auch nicht um "Sicherheit" absolut, sondern um die speziellen Sicherheitsaspekte der jeweiligen Umgebung - hier entsteht ein wenig der Eindruck, als ob z.B. das Betriebssystem selbst überhaupt keinerlei Sicherheitsmechanismen böte.
Der gleiche Eindruck entsteht aber auch beim Thema "längere Laufzeit" durch die VM.
-
byto schrieb:
Simon2 schrieb:
BTW: Es geht auch nicht um "Sicherheit" absolut, sondern um die speziellen Sicherheitsaspekte der jeweiligen Umgebung - hier entsteht ein wenig der Eindruck, als ob z.B. das Betriebssystem selbst überhaupt keinerlei Sicherheitsmechanismen böte.
Der gleiche Eindruck entsteht aber auch beim Thema "längere Laufzeit" durch die VM.
Stimmt!
-
-fricky- schrieb:
ob ein programm nun bugs einer vm oder eines betriebssystems ausnutzt, um böses zu tun, ist im prinzip das selbe.
Nein, der äquivalente Fehler wäre ein Bug in der MMU, der es erlaubte das OS direkt überschreiben zu können. Der kleinste Fehler in der JVM hebelt sie komplett aus! Das ist der Unterschied. Ein simpler Fehler im OS bedeutet nicht gleich den GAU.
-fricky- schrieb:
ich sehe da absolut keinen unterschied. ausser vielleicht, dass fehler im OS erheblich schlimmere folgen haben können, als sicherheitslücken einer VM.
Ein Fehler im OS kann nur dann schlimmere Auswirkungen haben, wenn man die Sicherheitsfunktionen der JVM nicht traut und das OS diese garantieren muß. Denn wenn die JVM gleichwertig wäre, dann wäre der Schaden es ebenfalls. Schön, daß Du mir indirekt zustimmst.
-fricky- schrieb:
vielleicht ist das auch der grund, warum es nicht wirklich viele schlimme viren gibt, die in Java programmiert wurden.
Java zieht viel Leistung beim Starten der JVM, das dürfte der Hauptgrund sein, weshalb es auf PCs keine Java Viren gibt. Sie würden dadurch nur auffallen. Auf Handys wäre ich mir mit dem "keine Java Viren" nicht so sicher.
-
~john schrieb:
-fricky- schrieb:
ob ein programm nun bugs einer vm oder eines betriebssystems ausnutzt, um böses zu tun, ist im prinzip das selbe.
Nein, der äquivalente Fehler wäre ein Bug in der MMU, der es erlaubte das OS direkt überschreiben zu können.
...und ein äquivalenter fehler auf software-ebene wäre eine sicherheitslücke, die es z.b. usern mit guest-account erlaubt, dem kernel code unterzujubeln.
~john schrieb:
Der kleinste Fehler in der JVM hebelt sie komplett aus! Das ist der Unterschied. Ein simpler Fehler im OS bedeutet nicht gleich den GAU.
im gegenteil. selbst grobe fehler in der VM können dem sicherheitskonzept des OS nichts anhaben. es sei denn, das OS selbst ist total buggy. eine VM ist im normalfall ein einfacher benutzerprozess, über den das OS die volle kontrolle hat. versucht die VM, oder client-code der VM, irgendwas unerlaubtes, dann sollte ein gutes OS sowas zu verhindern wissen.
~john schrieb:
-fricky- schrieb:
vielleicht ist das auch der grund, warum es nicht wirklich viele schlimme viren gibt, die in Java programmiert wurden.
Auf Handys wäre ich mir mit dem "keine Java Viren" nicht so sicher.
so weit ich weiss, nutzen die meisten handy-viren sicherheitslücken und bugs des betriebssystems. auf der ebene können sie auch viel mehr ausrichten. java-viren auf handys sind sicherlich für netzbasierte attacken wie 'phishing', usw. sehr beliebt, aber weniger für zerstörerische aktionen.
-
Tut mir leid ich habe nur den Anfang des Threaads gelesen, trotzdem möchte ich was dazu schreiben:
Eine Sprache mit der man Hardwarenah programmieren kann, kann nie langsammer sein als Hardware.
-
neoexpert schrieb:
Eine Sprache mit der man Hardwarenah programmieren kann, kann nie langsammer sein als Hardware.
ist das eine art naturgesetz?
-
Ja bei C++ hängt die geschwindigkeit der anwendungen von erfahrung des Programmierers ab.
In C++ code kann man auch direkt Assemblercode einbauen, und schneller als Assembler ist nichts.