Ich kenne mich mit dem Kernel nicht aus und weiß nicht wie er die Module nachlädt, dennoch denke ich, dass der Kernel selbst da nicht ganz unschuldig ist. Wenn meine Programme Plugins oder externe Module nachladen, dann haben sie nur wohldefinierte Speicherbereiche auf die sie zugreifen können. Wenn es der NVIDIA BLOB kann, dann können es auch sicher andere Module, ob BLOB oder nicht BLOB.
Die Module laufen im Ring0, sprich sind Teil des Kernels. Ansonsten könntest Du viele Treiber oder Subsysteme gar nicht in Module auslagern. Sprich Du hast einen großen monolithischen Kernel in den Distributionen. Für einen kleineren Memory Footprint würdest einen auf Dein System zugeschnitten Kernel kompilieren müssen.
Das Sandbox Prinzip oder ähnliche Mechanismen zu Trennung sind sicher oft möglich, wann man nicht sehr auf Geschwindigkeit angewiesen ist.
Bei NVidia ergibt sich aus Binary-Only das größere Problem, die Kernel Community kann keinen Code Review machen. Daher ist es eher eine Frage ob eine Sandbox für Binary Module sinnvoll oder sogar notwendig ist.
Von -.,-,-,-,.-,-., am Do, 2. August 2012 um 20:56 #
Natürlich ist der Kernel daran nicht ganz unschuldig. Der Kernel dürfte den Blob überhaupt nicht laden, weil der NVidia-Treiber unfrei ist. Na ja, wenigstens sind die Sicherheitslücken frei Haus.
Und in welcher Sprache sind deine Programme (und Plugins) geschrieben? Java, Python o.Ä.? Wenn sie in C/C++ geschrieben sind muss ich dir mitteilen, dass nachgeladene Plugins Zugriff auf den gesamten Speicher deines Programmes haben (wenn du nicht gerade eine Art Sandboxing verwendest).
Wenn du schon nicht weißt wie ein Kernel seine Module bzw. Treiber lädt, warum glaubst du dann es wäre eine gute Idee Schuldzuweisungen auszusprechen??
Ich kenne mich mit dem Kernel nicht aus und weiß nicht wie er die Module nachlädt, dennoch denke ich, dass der Kernel selbst da nicht ganz unschuldig ist. Wenn meine Programme Plugins oder externe Module nachladen, dann haben sie nur wohldefinierte Speicherbereiche auf die sie zugreifen können. Wenn es der NVIDIA BLOB kann, dann können es auch sicher andere Module, ob BLOB oder nicht BLOB.
Die Module laufen im Ring0, sprich sind Teil des Kernels. Ansonsten könntest Du viele Treiber oder Subsysteme gar nicht in Module auslagern. Sprich Du hast einen großen monolithischen Kernel in den Distributionen. Für einen kleineren Memory Footprint würdest einen auf Dein System zugeschnitten Kernel kompilieren müssen.
Das Sandbox Prinzip oder ähnliche Mechanismen zu Trennung sind sicher oft möglich, wann man nicht sehr auf Geschwindigkeit angewiesen ist.
Bei NVidia ergibt sich aus Binary-Only das größere Problem, die Kernel Community kann keinen Code Review machen. Daher ist es eher eine Frage ob eine Sandbox für Binary Module sinnvoll oder sogar notwendig ist.
Natürlich ist der Kernel daran nicht ganz unschuldig.
Der Kernel dürfte den Blob überhaupt nicht laden, weil der NVidia-Treiber unfrei ist.
Na ja, wenigstens sind die Sicherheitslücken frei Haus.
Und in welcher Sprache sind deine Programme (und Plugins) geschrieben? Java, Python o.Ä.? Wenn sie in C/C++ geschrieben sind muss ich dir mitteilen, dass nachgeladene Plugins Zugriff auf den gesamten Speicher deines Programmes haben (wenn du nicht gerade eine Art Sandboxing verwendest).
Wenn du schon nicht weißt wie ein Kernel seine Module bzw. Treiber lädt, warum glaubst du dann es wäre eine gute Idee Schuldzuweisungen auszusprechen??
Grüße,
unreal
> dennoch denke ich, dass der Kernel selbst da nicht ganz unschuldig ist.
Völlig korrekt, denn mit einem Microkernel wäre das nicht passiert.
lasset das flaming beginnen..