Brug af resload_Protect#?
Teori
Der er forskellige situationer i hvilke det kan være meget nyttigt
at få at vide hvornår det installerede program tilgår specifikke
hukommelses områder. med
resload_Protect#? funktionen er det muligt at beskytte visse
hukommelses områder fra processoren at læse og/eller skrive. At
beskytte betyder at ethvert forsøg på at tilgå et beskyttet område
vil generere en Access Fault exception som vil resultere i en
passende requester af WHDLoad. Hvis du deklærer et hukommelses
område som beskyttet v.h.a.
resload_Protect#? funktionen vil WHDLoad modificere de berørte
page descriptors i MMU'ens oversættelses træ. Nu vil CPU'en generere
en Access Fault exception hver gang et beskyttet område tilgås.
Exception handleren indeni WHDLoad vil verificere grunden til
exceptionen. Hvis grunden var et forsøg på at tilgå en beskyttet page men tilgangen ikke matcher det beskyttede
område vil tilgangen blive emuleret og den normale program
eksekvering vil fortsætte. Ellers vil WHDLoad afslutte med en passende
requester. Hvis adgangen var en adgng til instruktions strømmen (f.eks.
CPU'en forsøger at loade kode) vil den altid blive emuleret, eller med
andre ord resload_Protect#?
funktionen berører kun læsning og skrivning af data. Det faktum at enhver
adgang til en beskyttet side (sidestørrelsen er i øjeblikket $1000) vil
generere en access fault, selv hvis det beskyttede område kun har en
længde på 1 byte, resulterer i et drastisk fald i programmets eksekverings
hastighed. Specielt hvis dele af koden ligger på amme side. Hvis programmet
afhænger af eksekveringshastighed er der mulighed for afvigelser i
eksekveringen. Så det er muligt at nogle programmer ikke vil virke med
beskyttelses featuren.
Eksempel: checksums over kode
Hvis du installerer et program ved brug af WHDLoad er du nødt til at patche
de originale loader rutiner på en måde så de bruger WHDLoad til at loade spil
data. Nogle spil overvåger nogle kode områder med checksum for at kontrollere
at koden ikke er modificeret. Disse overvågnings rutiner kan være svære at
finde men ved hjælp af resload_Protect#?
functioner i WHDLoad er der ikke noget der er nemmere end dette. Alt
hvad du skal gøre er at beskytte de bytes du har ændret i koden fra at blive
læst. Nu vil hver rutine der prøver at lave en checksum kontrol og læse din
patchede kode generere en adgangs fejl. Og du vil vide hvor rutinerne ligger.
Begrænsninger
Du må ikke beskytte den hukommelses side hvor SSP'en peger hen. Hvis du gør
dette vil det resultere i en Double Bus Fault fordi CPU'en ikke vil være istand
til at skrive exception stackframen. Efter en Double Bus Fault er det kun muligt
at lave en reset for at fortsætte eksekveringen. WHDLoad vil kontrollere om der
er en konflikt af det beskyttede område og SSP'en og afslutte hvis der er. Men
dette vil ikke hjælpe hvis SSP'en ændrer sig senere hen.
- 68020 + 68851
- Denne hardware understøttes ikke i øjeblikket
- 68030
- 3-Byte transfers er ikke understøttet og vil generere en real Access Fault,
sådanne transfers vil opstå hvis et longword på en ulige addresse på en sides
udkant bliver tilgået (f.eks. "
tst.l ($fff)
" hvor siden på $1000
er beskyttet), fordi dette ikke er validt på en 68000 vil du højst sandsynligt
ikke se noget som dette.
- Låste transfers forudsaget af
tas
, cas
eller
cas2
er ikke supporteret og vil generere en real Access Fault.
Dette er ikke et problem fordi låste transfers ikke er supporteret på Amiga
hardware
- 68040
- denne hardware er ikke supporteret i øjeblikket
- 68060
- ulige data stream adgang er ikke supporteret og vil generere en real
Access Fault, en ulige adgange er en adgang der spænder over 2 sider (og
mindst én af dem er beskyttet). F.eks. "
tst.l ($ffe)
" berører
siden $0..$fff og siden $1000..$1fff, denne begrænsning er et stort problem
og kan nogle gange gøre resload_Protect featuren ubrugelig. Måske vil jeg
prøve at supportere dette senere hen men det er meget vanskeligt.
- ulige instruction stream adgange er ikke supporteret og vil generere en
real Access Fault hvis begge sider er beskyttet. En sådan konstallation
skulle være til at undgå
- låste transfers der forudsages af
tas
eller cas
er ikke supporteret og vil generere en real Access Fault. Dette er ikke et
problem fordi låste transfers alligevel ikke er understøttet af amiga hardware
- instruktioner der ligger på en beskyttet side (og derfor vil blive emuleret)
og som tilgår overvågnings delen af status registret vil blive eksekveret ukorrekt.
Disse instruktioner vil altid se trace bit'en som 1 og interrupt priority mask som
7. Enhver modifikation af overvågnings delen vil være uden effekt (overvågnings
delen vil bevares uændret)
movem
instruktion kan få adgang til et beskyttet område uden at
genererere en Access Fault exception. Dette er muligt fordi kun den første adgang
(word eller longword) vil blive verificeret om det matcher det beskyttede område
move16
og dobbel præcisions operationer (FPU) er ikke understøttet
og vil generere en real Access Fault
- en "
move (mem),(mem)
" med overlappende kilde og base addresse som
genererer en Access Fault fordi det ikke vil blive eksekveret ordentligt. For eksempel
"move.l ($ffc),($ffe)
" hvor side $1000..$1fff er beskyttet og hukommelse
før eksekvering indeholder ($ffc)=$11112222, ($1000)=$33334444, efter eksekvering
indeholder $1000, $11114444 og ikke $22224444