Usando resload_Protect#?
Teoría
Hay varias situaciones en las cuales puede ser útil ser informado cuando el programa
instalado realiza accesos a ciertas ubicaciones especificas en memoria.
Con las funciones resload_Protect#? es posible proteger
ciertas ubicaciones de memoria contra ser leídas y/o escritas por el procesador.
Esta protección implica que cada acceso a una de estas áreas protegidas, de realizarse,
generará una excepción de Falla de Acceso que resultará en un cuadro de diálogo apropiado
por parte de WHDLoad. Si Ud. declara como protegida un área de memoria usando una
función resload_Protect#? WHDLoad modificará los descriptores
de la página afectada en el árbol de traducción de la MMU. Luego, en cada acceso a la
página protegida, la CPU creara una excepción de Falla de Acceso. El gestor de excepciones
dentro de WHDLoad verificara la razón de la excepción. Si la razón ha sido un acceso
a una página protegida pero el acceso no corresponde al área protegida
los accesos serán emulados, y la ejecución normal del programa continuara. De otra forma
WHDLoad saldrá de la ejecución con el cuadro de dialogo apropiado. Si el acceso fue
realizado dentro del flujo de instrucciones (es decir, la CPU ha intentado leer código)
siempre será emulado, o en otras palabras, las funciones resload_Protect#?
solo afectan a la lectura y escritura de datos. El hecho de que cada acceso a una página
protegida (el tamaño de página es actualmente $1000) generara una falla de acceso,
aun si el área protegida tiene una longitud de tan solo 1 byte, resultara en un gran
enlentecimiento de la velocidad de ejecución del programa. Especialmente si partes
del código están ubicadas en la misma página. Si el programa es critico en cuanto
a velocidad de ejecución, existen diferencias en cuanto a la ejecución del mismo.
Por lo tanto es posible que algunos programas no funcionen con la funcionalidad
de protección.
Ejemplo: sumas de control sobre el código
Si Ud. instala un juego usando WHDLoad Ud. deberá parchar las rutinas de carga en el cargador original
del juego de tal forma que usen WHDLoad para cargar los datos del juego. Algunos juegos realizan
sumas de control sobre ciertas áreas de código para detectar si el código original ha sido modificado.
Estas rutinas de detección pueden ser en ocasiones bastante difíciles de encontrar. Pero usando
la funcionalidad resload_Protect#? en WHDLoad nada puede ser mas sencillo
que esto. Todo lo que Ud. tiene que hacer es proteger los bytes que Ud. ha cambiado en el código
del juego contra lectura. Ahora cada rutina que intenta realizar una suma de control y leer el código
parchado causara una falla de acceso. Y Ud. conocerá donde esta ubicada la rutina.
Limitaciones
Ud. no debe proteger la página de memoria donde apunta el SSP. Si lo hace, y ocurre una Excepción,
resultara en una Falla de Doble Bus dado que la CPU no será capaz de escribir el entorno de pila
de la excepción. Luego de una Falla de Doble Bus solamente puede hacerse un reset para continuar
con la ejecución. WHDLoad verificará si hay un conflicto del área protegida mediante el SSP y terminará
en caso afirmativo, pero esto no será de ayuda si el SSP cambia posteriormente.
- 68020 + 68851
- este hardware no esta soportado actualmente
- 68030
- las transferencias de 3 bytes no están soportadas y crearan una Falla de Acceso real,
tales transferencias ocurrirán si una palabra larga en una dirección impar en la frontera
de una página es accedida (por ej. "
tst.l ($fff)
" donde la página en $1000 este protegida),
dado que esto es invalido en un 68000 probablemente Ud. nunca vea algo como esto
- transferencias bloqueadas causadas por
tas
, cas
o cas2
no
están soportadas y causaran una Falla de Acceso real, no es un problema dado que las transferencias
bloqueadas no están soportadas por el hardware en Amigas
- 68040
- este hardware actualmente no esta soportado
- 68060
- accesos a flujos de datos no alineados no están soportados y causaran una Falla
de Acceso real, un acceso no alineado es un acceso que abarca dos paginas (y al menos
una de ellas esta protegida), por ejemplo "
tst.l ($ffe)
" afecta a la página
$0..$fff y la página $1000..$1fff, esta limitación es realmente un problema y causara que
la funcionalidad de resload_Protect sea prácticamente inutilizable en ocasiones, tal vez
mas adelante intentare soportar esto pero es difícil
- accesos a flujos de instrucciones no alineados no están soportados y causaran una Falla
de Acceso real si ambas paginas afectadas están protegidas, la mayor parte de las veces
tal situación puede ser evitada
- transferencias bloqueadas causadas por
tas
, cas
o cas2
no
están soportadas y causaran una Falla de Acceso real, no es un problema dado que las transferencias
bloqueadas no están soportadas por el hardware en Amigas
- instrucciones que estén en una página protegida (y por lo tanto son emuladas) y
acceden a la porción de supervisor del registro de estado serán ejecutadas incorrectamente,
estas instrucciones siempre verán el bit de seguimiento (trace) con valor 1 y la mascara
de prioridad de interrupciones con valor 7, cualquier modificación a la porción de supervisor
no tendrá efecto (es decir que la porción de supervisor permanecerá sin cambios)
- las instrucciones
movem
pueden acceder un área protegida sin crear una
excepción de Falla de Acceso, esto es posible debido a que solamente el primer acceso
(palabra o palabra larga) será verificado contra el área protegida
move16
y las operaciones de doble precisión (FPU) no están soportadas y causaran
una Falla de Acceso real
- un "
move (mem),(mem)
" con direcciones origen y destino solapadas debido a
no estar alineado será ejecutado incorrectamente, por ejemplo "move.l ($ffc),($ffe)
"
donde la página $1000..$1fff esta protegida y la memoria antes de la ejecución contiene
($ffc)=$11112222, ($1000)=$33334444, luego de la ejecución $1000 contendrá $11114444 y no $22224444