Correct way to hard reset in the bootblock on 1.3-3.1?

[a/b]

A bit shorter:

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:

[Photon]

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.

[admiral]

Originally Posted by Photon

    *--- copy ---*

	move.l a1,a2
	lea BootStart(PC),a0
.copyl:	move.b (a0)+,(a1)+
	subq.l #1,d7
	bne.s .copyl
	jmp (a2)			;jump into chipmem

What's the purpose of this copy?

Also, why do you force the copy to be slow on 68010?

[a/b]

Originally Posted by admiral

... Also, why do you force the copy to be slow on 68010?

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.

[admiral]

Originally Posted by a/b

Copy speed is irrelevant here

To be clear, that was a playful way to ask "why do you not use dbf?". Speed is of course irrelevant.

The important part was to know why is this copy being done in the first place.

(I still don't)

[a/b]

Yeah, I'm not sure either. Maybe there was some initial idea requiring the code to be in chip mem.

[admiral]

Originally Posted by a/b

Yeah, I'm not sure either. Maybe there was some initial idea requiring the code to be in chip mem.

That was the first idea, but then I remembered this is meant to be a bootblock.

Does any AmigaOS version ever load the bootblock anywhere else than CHIP?

[Photon]

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:

1. Is my clearing of the vectors etc correct and complete to kill a resident virus, assuming Exec is not patched? Should I clear KickTagPtr also?
2. Can I detect if Supervisor() or ColdReboot() have been patched by a virus?
3. Can I use something else instead of Supervisor() or ColdReboot() that doesn't use Exec?

[admiral]

Originally Posted by Photon

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:

1. Is my clearing of the vectors etc correct and complete to kill a resident virus, assuming Exec is not patched? Should I clear KickTagPtr also?
2. Can I detect if Supervisor() or ColdReboot() have been patched by a virus?
3. Can I use something else instead of Supervisor() or ColdReboot() that doesn't use Exec?

Good to know re: anymem on v36+.

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.

[a/b]

VBR is always 0 when you boot, and remains 0 until you fire up SetPatch or anything similar. Has that changed in 3.2?

[admiral]

Originally Posted by a/b

VBR is always 0 when you boot, and remains 0 until you fire up SetPatch or anything similar. Has that changed in 3.2?

A virus could have moved it elsewhere.

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.

[ross]

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.

	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

[a/b]

Originally Posted by admiral

A virus could have moved it elsewhere....

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).

[Photon]

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?

[ross]

Originally Posted by Photon

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?

If you 'degrade' the system with my code, also my manual reset code could be freely used.
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,SR

I don't think anyone can interfere (else a big crash)

[Photon]

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.

[admiral]

Originally Posted by Photon

it's setting my own vector that's the problem.

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.

[admiral]

Originally Posted by a/b

However, that would break a bunch of games and demos, and the virus would 'unstealth' itself.

New vectors can be set to be "followers" that just do an indirect call to the matching vectors at 0. Thus delaying everything vectored just a few cycles.

This would break some very, very tight software on plain 68010 running at the standard A500 7MHz clock... but nothing else.

[Thomas Richter]

Originally Posted by Photon

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?

No. Run MuForce, and you'll get a hit, but AbsExecBase will remain unchainged.

[ross]

Originally Posted by Photon

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.

You have to choose what to trust.
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 $7

or 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.