Java ist schneller als C++!

*john 0

hehehe schrieb:

Die JVM ist das OS für Java. Dein Argument hebt sich somit selber wieder auf.

Nein, die JVM ist nur unter ganz bestimmten Bedingungen mit einem OS vergleichbar, und zwar dann wenn sie das OS ersetzt. Im Regelfall ist sie nur eine Laufzeitumgebung, die die Stabilität des Programm verbessert und die mögliche Fehlersuche vereinfacht. Eine JVM auf einem normalen OS jedenfalls bietet keinerlei Sicherheit, denn die kann nur vom OS garantiert werden.

DEvent

Kenner der OS schrieb:

Und ja... die JVM mit ihrer Sandbox ist nur eine andere Abstraktionebene, aber kein besserer Effekt, als ob ich ein C++-Programm in einer Sandboxie oder Jail laufen lasse. Also was soll die Diskussion, das C++ unsicherer ist? Java-Programme sind es auch nicht, da dafür die JVM-Sandbox zuständig ist.

Mein Punkt war eigentlich der, das man bei Java alles schon standardmaessig hat, ob man will oder nicht. Also Java: Keine Wahl, bei anderen Programmen ist es Optional.

is halt so, hier wird die wirklichkeit einfach mit theoretischen möglichkeiten und spezialfällen vermischt und dann sind alle C++ Programme plötzlich theoretisch so sicher wie Java Programme praktisch immer sind.

~john schrieb:

Eine JVM auf einem normalen OS jedenfalls bietet keinerlei Sicherheit, denn die kann nur vom OS garantiert werden.

*räusper* http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-specTOC.fm.html

*john 0

-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. Lies Dir einfach die Infos zu TrustedSolaris bzw. SELinux durch und vergleich das ganze mit den üblichen Sandboxes.

http://www.sun.com/software/solaris/trustedsolaris/index.xml
http://www.nsa.gov/selinux/

P.S. Nur eine Frage Windows-Nutzer oder mit *I*X erfahren?

Gibt es einen Grund, warum ein OS Programmierer besser als ein VM Programmierer sein soll?

gegenfrage schrieb:

Gibt es einen Grund, warum ein OS Programmierer besser als ein VM Programmierer sein soll?

Ein OS hat ganz andere Möglichkeiten als eine VM, eine VM ist einfach nur eine normale Anwendung die im Userspace läuft.

und wie beantwortet das jetzt meine Frage?

gegenfrage schrieb:

und wie beantwortet das jetzt meine Frage?

Klaro, weil du jetzt merkst, dass deine Frage überflüssig ist und du einfach was in den falschen Hals bekommen hast.

*john 0

Es geht nicht darum, wer weniger Fehler macht. Aber die JVM läuft im selben Adreßraum wie die Applikation selbst, das OS üblicherweise nicht. Wenn es einen Bug/Exploit gibt, ist es sehr wahrscheinlich, daß das Programm aus der Sandbox ausbrechen kann, da man nun beliebigen Code der JVM überschreiben kann. (So wie dies bei einem Bufferoverflow passiert) So einfach ist es nicht aus dem Korsett des OS auszubrechen, da muß man schon deutlich mehr herumprobieren, denn die Trennung in logische Adreßräume läßt sich nicht so leicht austrickens.

Du setzt einfach vorraus, dass es im OS keinen Bug gibt der es ermöglich irgendwas zu hacken und das geht nur wenn die Programmierer besser wären.

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.

DEvent

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.

Wenn du das mit SELinux dir durchgelesen haettest,wuestest du das es nichts anderes macht als, die JavaVM.

Im Grunde sieht das in SELinux so aus:

Application File Access ---> SELinux Rechteverwaltung ----> File

In der JavaVM sieht das genauso aus:

Application File Access ---> JavaVM Rechteverwaltung ----> File

Nur ist das bei Java fest in der API/Sprache eingebaut, waehrend bei SELinux man Hooks im Kernel einbaut.

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.

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.

*john 0

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.

Simon2

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.