Ich lerne über verwalteten und nicht verwalteten Code in CLR. Also schrieb ich dieses Beispiel mit C-Style-Zeigern in C #:
%Vor%Ich frage mich also, was wirklich in IL-Code unsicher ist, dass ich aus dem obigen Code habe?
%Vor%Verwaltet CLR diesen Code? Und was kann mit einem obigen Code schiefgehen?
Was diesen Code unsicher macht, ist die Verwendung der Anweisung 'ldind.i4'. Dies lädt eine vorzeichenbehaftete 4-Byte-Ganzzahl aus einer Speicheradresse. Jede Speicheradresse kann angegeben werden, so dass Sie von jeder Speicheradresse im aktuellen Prozess lesen können. Dies gilt als unsicher und nicht verifizierbar. Zum Beispiel könnten Sie dies verwenden, um in andere App-Domains zu schauen, was nicht erlaubt ist.
Es heißt unsicher, teilweise weil es nicht verwaltet wird.
Sie können leicht Speicherausfälle im C ++ Stil erstellen, es gibt keine Grenzprüfungen und andere Probleme ...
Ein schöner Artikel über unsicheren Code, listet auch ein paar Risiken auf:
Unsicher bedeutet möglicherweise nicht gefährlich, aber in unsicheren Codes ist eine Sache wichtig: Sie ist nicht verifizierbar . Dies kann mehrere Dinge bedeuten, beispielsweise die Überprüfung der Grenzen eines Arrays. In Ihrem einfachen Beispiel. Es ist nicht so gefährlich oder beängstigend. Es ist ziemlich einfach.
In kann unsicher sein, da es auch die meisten Sicherheitsmechanismen in .NET Framework umgehen kann. Aus diesem Grund erfordert unsicherer Code trotzdem Full Trust.
Unsicher! = Nicht verwaltet. Unsafe bedeutet nur, dass es Zeiger manipulieren kann.
Im Allgemeinen ermöglicht Ihnen das Schlüsselwort unsafe den direkten Zugriff auf den Speicher und umgeht daher alle Verifizierungs- und Sicherheitsprüfungen durch die CLR.
Hier ist ein guter Artikel über die Verwendung und Auswirkung von unsafe code:
Ссылка
Standardmäßig erzeugen die C # - und Visual Basic.NET-Compiler von Microsoft "sicheren" Code. Sicherer Code ist Code, der nachweislich sicher ist. Wenn Sie jedoch das unsichere Schlüsselwort von C # verwenden oder andere Sprachen verwenden (z. B. C ++ mit Managed Extensions oder IL Assembly), können Sie Code erstellen, der nicht nachweisbar sicher sein kann. Das heißt, der Code könnte tatsächlich sicher sein, aber die Überprüfung ist nicht in der Lage, dies zu beweisen.
Ein Administrator kann die Verifizierung deaktivieren (mit der ".NET-Verwaltung" Microsoft) Management Console Snap-In). Wenn die Verifizierung deaktiviert ist, kompiliert der JIT-Compiler nicht verifizierbares IL in native CPU-Anweisungen; Der Administrator übernimmt jedoch die volle Verantwortung für das Verhalten des Codes.