Artikel lesen
Druckbare Version
Klingt Gut! Microsoft muss mit Windows Phone den unerforschten Ozean erobern, die Gebite und Leute die noch nie ein Smartphone hatten und somit gliech mit Windows Phone "aufwachsen". Und nicht erst getrügt werden durch den Schein eines Asteroiden oder ein biss in den (sauren) Apfel...
C++ Support klingt auch sehr positiv. So öffnet man sich auch einem größeren Feld an Entwicklern, die nicht im .NET Universum zu Hause sind. Würde mich nicht wundern wenn man ähnlich wie bei Windows 8 die Oberflächen in HTML 5 erstellen kann. Wenn schon nicht über Silverlight/Xaml, dann muss ja eine alternative her.
Schauen wir mal wie es umgesetzt wird =)
Würde durch C++ das unlocken einfacher?
Mit der kostenlosen PocketPC.ch App von meinem 7 Mozart aus geschrieben.
hmm, vielleicht. Man darf dann halt code ausführen, der über die Silverlight API hinausgeht. also etwa die Registry betrifft. Ich denke aber, auch hier wird eingeschränkt, sonst wäre ja der ganze closed market Weg futsch und die Sicherheit genauso wie bei Android in Gefahr.
klingt ja alles ganz nett.
Nur gibt es da nicht zuerst noch einige andere Baustellen, welche geschlossen werden sollten? z.B. eine vernünftige Backup-Möglichkeit oder ein "businesstauglicher" Kalender?
Oder bin er der einzige der diese Funktionen braucht oder besser, sind die Funktionen mit Tango sogar integriert?
Ich bin echt zufrieden mit WP7, nur die Businesstauglichkeit ist schon noch verbesserungswürdig und würde die Absatzchancen aus meiner Sicht wohl eher verbessern.
WP7 ist halt leider nicht explizit auf den Business-Markt ausgerichtet. Ich würd mir auch mehr Funktionalität diesbezüglich wünschen. Das mit dem Kalender und Exchange geht ja schon ganz gut, aber dass MS es nicht schafft, die MIME-Implementation sauber zu machen, so dass man auch die Anhänge signierter E-Mails lesen kann, ist unverständlich
Oder wie wärs denn mit nem einfachen Umlaut-Bugfix?
Sicher gibt's noch einige große Baustellen, aber wenn man das mal aus Sicht der Einwohner in den betroffenen Ländern sieht, dann ist für die die Sprachunterstützung sicher das wichtigste. Es kamen ja auch hier im Forum z.B. Anfragen ob WP7 auch türkisch kann, die User werden jetzt vermutlich zufriedengestellt.
Bei Nativ ausführbarem Code assoziiere ich direkt die nächsten Botnetz Meldungen für Windows Phone 7. Eigentlich sollten wir soweit sein, dass bei Hauptsächlich online geführten Geräten nativ ausgeführter Code strikt nicht erlaubt ist.
Hä?Zitat:
Zitat von KnightNoir
Mit der kostenlosen PocketPC.ch App von meinem 7 Mozart aus geschrieben.
Nativ heißt doch das zb auf den kernel direct zugegriffen werden kann wie bei Android?
Wenn dann kommen bald die ersten Apps mit telefon zugriff und es werden fleißig Premiumnummern angerfufen
Ich trau mich wetten, dass es so etwas nie und nimmer ohne Einschränkungen geben wird. Wenn man die aktuellen Restriktionen betrachtet (einige machen durchaus Sinn), und mit Kernelzugriff vergleicht, dann ist das wie Tag und Nacht.
Bei Nativ laufendem Code hat man quasi direkten Zugriff auf den Speicher und auf Systemcalls. Das macht es (relativ) einfach, Schadcode auszuführen. Der Druck auf die Programmierer steigt dadurch, ihre Anwendungen sicher zu gestalten. Das ist aber alles andere als Simpel. Vor allen Dingen aber bei Anwendungen die Informationen aus dem Internet laden muss man dann aufpassen, dass durch JavaScript und ähnliche Techniken nicht einfach so Schadcode in den Speicher geschoben werden kann (Stichwort: Alternative Browser). Je nachdem welche Mängel das System hat (z.B. mangelndes ASLR) oder aber welche Exploits existieren, können dann Apps auch (relativ) einfach das ganze Missbrauchen um Daten abzugreifen, anrufe zu tätigen usw. auch ohne das der Anwender das merkt.Zitat:
Zitat von Geosammler
Das Umgeht man Momentan indem man wie bei .net die Anwendungen in eine Sandbox packt, bzw. den Anwendungen nur eine begrenzte Api zur Verfügung stellt (beides macht WinPhone soweit ich weiß, das ist auch der Grund warum Apple die Api begrenzt hat). Auf dem PC Windows benutzt man aus diesem Grund auch .net mit C# oder Visual C++ oder eben Java das in einer VM läuft. Das ganze nennt sich managed code (ein MS begriff, es darf gegooglet werden!).
Sicher ist der Geschwindigkeitsvorteil von nativem Code nicht zu verachten, aber der Tradeoff zwischen Sicherheit und Geschwindigkeit muss immer zu gunsten der Sicherheit ausgehen. Bei einem Smartphone ist mir aber die Sicherheit lieber, im Zweifelsfall kann ich lieber ein Spiel nicht spielen als dass mein Adressbuch bei irgendwelchen Leuten landet, die es ausspähen. Viele Firmen haben deshalb auch ein Problem damit, Android in ihre IT-Struktur zu integrieren und weichen auf Blackberry, iPhone und hoffentlich bald Windows Phone aus.
Bei der tatsächlichen Gefahr von Native Code muss ich jetzt mal einhaken. Rufe ich ein API auf in Managed Code wird so es eine Systemfunktion betrifft ja dann trotzdem von der CLR der Kernel aufgerufen (anders ginge es ja gar nicht). Ist der entsprechende Aufruf per Security Policy verboten wird er nicht durchgeführt. Ähnliche Policies kann ich jedoch auch für Managed Code gestalten, genauso wie eine Sand Box durchaus auch für Native Code möglich ist (beim iPhone nennt man die halt ein Jail und der Jailbreak ist das ausbrechen aus der Sandbox).
Microsoft führt z.B. am Desktop den Internet Explorer mit geringeren Rechten aus als die Rechte, die der User an und für sich zur Verfügung hätte. Das stellt wieder eine zusätzliche Hürde da.
Native Code ist also mitnichten synonym zu sehen mit unbeschränktem Zugriff auf das System bzw. auf APIs. Metro-Anwendungen unter Windows 8 die mit C++ geschrieben werden bekommen auch nicht automatisch vollen Systemzugriff und müssen mit den APIs der WinRT ein Auslangen finden.
Was momentan aber tatsächlich stimmt ist, dass man sobald man mal Native Code ausführen kann auf WP7 mit Hacks (hauptsächlich über die schlecht abgesicherten Tools der Gerätehersteller) Zugriff auf weitergehende Systemfunktionen bekommt.
Was Managed Code sicherer macht ist die Tatsache, dass die darin geschriebenen Programme manche Sicherheitsprobleme gar nicht aufweisen können, da wenn der Programmierer sie übersieht die CLR diese erkennt und abfängt (Buffer Overflows, Null-Pointer, etc.) Diese zusätzlichen Checks sind ja auch mit ein Grund für die schlechtere Performance. Das Zulassen von Native Code führt aber definitiv nicht automatisch dazu, dass das System sperrangelweit offen steht.
Wir sollten mal definieren was nativer Code ist: Ich verstehe darunter Code der in Maschinensprache umgewandelt wird und dann auf der Hardware ausgeführt wird (so hab ichs im Studium gelernt und finde es auch bei Wikipedia ;) )Zitat:
Zitat von StevieBallz
Eine Sandbox für nativen Code müsste also die Maschinensprache interpretieren und auf einer Virtuellen Maschine ausführen, um die Zugriffe zu kontrollieren, wo wir dann wieder beim Managed Code wären (ob das nun Bytecode, Zwischencode oder Assembler ist spielt ja keine Rolle). Damit haben wir dann faktisch keinen nativen Code mehr. Der Aufruf von Apis in Nativem Code kann wenn ich mich recht erinnere auch zur "Laufzeit" nicht überwacht werden.
Aber du hast recht man verlagert das Problem nur in die Sandbox, Jail, VM wie auch immer man das sehen will. Allerdings kann man dort zur Laufzeit des Programmes z.B. über den CLR (dafür ist der ja gemacht und er arbeitet mit Zwischencode) die Aufrufe des ausgeführten Programms überwachen und ggf. abfangen.
Da stellt sich die Frage ob der IE Managed läuft oder nicht. Soweit ich weiß nicht. Exploiting funktioniert ja in der Regel so, dass man eine Methode über eine Eingabe dazu bewegt beliebige Informationen in den Speicher zu schreiben. Dazu ist es notwendig das die Methode das entweder anbietet oder eben einen Bug hat. Bei nativem Code kann eigentlich nichts die Methode aufhalten. Bei Managed Code würde die Beschränkung der Sandbox greifen. Allerdings führt ein Exploit in der Sandbox natürlich wiederrum zum gleichen problem.Zitat:
Zitat von StevieBallz
Da unter Windows C++ Managed (visual C++) und unmanaged funktioniert ist C++ nicht zwangsläufig Synonym für native Ausführung. Ich hab nun die Metrofunktionalität noch nicht angeschaut, aber würde mal behaupten, es handelt sich dabei um eine in .net umgesetzte Managed Code Geschichte, an denen hat Microsoft aufgrund der Sicherheitsaspekte hohes interesse.Zitat:
Zitat von StevieBallz
Alternativ könnte man bei der Kompilierung schon überwachen was passiert, allerdings würde man damit die Möglichkeit der Manipulation eröffnen, sofern nicht MS selbst die Sachen kompiliert oder aber in irgend einer Form eine Zertifizierung entwirft, die Verifiziert, dass ein korrekter Compiler verwendet wurde. Da halte ich Managed Code aber ebenfalls für Wahrscheinlicher und auch Sinnvoller.
Das hab ich auch nicht geschrieben ;) Allerdings wird die Wahrscheinlichkeit, dass Schadprogramme Zugriff bekommen drastisch erhöht und viel Verantwortung an die Entwickler weiter gegeben, die damit auch erst mal umgehen müssen.Zitat:
Zitat von StevieBallz
Eine Möglichkeit das zu verhindern wäre z.B. das Microsoft die Programme signieren muss und vorher einer Prüfung unterzieht und dabei untersucht ob bestimmte System Calls getätigt werden.
Da unterschätzt du die Möglichkeiten des Betriebssystems relativ stark. Natürlich setzt das auch eine gewisse Unterstützung auf Hardwareebene vorraus aber die ist seit dem 80386 von Intel gegeben und auch auf den ARM-CPUs so. Bloß weil Code schon in Maschinensprache übersetzt ist, bedeutet das nicht, dass er tun und lassen kann was er will.
Das geht schon damit los, dass jeder Prozess seinen eigenen virtuellen Adressraum bekommt, der dann vom Betriebssystem mit Hardwareunterstützung auf physische Adressen abgebildet wird. Was nicht in diesen virtuellen Adressraum eingeblendet wird ist für das Programm auch nicht erreichbar.
Dass ein Programm sobald es läuft nicht alles tun und lassen kann was es will zeigt sich doch auf jedem Windows-System im Firmenumfeld. Die Überprüfung von Zugriffsberechtigungen auf Dateien prüft das Betriebssystem, nicht die laufende Software. Wenn ich Assembler programmiere bin ich programmiertechnisch schon so nahe am Maschinencode wie nur irgend geht - da übersetzen sich die Befehle meistens 1:1 in einen CPU-Befehl (mussten im Studium das auch von Hand umschreiben aber das ist ein anderes Thema). Will ich eine Datei lesen muss ich den Pfad in den Speicher schreiben und dann einen bestimmten Interrupt auslösen bei entsprechendem Registerinhalt, damit das Betriebssystem die Datei öffnet und mir die Daten daraus zur Verfügung stellt. Direkt auf den Festplattentreiber kann ich so nicht zugreifen. Und der virtuelle Adressraum verhindert auch dass ich direkt die Hardware mit einem eigenen Treiber anspreche.
Den Aufruf der API kann ich so nicht verhindern, jedoch kann das Betriebssystem wenn der Aufruf kommt innerhalb dieses Aufrufs (der ja im Kontext des Betriebssystems stattfindet) überprüfen ob der Aufrufer (der ist ja bekannt, sonst könnte man ihm nichts zurückgeben) die entsprechende Berechtigung hat und sonst gibt man halt gleich zu diesem zurück ohne die gewünschte Aktion auszuführen - oder beendet den Prozess wegen einer Zugriffsverletzung.
Bei den meisten Exploits geht es auch weniger darum den auszuführenden Code in den Speicher des Ziels zu kriegen sondern eher darum dieses dann dazu zu bringen, den auch auszuführen. Bei Buffer-Overflows geht das z.B. so, dass man soweit über das Ende des Puffers schreibt, dass man das eigentliche Programm überschreibt und im weiteren Verlauf dann dieser Code ausgeführt wird. Problematisch ist dann also wenn der gekaperte Prozess Rechte hat mit denen er im System etwas tun kann. Ist dies nicht der Fall sind noch weitere Bugs in anderen Prozessen nötig um die Rechte soweit zu eskalieren, dass das Betriebssystem bereit ist die gewünschten Schritte auszuführen.
Das setzt aber auch ohne ASLR, etc. schon einiges an können voraus, da normalerweise das schreiben in nicht dafür vorgesehenen Speicher zu einem Segmentation Fault seitens des Betriebssystems führt.
Fakt ist: Native Code hat nicht komplett freie Hand auf einem System - auch wenn es direkte Maschinencode-Anweisungen sind.
Der C++ Anteil in Windows 8 Metro ist Native Code, es handelt sich nicht um Managed C++.
Nebenbei erwähnt führen Exploits in der CLR auch zu Sicherheitsprobleme aber ich muss sie dann nur in einer Komponente beheben statt in 1000en (das setzte der Java-VM eine Weile ganz schön zu). Allerdings haben das Problem dann auch gleichzeitig 1000e Apps statt einer (unterm Strich läuft aber meistens mehr Zeit in Security Audits einer VM als einzelner Apps, sodass die Sicherheit meistens von Managed Code mehr profitiert).
Nachdem Aufrufe sich aus Speicheradressen und Registerinhalten zusammensetzen ist eine statische Analyse welche Aufrufe Native Code macht nicht so ohne weiteres möglich. Man müsste alle möglichen Ausführungspfade prüfen (eine potentiell enorme Menge). Vor ähnlichen Problemen steht die Analyse bei .Net wenn die Aufrufe per Reflection passieren (da ist ein Check auch erst zur Laufzeit möglich). Das Problem mit Reflection äußert sich bei WP7 konkret darin, dass wenn ich bestimmte Methoden nur via Reflection aufrufe, die zur Ausführung eine bestimmte Permission brauchen (z.B. GPS-Zugriff), die bei Aufnahme in den Marketplace nicht erkannt wird => meine App hat die Permission auf dem Gerät dann nicht und stürzt ab wenn sie versucht die GPS-Koordinaten zu bestimmen.
Das Problem ist einfach, dass es bei nativem Code zig Möglichkeiten gibt, Lücken zu nutzen. Das ganze lässt sich auch nicht wegdiskutieren. Ich habe nicht gesagt das dann allem Tür und Tor offen steht, sondern dass die Sicherheit darunter leidet. Das ist nun mal leider ein Fakt. Simplerweise weil meine Sicherheitslücke in der Sandbox zu suchen ist, was zugegebener Maßen auch passieren kann, aber einfach viel weniger da ist, was nicht gut Programmiert worden ist.
Du hast auch recht, aber wenn ich jetzt hier anfange das bis auf Heller und Pfennig zu zerlegen wie was überprüft wird und was dabei vor sich geht und wie man was umgehen kann, dann werden das 100te von Seiten. Z.B. reicht es aus Rootrechte zu bekommen und seinen Code auszuführen um direkt ne Berechtigung für quasi alles zu bekommen und dafür muss ich quasi nur eine geeignete Lücke finden ein Rootkit zu installieren, was wie wir wissen bei Windows kein großes Problem bisher war, auch aufgrund der Größe des ganzen Systems. ALSR war bisher auch nur eine Hürde die man überspringen musste. Und wie ich selbst schon feststellen musste arbeiten auf der Gegenseite wirklich findige Programmierer und auch nicht so findige Programmierer mit Webbrowser Exploits ASLR umgehen können.
Nicht umsonst werden in vielen Hochsicherheitssystemen quasi nur noch Virtualisierungen verwendet um die Menge an Code klein zu halten, die überprüft werden muss.
Ich halte es nach wie vor nicht für Sinnvoll das nativer Code ausgeführt wird, weil die Vorteile so viel Geringer gegenüber den daraus entstehenden Nachteilen sind. Viel eher wäre ich dafür eine WinRT für die Spiele zu erstellen und zu optimieren um daraus den Geschwindigkeitsbonus zu erhalten.
Kurzes Googlen ergab übrigens folgendes:
http://i.stack.imgur.com/ZLtaJ.jpg
Wie ich es mir schon gedacht habe, läuft Metro in Windows 8 als managed Code.
Über die Grafiken gab es einiges an Diskussion (bzgl. deren Klarheit) aber was du hier siehst sind die WinRT-APIs auf denen dann entweder C#/VB.Net Managed läuft oder eben C++ mit nativem Zugriff (bzw. in C++ funktioniert das ganze dann über das altbekannte COM).
Nachzulesen, z.B. hier: http://www.heise.de/developer/artike...artikelseite=2
Jetzt erklär mir bitte noch warum das indirekte Aufrufen der Kernelfunktionen durch eine Komponente WinRT und die Com Methode (die MS nach Managed mit Native Code verbindet) nativer Code ist, während der gleiche Vorgang woanders Managed Code ist. Die WinRT (Windows Runtime) bietet eine Laufzeitumgebung in der C++ und C# sowie javascript Apps laufen, also alles Managed Code... Das WinRT dann nativ läuft ergibt sich, heißt aber längst nicht, dass eine C++ Metro Awendung nativ läuft.Zitat:
Zitat von StevieBallz
Wenn allerdings bei Win Phone das genauso umgesetzt werden soll, dann nehme ich alle zurück, dann ändert sich ja quasi nichts.
Mann, Mann, Mann, du und der StevieBallz, ihr schenkt euch nix, oder?
Kampf der Superbrains.... :P ;)
Aber wenigstens kann ich jetzt sicher sein, das mir hier von kompetenten Leuten Rat gegeben wird.... ;)
Mit der kostenlosen PocketPC.ch App von meinem 7 Mozart aus geschrieben.
Native Code => Code wird kompiliert und liegt in Maschinensprache vor, haben wir ja eingangs festgestellt. Dies ist bei WinRT und C++ der Fall. Also ich schreibe C++ Code und am Schluss kommt x86, x64 oder ARMv7 Maschinencode heraus. Speicher wird über die C-Standard APIs vom Betriebssystem angefordert, direkte Operationen auf den Speicheradressen inkl. Pointerarithmetik ist möglich.
Managed Code => Code wird kompiliert und liegt dann in MSIL vor, wird von der Common Language Runtime Just in Time in Maschinencode übersetzt (im Falle von Microsofts CLR nämlich immer, bei Javas Hot Spot VM nur die kritischen Teile). An dieser Stelle können noch zusätzliche Checks durchgeführt werden. Speicher wird von der CLR und dem dazugehörigen Garbage Collector verwaltet (auch bei Managed C++).
Die WinRT ist auch wenn sie Runtime heißt eigentlich keine Laufzeitumgebung wie die CLR sondern eine neue API zur Systemkommunikation, die Metro-Anwendungen anstatt des Win32-API nutzen (müssen). Letzten Endes wird hier bei Windows Phone und Windows 8 derselbe Mechanismus bzgl. Sandboxing genutzt werden. Also zumindest insofern ist es gleich sicher/unsicher. Aber was definitiv der Fall ist, ist dass eben der Code direkt in den Befehlssatz der Zielmaschine übersetzt wird => Native Code und er trotzdem nicht alles tun können wird.
Hier nochmal ein Bild das den Sachverhalt ein bisschen übersichtlicher darstellt als das von Microsoft damals bei der Präsentation genutzte (wie gesagt, es gab zu dem Bild aus genau den Gründen wieso wir hier diskutieren einige Unsicherheit): http://1.bp.blogspot.com/-uUSc-JjjBD...w-platform.png
Diese nativer Code Unterstützungsgeschichte hat aber nicht zufällig was mit dem Interop Unlock zu tun?
Oder ist der Interop Unlock wieder ganz was anderes (da wird auch von nativem Code geredet)?
Interop ist ein Verfahren, um nativen Code von Managed code aus aufzurufen. siehe http://pinvoke.net/