Print

[Daniel]

I will try it out soon. I am currently in a CHRP debugging spree.

[Daniel]

My CHRP debuging spree is over. I just tested out the new version. It appears to work, but it seems to be hard to capture that debugging output. Maybe if it saved it to a file? I have attached one picture of the screen. My camera can't clearly capture all of the text at once. Also, NKDebug does not work on it anymore. It gives error code -4, which you said means that it is not implemented.

[ELN]

Well wow. I'm almost surprised that that worked!

The only modifications to the kernel in that last version were to force a bit to be set in KDP.NanoKernelInfo.ConfigFlags, for the NewWorld and OldWorld code paths. This causes the kernel log to be redrawn on the framebuffer whenever it is updated. I did not enable my NKDebugShim code, because it is actually quite hacky and incompatible with the kernel screen log (for now). I'll post some code to explain.

[ELN]

So here's the code. DeclareMPCall is a macro to put a pointer to NKDebug in the "MPCall" (syscall) table at position 200. By default only about 130 positions in that table are used. I will soon write an app to extract the entire kernel output from an unmodified kernel.

Code: [Select]

;_______________________________________________________________________
; My additions to the NanoKernel, to go at the end of the code image
;_______________________________________________________________________

if NKDebugShim && !Vanilla

DeclareMPCall 200, NKDebug

NKDebug

; Lifted from NKxprintf:
; Put the physical address of the r3 arg in r8

rlwinm. r9, r11, 0, DRbit, DRbit ; IntSyscall sets this
mr r8, r3

beq- @already_physical
li r9, 0
bl V2P ; takes page EA in r8, r9=0, returns page PA in r17
beq- @fail
rlwimi r8, r17,  0,  0, 19
@already_physical


; Copy the command into the KDP buffer reserved for this purpose:
; r8 = src
; r29 = dest
; r30 = ctr
; r31 = val

mfsprg r1, 0
lwz r1, EWA.PA_KDP(r1)

li r30, 0
addi r29, r1, -0x960
@cmdloop
lbzx r31, r8, r30
stbx r31, r29, r30
addi r30, r30, 1
cmpwi r31, 0
bne @cmdloop

lwz r31, -0x404(r1)

stw r8, -0x404(r1)

bl panic

lwz r8, -0x404(r1)
li r0, 0
stw r0, 0(r8)

stw r31, -0x404(r1)

b ReturnZeroFromMPCall


@fail
b ReturnMPCallOOM

endif


[Daniel]

It looks very interesting. I am not familiar with PowerPC assembly but I can sort of guess what the mnemonics mean. How much control do you have over the debugger? Can you add new commands? It would be very useful if you could dump the page tables or something like that.

[ELN]

We can do whatever we like with the debugger. Some modifications were required to get it to accept commands in a buffer instead of via serial, and to return after executing one command. That code is attached for your perusal.

The debugger's main use is in examining the kernel's opaque internal structures. These are only exposed to userspace by their opaque ID. Structure types include: address spaces, areas, processors, memory coherence groups, queues, semaphores, critical regions, event groups, timers, notifications. While you can examine the hash table directly, address space and area structures give you a better high-level overview (although I am a bit slow on the reversing here -- help wanted).

[Daniel]

Unfortunately I probably won't be able to help much with reverse engineering the kernal. I can still offer suggestions. My first suggestion is that the 'dm' and 'dml' commands should not be able to crash the system. Maybe you can temporarily alter the relevant exception vectors while they run so any address errors or protection faults will be caught by the debugger. Another suggestion is to make it so you can use the debugger to load a program file and run it in supervisor mode. That would be very useful for experimenting.

[ELN]

Good thoughts!

Catching DSI exceptions would be a pretty large change to the debugger, and I'm a bit shy about the time it would take. But I'll keep thinking about it.

As for running arbitrary code in supervisor mode -- interesting. A lot of what I know about the kernel comes from old newsgroup discussions on how to do just that, usually in order to access special processor registers. In fact there is already a method for it, which NKv2 uses to replace NKv1 with itself on OldWorld Macs. It is invoked from the 68k emulator by issuing a RESET instruction (resets peripherals, not the processor) with Gary Davidian's name and (I think) his birth date in registers. The RESET instruction (again, I think) causes the emulator to execute a trap instruction with trap number 2. The NanoKernel takes a program interrupt, interprets the trap number, and executes the kcResetSystem handler, which checks for the special values. I am pretty sure that the handler then returns control to the calling task with the emulator turned off and PowerPC registers set according to passed-in values, but I haven't looked too closely.

You can see all this playing out if you fire up PowerMacInfo and check the processor temperature while the kernel log is being displayed. It's pretty cool.

I'll see what I can do to exploit it.

(By the way, supervisor mode can also be achieved through some pretty unsavoury patches to the kernel's internal structures. This is sleazy, and the only code that I could find would definitely have broken for NKv2.28.

[Daniel]

Another suggestion is to find a way to edit MacsBug so that it locates the kernal data for you and gives you their addresses. So you can just hit cmd-power and start messing around with things without having to find everything.

[ovalking]

I just got 'KCKernelDebuggerCommand error: -4' for each command when I tried on a beige G3 266 OS9.2.2 192MB RAM.

[Daniel]

That is to be expected. Beige G3s are Old World systems and ignore the Mac OS ROM file. Seeing as the Mac OS ROM file is what enabled NKDebug, it makes sense that it wouldn't work. It might be possible to stick the correct 'krnl' resource in the system suitcase to enable NKDebug on Old World machines, but I have no idea if that would work. ELN probably knows (or can find out easily).