Software > Alternative Betriebssysteme

Alte Programme und deren Probleme mit Speicherschutz

<< < (3/3)

mfro:

--- Zitat von: HelmutK am Fr 01.06.2018, 22:06:06 ---Kann man nicht auch setjmp im message-handler im AES aufrufen, und dann anstelle des Alerts in diesen zurückspringen, und an den Aufrufer einen Fehlercode zurückgeben?

Nur so eine Idee, ob das geht weiß ich nicht.

--- Ende Zitat ---

Die Gefahr eines Supervisor-Stack-Überlaufs da leider ziemlich wahrscheinlich. setjmp() sichert den gesamten CPU-Kontext und Supervisor-Stackspace im AES ist meist knapp.

KarlMüller:

--- Zitat von: Thorsten Otto am Fr 01.06.2018, 18:56:38 ---Bei Gemscript glaube ich auch.

--- Ende Zitat ---
Da wird auch eine Struktur verschickt.


--- Zitat von: Thorsten Otto am Fr 01.06.2018, 18:56:38 ---
--- Zitat von: KarlMüller am Fr 01.06.2018, 08:15:48 ---beim SE-Protokoll und DHST wird, wie Du schon vermutest, eine Struktur verschickt.

--- Ende Zitat ---
Das sind aber Protokolle die nur von wenigen Programmen benutzt werden. Müsste man im Zweifelsfall mal prüfen, aber ich gehe davon aus daß diese Programme in der Beziehung "sauber" sind.

--- Ende Zitat ---
Beim SE-Protokoll würde ich Dir recht geben, aber DHST ist schon verbreitet. Allerdings bin ich auch Meinung das die Programme die es nutzen so jung sind das der Speicherschutz beachtet wird.

Wenn man ein Protokoll abfangen möchte scheint das AV am wichtigsten zu sein, denn das ist das Älteste  und meist verbreiteste und wurde zu einer Zeit entwickelt als man dem Speicherschutzt noch keine Beachtung schenkte oder musste.

Es wir eh ein schwierges unterfangen alles abzufangen. Man muß sich ja nur die Liste an Nachrichten im tos.hyp anschauen um zu erkennen das da einges zum Abstürzen kommen könnte.

Thorsten Otto:

--- Zitat von: HelmutK am Fr 01.06.2018, 22:06:06 ---Nur so eine Idee, ob das geht weiß ich nicht.

--- Ende Zitat ---

Nein, das geht nicht. Das ist Teil des AES, bzw. des Kernel, man kann dort nicht einfach in die Anwendung zurück springen. Was im Grunde nur fehlt ist die Möglichkeit das Alert-Level des Kernels abzufragen und zu setzen, dann könnte das von vornherein vermeiden,


--- Zitat von: mfro ---Supervisor-Stackspace im AES ist meist knapp.
--- Ende Zitat ---

Das wäre in diesem Fall wohl nicht so problematisch. Es betrifft ja nur MP, sprich MiNT, und dort ist der Stackspace nicht so knapp.

HelmutK:
Es soll ja nicht in die Anwendung gesprungen werden, sondern innerhalb vom AES.

- setjmp im AES-message-handler
- msg verarbeiten, verschicken
- Memory-violation im Client
- signal-handler im AES
- longjmp in den message-handler
- Fehler zurück zum Sender

So hatte ich mir das vorgestellt, aber ich bin da auch nicht so im Thema zur Zeit.

Naja, geht wohl wirklich nicht, weil der client nach der memory-viiolation nicht weiß, wie es weiter gehen soll.

Navigation

[0] Themen-Index

[*] Vorherige Sete