Alte Programme und deren Probleme mit Speicherschutz

[Thorsten Otto]

... berüchtigtes Bsp., das imho per AES unlösbar ist.

Kein Geheimnis: Die TDI-Tools tauschen ihre Daten untereinander auch auf unsaubere Weise
[/quote]]

Das ist natürlich ungünstig, da kann man wenig machen. Im AES könnte man nur die bekannten, mehr oder wenigen offiziellen Protokolle fixen.

Speicher zu benutzen, der einem nicht selbst gehört, das war auch vor Erfindung von MP und Flags schon eine Schweinerei.

Naja, das müsste man dann eher den Designern der Protokolle vorwerfen. Die Programme können da wenig für, wenn sie sich an die Vorgaben halten. Ganz abgesehen davon, daß es ohne MiNT/MagiC auch gar keine Möglichkeit gibt, Shared-Memory anzufordern.

In dem Zusammenhang wäre auch mal interessant zu erfahren, was Virtuelle Memory-Manager wie OUTSIDE/VRAM da anstellen, wenn der Speicher nicht nur einem nicht gehört, sondern in einem anderen Prozess möglicherweise an einer Addresse eingeblendet wird.

[ari.tao]

Das Speicher-Problem trat in´s Bewußtsein, als es MultiTOS gab. Ab da konnten jeder Programmierer und jeder Protokoll-Designer daran arbeiten. MP war erst eine ganze Weile später, ab dem 68030.

[goetz @ 3rz]

Das Speicher-Problem trat in´s Bewußtsein, als es MultiTOS gab. Ab da konnten jeder Programmierer und jeder Protokoll-Designer daran arbeiten. MP war erst eine ganze Weile später, ab dem 68030.

Als MultiTOS rauskam, gab es den TT schon eine Weile. 'MP' mußte also nicht auf das Erscheinen eines 68030-Computer warten.

[ari.tao]

Da hast Du wohl recht. Kam mir nur so vor, weil ich damals bloß den MST4 hatte (übernommen von Viszena). M-TOS trägt ein Datum vom März ´93, mein erster F30 kam ´97 und mein erster TT erst ´09. Aber die Speicher-Problematik war auch mit meinem MST4 für mich schon ein Thema (wg. TDI, so.).

[KarlMüller]

Mal was technisches aus Thing, wie zumindest ein Programm selbst verhindern kann nicht in den Abgrund gezogen zu werden.

Code: [Auswählen]

/**
 * avp_checkbuf
 *
 * Prueft, ob ein von einem AV-Client gelieferter Pufferzeiger fuer
 * Thing les- und ggf. schreibbar ist (Stichwort Speicherschutz).
 *
 * Eingabe:
 * id: AES-ID des AV-Clients
 * msg: Betroffene AV-Nachricht als Zahl
 * tmsg: Betroffene AV-Nachricht als Text
 * buf: Zeiger auf zu pruefenden Puffer
 * write: 1, wenn auch Schreibzugriff benötigt wird
 *
 * Rueckgabe:
 * 0: Puffer nicht OK, Alert wurde angezeigt
 * sonst: Alles klar, go ahead
 */
short avp_checkbuf(short id, short msg, char *tmsg, char *buf, short write) {
short ok;
long old_sigbus;
char *name, d, *origbuf;
AVINFO *ainfo;

old_sigbus = (long) Psignal(SIGBUS, (long) handle_sigbus);
/* Wenn es Psignal nicht gibt, kann man nix machen ... */
if (old_sigbus == -32L)
return (1);
origbuf = buf;
ok = 1;
    /*
     * Ohne setjmp()/longjmp() geht es nicht, weil bei Rückkehr
     * aus einem Signalhandler fÅr SIGBUS und SIGSEGV an genau
     * der Stelle weitergemacht wird, die den Fehler verursacht
     * hatte -> das Signal würde also gleich nochmal ausgelöst
     */
if (setjmp(check)) {
        /*
         * Wenn dieser Teil der Routine erreicht wird, wurde der
         * Signalhandler aktiviert und ist mit longjmp() hierher
         * zurückgekehrt, um den Fehler zu melden
         */
ok = 0;
ainfo = avp_get(id);
if (ainfo)
name = ainfo->name;
else
name = appl_name(id, "UNKNOWN");
sprintf(almsg, rs_frstr[ALPRIVATEMEM], name, id, write ? "global"
: "readable");
if (frm_alert(2, almsg, altitle, conf.wdial, 0L) == 1) {
sprintf(almsg, rs_frstr[ALPMDETAILS], tmsg, msg, buf, origbuf);
frm_alert(1, almsg, altitle, conf.wdial, 0L);
}
} else {
        /*
         * Dieser Teil wird direkt nach dem Aufruf von setjmp()
         * erreicht. Hier wird der Puffer geprüft, wobei die
         * Abfrage auf Ende des Puffers erst in der Schleife
         * stattfindet, um ggf. auch diese Speicherstelle
         * testweise zu beschreiben
         */
for (;; buf++) {
d = *buf;
if (write)
*buf = d;
if (!d)
break;
}
}
    /*
     * Den alten Signalhandler restaurieren und das Ergebnis des
     * Tests liefern
     */
Psignal(SIGBUS, (long) old_sigbus);
return (ok);
}

/**
 * handle_sigbus
 *
 * Handler fuer SIGBUS und SIGSEGV bei avp_checkbuf(). Springt per
 * longjmp() zurück und meldet dabei einen Fehler.
 *
 * Eingabe:
 * signo: Signalnummer (SIGBUS)
 */
static void cdecl handle_sigbus(long signo) {
UNUSED(signo);
Psigreturn();
longjmp(check, 1);
}

Die Routine befindet sich in AVSERVER.C

[ari.tao]

Interessant!
Gibt´s da noch mehr, ie. für andere Protokolle?

[Thorsten Otto]

Mal was technisches aus Thing, wie zumindest ein Programm selbst verhindern kann nicht in den Abgrund gezogen zu werden.

Das Problem dabei ist, daß man trotzdem den buserror-Alert vom AES zu Gesicht bekommt (zumindest dann wenn jemand die Alert-Pipe angelegt hat, was aber wohl meistens der Fall sein dürfte). Das macht die ganze Sache schlecht automatisierbar.

Gibt´s da noch mehr, ie. für andere Protokolle?

Die Routine ist recht allgemein gehalten, wo der Zeiger her kommt ist dort auch nicht festgelegt, von daher ist sie auch für andere Protokolle geeignet. Einzige Annahme ist, daß der Zeiger auf einen 0-byte terminierten String zeigt, was wohl für die meisten Messages der Fall sein dürfte. Bin mir gerade nicht ganz sicher ob es sowas gibt, aber wenn der Zeiger auf eine bestimmte Struktur fester Länge zeigt, bräuchte man eine zweite Routine.

[KarlMüller]

Einzige Annahme ist, daß der Zeiger auf einen 0-byte terminierten String zeigt, was wohl für die meisten Messages der Fall sein dürfte. Bin mir gerade nicht ganz sicher ob es sowas gibt, aber wenn der Zeiger auf eine bestimmte Struktur fester Länge zeigt, bräuchte man eine zweite Routine.

Da werden x Routinen benötigt. Zum Beispiel beim XAcc wird das Ende des Strings mit zwei 0-Bytes angezeigt, beim SE-Protokoll und DHST wird, wie Du schon vermutest, eine Struktur verschickt.

[Thorsten Otto]

beim XAcc wird das Ende des Strings mit zwei 0-Bytes angezeigt

Ah, richtig. Bei Gemscript glaube ich auch.

beim SE-Protokoll und DHST wird, wie Du schon vermutest, eine Struktur verschickt.

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.

[HelmutK]

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.

[mfro]

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.

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]

Bei Gemscript glaube ich auch.

Da wird auch eine Struktur verschickt.

beim SE-Protokoll und DHST wird, wie Du schon vermutest, eine Struktur verschickt.

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.

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]

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

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,

Supervisor-Stackspace im AES ist meist knapp.

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.