[NEWS] Microsoft entwickelt neues "sicheres" OS - auf Basis von C#
-
Sprich die packen einfach die VM in Ring0. Sind die verrückt? Was erzählen die eigentlich von Sicherheit anstelle von Performance?Sprich jeder Fehler in der VM legt den ganzen Computer lahm. Ein hängender SIP und der Rechner hängt.
Ich dachte an so etwas:
µKernel ---> VM(Programm)
Also geht es denen doch um Performance.
-
Also so wie ich das verstehe, soll der Kernel die VM sein. Also nur ganz ganz wenig Code für die Initialisierung der VM wahrscheinlich in ASM und ab diesem Punkt sollen dann schon die Kernel Dienste in der VM laufen.
Genau darum glaube ich, dass davon eine Sprache wie C# deutlich an Performance gewinnen wird - auch wenn die eigentliche Performance realistisch gesehen einem C Kernel ganz klar nachsteht wird.
-
@kingruedi soweit ich in dem windows file gelesen hab sieht die architekture so aus wie du sagst
ftp://ftp.research.microsoft.com/pub/tr/TR-2005-135.pdf
seite 7 ist die architecture
-
Hoffe ein Mod hält den Thread hier auch sauber vor unnötigen Diskussionen, die News hab ich auf anderen Seiten schon kommen und gehen sehen, weil die wieder gelöscht werden mussten, weil die ganzen Kommentare verschiedenster Art(meist unqualifizierte Aussagen von Fanatikern einer OS Ecke) keine weitere Diskussion zuließen.
Erstmal, Singularity wurde schon Ende August auf Channel9 vorgestellt in einem Video und es gibt auch schon von Ende 2004 eine Präsentation über das Projekt. Soviel erstmal zur Aktualität der News
.Aber nun mal zur technisches Seite. Singularity ist ja ein reines Forschungsprojekt. Es ist der Versuch ein OS vollkommen in managed Code(sprich .Net Code) zu schreiben, was wohl auch prima gelungen ist. Der Channel9 Blog geht ziemlich auf die einzelnen technischen Details ein. Außer ein klein wenig Assembler für Interrupthandling auf LowLevel Ebene, ist ja das gesamte OS in C# geschrieben. Das ist schon ein gewaltiger technischer Fortschritt(gab ja wohl auch für Java Versuche, aber glaube MS hat als einzige die Manpower um das wirklich fertigzustellen und in zukünftige Produkte mal zu adoptieren).
Managed Code ist von Haus aus schon sicherer als normaler Code, schon das Sicherheitssystem vom .Net Framework ist sehr gut - Optimizer hat ja die AppDomains z.b. schon angesprochen. Bei Singularity gibts ja eine VM im ursprünglichen Sinne nicht mehr, da dort das OS ja selber die VM darstellt. Also verständlich dass das von der Performance nicht wirklich schlechter sein kann.
Also ich bin echt gespannt was die da in Zukunft noch so machen, bin ja eh begeisteter .Net Fan
Aber auch die anderen Projekte bei MS Research sind schon cool wenn man sich di mal durchschaut. Kenn selber einen der in Cambridge dort arbeitet, und der hat mal bissle über KI erzählt. Schon echt interessant.
-
kingruedi schrieb:
Sprich die packen einfach die VM in Ring0. Sind die verrückt? Was erzählen die eigentlich von Sicherheit anstelle von Performance?Sprich jeder Fehler in der VM legt den ganzen Computer lahm. Ein hängender SIP und der Rechner hängt.
Ich dachte an so etwas:
µKernel ---> VM(Programm)
Also geht es denen doch um Performance.
Naja ein Treiber ist heute auch im Ring 0. Und einem ATI-Grafikkarten-Treiber traue ich fast noch weniger.
Wie der Ring 0 in Singularity aussieht, weiß ich zwar nicht, aber ich finde es z.B. sinnvoll, die Adress-checks zu entfernen. Ich kann für C#-Programme ohne unsafe code mit "Sicherheit" sagen, dass sie nicht versuchen werden, auf prozessfremden Speicher zuzugreifen, also warum jede Adressierung überprüfen?µKernel ---> VM(Programm)
So dachte ich es auch, vielleicht habe ich irgendwo was anderes gesagt, wie ich meine?
-
-
Optimizer schrieb:
Naja ein Treiber ist heute auch im Ring 0. Und einem ATI-Grafikkarten-Treiber traue ich fast noch weniger.
Wie der Ring 0 in Singularity aussieht, weiß ich zwar nicht, aber ich finde es z.B. sinnvoll, die Adress-checks zu entfernen. Ich kann für C#-Programme ohne unsafe code mit "Sicherheit" sagen, dass sie nicht versuchen werden, auf prozessfremden Speicher zuzugreifen, also warum jede Adressierung überprüfen?die agieren auf ring 0 wieso das den? Die haben ihren eigenen prozessor
-
mosta schrieb:
Optimizer schrieb:
Naja ein Treiber ist heute auch im Ring 0. Und einem ATI-Grafikkarten-Treiber traue ich fast noch weniger.
Wie der Ring 0 in Singularity aussieht, weiß ich zwar nicht, aber ich finde es z.B. sinnvoll, die Adress-checks zu entfernen. Ich kann für C#-Programme ohne unsafe code mit "Sicherheit" sagen, dass sie nicht versuchen werden, auf prozessfremden Speicher zuzugreifen, also warum jede Adressierung überprüfen?die agieren auf ring 0 wieso das den? Die haben ihren eigenen prozessor
Na also die kommunizieren ja schon irgendwie auch noch mit dem Betriebssystem. Ist Ring 0 nicht der kernel mode?
Wikipedia schrieb:
Unter Windows ist ein Gerätetreiber eine Sammlung von Funktionen, die im Kernelmode laufen
-
Optimizer schrieb:
Naja ein Treiber ist heute auch im Ring 0. Und einem ATI-Grafikkarten-Treiber traue ich fast noch weniger.
Wie der Ring 0 in Singularity aussieht, weiß ich zwar nicht, aber ich finde es z.B. sinnvoll, die Adress-checks zu entfernen. Ich kann für C#-Programme ohne unsafe code mit "Sicherheit" sagen, dass sie nicht versuchen werden, auf prozessfremden Speicher zuzugreifen, also warum jede Adressierung überprüfen?Natürlich ist das bisherige Treiber Konzept auch nicht gut gelungen. Die Archillesferse der meisten Betriebssysteme. Aber so etwas versucht man ja mit µKernel entgegen zu wirken. Treiber sollten auch nur im Usermode laufen. Bei neuen µKernel wird ja so viel wie möglich in den Usermode verlagert.
Singularity macht es anders, die verlagern alles in den Kernelmode. Ich halte das nicht für sinnvoll, da jeder kleine Fehler zu einem Systemfehler wird.
Die Addressierung wird doch eh von der Hardware geprüft. Ich denke eh, dass man den Ansatz wahrscheinlich durch die richtige hardware lösen sollte.
µKernel ---> VM(Programm)
So dachte ich es auch, vielleicht habe ich irgendwo was anderes gesagt, wie ich meine?
naja, der Pfeil sollte die Verschiebung auf die Usermode Ebene darstellen
-
aber was soll das verschieben in eine vm für vorteile bringen ausser mehr overhead . Das kann man doch auch mit threads realisieren. Nur hast du bei der thread lösung nicht jedesmal ne vm dazwischen die für mehr aufwand sorgt und an abstraktionsschichten fehlt es dem win doch nicht
-
Talla schrieb:
Also ich bin echt gespannt was die da in Zukunft noch so machen, bin ja eh begeisteter .Net Fan
Aber auch die anderen Projekte bei MS Research sind schon cool wenn man sich di mal durchschaut. Kenn selber einen der in Cambridge dort arbeitet, und der hat mal bissle über KI erzählt. Schon echt interessant.kannste da mal was genaueres zu sagen weil KI Projekte ja meistens intressant sind;-)
-
mosta schrieb:
aber was soll das verschieben in eine vm für vorteile bringen ausser mehr overhead . Das kann man doch auch mit threads realisieren. Nur hast du bei der thread lösung nicht jedesmal ne vm dazwischen die für mehr aufwand sorgt und an abstraktionsschichten fehlt es dem win doch nicht
Die VM führt eben so etwas durch, wie Pointer Prüfung, Garbage Collection etc.
-
und was hat es für nachteile sowas gleich ins os zu packen bzw. als service oder so zu laufen
-
kingruedi schrieb:
Singularity macht es anders, die verlagern alles in den Kernelmode. Ich halte das nicht für sinnvoll, da jeder kleine Fehler zu einem Systemfehler wird.
... jeder Fehler in der VM, ja. Das sehe ich jetzt insgesamt als Vorteil an. Im Moment haben wir von x Herstellern y verschiedene Treiber, alle im niedrigsten Sicherheitsring. Hier ist nach meinem Verständnis geplant, dass nur die VM im niedrigsten Sicherheitsring laufen soll. Die VM mag vielleicht oft instanziert werden, aber im Großen und Ganzen ist die Codemenge, die jetzt ohne jede Kontrolle ausgeführt wird, doch geringer, oder? Jetzt gibt es nur noch ein Programm, wo es echt fatal ist, wenn Programmierfehler drin sind, im Moment sind das vergleichsweise viele.
Die Addressierung wird doch eh von der Hardware geprüft. Ich denke eh, dass man den Ansatz wahrscheinlich durch die richtige hardware lösen sollte.
So lange es notwendig ist, jedem Prozess einen Adressraum zuzuordnen und die Adressierung zu prüfen, stimme ich dir natürlich voll zu, dass es die Hardware machen sollte und keine VM. So ist es ja auch. Wenn es jedoch konzeptionell nicht möglich ist, auf prozessfremden Speicher zuzugreifen, warum sollte man dann so eine Prüfung beibehalten? Ich weiß nicht, ob das nach deren Vision komplett entfallen kann, für ein C#-Programm ohne "unsafe code" ist so eine Prüfung jedoch mit Sicherheit (außer vielleicht auf null-Pointer) unnötig. Zum Ausgleich müssen andere Prüfungen (bounds checking) oder Vorschriften (zwingend initialisierte Variablen) gemacht werden, die früher greifen, um das ganze System aufrecht zu erhalten.
-
Optimizer schrieb:
kingruedi schrieb:
Singularity macht es anders, die verlagern alles in den Kernelmode. Ich halte das nicht für sinnvoll, da jeder kleine Fehler zu einem Systemfehler wird.
... jeder Fehler in der VM, ja. Das sehe ich jetzt insgesamt als Vorteil an. Im Moment haben wir von x Herstellern y verschiedene Treiber, alle im niedrigsten Sicherheitsring. Hier ist nach meinem Verständnis geplant, dass nur die VM im niedrigsten Sicherheitsring laufen soll. Die VM mag vielleicht oft instanziert werden, aber im Großen und Ganzen ist die Codemenge, die jetzt ohne jede Kontrolle ausgeführt wird, doch geringer, oder? Jetzt gibt es nur noch ein Programm, wo es echt fatal ist, wenn Programmierfehler drin sind, im Moment sind das vergleichsweise viele.
aber die treiber müssen doch immer auf der niedrigsten ebene laufen, da die doch die funktionalität bieten oder hab ich da nen denkfehler? und ich denk zurzeit sind doch soviele funktionen wie möglich als services implementiert oder ist das nur in linux so?
-
For example, because SIPs are so cheap to create and enforce, Singularity runs each program, device driver, or system extension in its own SIP.
Sieht also so aus, als würde jedes Programm mit Ausnahme der VM in so einem SIP laufen.
