15 September 2021, 23:54 | #41 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,038
|
A bit shorter:
Code:
BootStart: ;a6=Execbase lea.l GoAway(pc),a5 ;<KS20 supervisor address ... ; lea.l GoHard(pc),a5 ;<KS20 supervisor address ; bra.s _ElbowTemperatureReboot ;** really allow Exec to do it? subq.l #GoAway-GoHard,a5 SoftReset: ; lea.l GoAway(pc),a5 ;<KS20 supervisor address ... CNOP 0,4 ;IMPORTANT! Longword align! GoHard: st 7.w *Exec made odd to force rebuild GoAway: lea.l MAGIC_ROMEND,a0 ;(end of ROM) ... BootCodeE: |
16 September 2021, 00:55 | #42 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,602
|
Appreciated as always a/b.
My thinking is: The mighty MagicResetCode does not rely on exec or a6. The call to Supervisor() relies only on a6. Supervisor itself might read address 4, now or in future. Which is unknown to me. This is why. And in general it's about if the thinking is correct and if an Exec that allows residents plus denies hard resets since 2.0 (this is the sticky combo) is to be relied upon. Or if I should just detect residents and print a message "tuRn off computeR with buttoN if feel unsafe". Simply, a way out of the sticky combo. Last edited by Photon; 16 September 2021 at 01:00. |
16 September 2021, 01:40 | #43 | |
Engineer
Join Date: Oct 2018
Location: Shadow realm
Posts: 165
|
Quote:
Also, why do you force the copy to be slow on 68010? Last edited by admiral; 16 September 2021 at 01:42. Reason: 68010 |
|
16 September 2021, 09:18 | #44 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,038
|
Copy speed is irrelevant here, tiny amount of data. Not using dbf saves 2 bytes, no need to decrement the count, and makes it simple.
Now in most cases you wouldn't have to (you could copy one more byte) because allocated memory is rounded up (to be a multiple of minimum alloc size, 8 at the moment) but if your code ends up fitting perfectly then you could trash something important. |
16 September 2021, 10:30 | #45 |
Engineer
Join Date: Oct 2018
Location: Shadow realm
Posts: 165
|
|
16 September 2021, 10:55 | #46 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,038
|
Yeah, I'm not sure either. Maybe there was some initial idea requiring the code to be in chip mem.
|
16 September 2021, 10:59 | #47 |
Engineer
Join Date: Oct 2018
Location: Shadow realm
Posts: 165
|
|
16 September 2021, 15:04 | #48 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,602
|
Bootblocks can be loaded into anymem on KS2+, so this is a standard operation for a bootblock that has chipset resources in it (e.g. copper lists).
The copy to chipmem is for a) to make the run-from-wherever environment the same as in the bootblock and b) eliminate CPU caching as a factor in execution. It will be there when I put the finished code into my bootblock, which displays a copper list, but you can ignore it. Apart from ideas about improved virus detection, I'm looking for feedback on the Hard/Softreset part only. Things like:
|
16 September 2021, 15:31 | #49 | |
Engineer
Join Date: Oct 2018
Location: Shadow realm
Posts: 165
|
Quote:
Re: Supervisor alternative, there's the vector table you can mess with (particularly always the case if no MMU present, but note 010+ has the VBR), to then create a suitable exception. |
|
16 September 2021, 15:41 | #50 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,038
|
VBR is always 0 when you boot, and remains 0 until you fire up SetPatch or anything similar. Has that changed in 3.2?
|
16 September 2021, 16:03 | #51 | |
Engineer
Join Date: Oct 2018
Location: Shadow realm
Posts: 165
|
Quote:
There's the argument of performance (if moved to fast). IDK if any amigaos is doing this. It is also a way to keep a debugger working regardless of changes to the copy at 0. |
|
16 September 2021, 16:47 | #52 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
This is some code I used. It was a 'mutual inspiration' between me and Keirf.
I don't remember if it's a latest version. It require Supervisor() but I do not see the point for a malicious program to patch it.. Move the supervisor executed code to chipmem (and not in lower memory that MMU can move); this to avoid that MMU reset destroy your own code. Now all special registers (VBR, MMU, (I)TT(x)) are no more a problem. Code:
lea (_super_disable,pc),a5 jsr _LVOSupervisor(a6) ... _trap_disable: and.w d2,(sp) ; clear CCR.Z addq.l #4,2(sp) ; skip faulting instruction rte _super_disable: subq.l #8,a5 ; lea (_trap_disable,pc),a5 move.l a5,($10).w moveq #0,d0 moveq #0,d1 moveq #~4,d2 .010 ; VBR=0 dc.l $4e7b0801 ; movec d0,VBR dc.l $4e7a1002 ; movec CACR,d1 tst.l d1 ; Bit 31 set? (68040+ Data Cache Enabled) bpl.b .020 ; Skip CPUSHA if not (020/030 boards fail) dc.w $f478 ; CPUSHA DC ; 68040+ only .020 ; Disable caches moveq #$10,d1 ; IBE only on 030 tst.l d0 ; set CCR.Z dc.l $4e7b1002 ; movec d1,CACR bne.b .done ; if CCR.Z bail on 000/010 ;tst.l d0 ; CCR.Z already set if I get here dc.l $4e7a1004 ; movec ITT0,d1 ; 68040+ only beq.b .060 ; CCR.Z=1 if 040/060 ; Detect 020 vs 030: check IBE dc.l $4e7a1002 ; movec CACR,d1 tst.l d1 ; d1=$10 if running on 68030 beq.b .done ; bail on 68020 .030 ; Disable 030 MMU clr.l (a5) dc.l $f0154000 ; pmove.l (a5),TC dc.l $f0150800 ; pmove.l (a5),TT0 dc.l $f0150c00 ; pmove.l (a5),TT1 bra.b .done .060 ; Disable superscalar dispatch dc.l $4e7b0808 ; movec d0,PCR ; 68060 only .040 ; Disable 040/060 MMU move.l #$0000c040,d1 dc.l $4e7b1006 ; movec d1,DTT0 move.l #$00ffc000,d1 dc.l $4e7b1004 ; movec d1,ITT0 dc.l $4e7b1005 ; movec d1,ITT1 dc.l $4e7b1007 ; movec d1,DTT1 dc.l $4e7b0003 ; movec d0,TC dc.l $4e7b0806 ; movec d0,URP dc.l $4e7b0807 ; movec d0,SRP .done rte |
16 September 2021, 17:02 | #53 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,038
|
This is a good point that should be considered, I agree. However, that would break a bunch of games and demos, and the virus would 'unstealth' itself. Even though booting a game/demo disk probably means the virus is going byebye, you still can't see something is not right and don't assume anything.
Maybe checking if VBR is 0 could be used as anti-virus, if there's enough place on bootblock (which was my intention, to cut down on VBR stuff to make sure there is, without realizing that it could've been moved for malicious purposes). |
16 September 2021, 19:24 | #54 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,602
|
Can't read VBR OS-friendly without Supervisor() to set vector manually and trap to supervisor without it. This means there's still a call to Supervisor(). So if it's patched this dependency isn't removed.
Could ColdReboot() be removed and how? |
16 September 2021, 20:28 | #55 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
If the MMU stuff is to much, simply remove it. The only dependency is Supervisor()/SuperState(), but I fail to understand how could be useful to malicious code. When you just got into supervisor mode if you run move #$2700,SRI don't think anyone can interfere (else a big crash) |
|
17 September 2021, 01:54 | #56 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,602
|
A move to SR will trap to Supervisor, but it's setting my own vector that's the problem. I could separate out 68000, but e.g. ACA500Plus has VBRMOVE. It should be transparent. And this allows removing the Supervisor() call. I'll try it.
I agree though that ColdReboot() is much more likely to be patched. I could check if it's in ROM, but then there's MapROM... Currently, Early Boot Menu counts as Resident. And I suppose it is. Is there a way to identify it and ignore it for the virus warning? And finally, is it safe to use st 7.w and then use ColdReboot() on all Amiga hardware configurations up to and including 3.2? Because there's no simple way to hard reset in ROM, it has taken me on a strange journey and that's why all these strange questions. I hope I'm not tiring you and I'm glad for the answers. |
17 September 2021, 04:51 | #57 |
Engineer
Join Date: Oct 2018
Location: Shadow realm
Posts: 165
|
It's not that bad.
Say, you could disable interrupts (via INTENA), point exception for zero division to your code (saving current handler address), divide by zero (and get into mighty interrupt mode), restore, reenable interrupts. Nobody is going to cause the exception (and run your handler) in the duration of this, due to the temporarily inhibited interrupts. Last edited by admiral; 17 September 2021 at 04:52. Reason: broken quote |
17 September 2021, 04:54 | #58 | |
Engineer
Join Date: Oct 2018
Location: Shadow realm
Posts: 165
|
Quote:
This would break some very, very tight software on plain 68010 running at the standard A500 7MHz clock... but nothing else. |
|
17 September 2021, 07:25 | #59 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,214
|
|
17 September 2021, 08:29 | #60 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
The one I think is absolutely the least sensitive to a patch is Supervisor() (still someone has to explain to me why a malicious software should patch it without having huge side effects). Once in supervisor mode you take control of the machine and degrade it completely: this means that you can do whatever you want and when you have destroyed exec base (with st $7or whatever) there is no 'middleman' that can come into action. Otherwise the MMU can always avoid your tampering attempts, ColdReboot() can be patched, the exec vectors used and so on. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Amiga 1200 problem with soft reset (and hard reset) | joora | support.Hardware | 6 | 21 July 2020 10:53 |
Crack tells me to "hard reset" to clear Ram | apachacha | support.WinUAE | 6 | 28 December 2011 11:30 |
is this correct? | CU_AMiGA | MarketPlace | 1 | 28 September 2007 20:05 |
Hard and soft reset | Photon | request.UAE Wishlist | 3 | 28 November 2006 16:08 |
Hard reset | BippyM | support.WinUAE | 3 | 22 February 2006 01:47 |
|
|