LisaList2
General Category => LisaList2 => Topic started by: rayarachelian on August 30, 2020, 10:24:57 pm
-
So, trap #7 is a universal trampoline and can be used to switch supervisor on in the processor, so it can be used for privilege escalation in LOS.I think I mentioned running across this before, but had forgotten exactly which trap it was:
Load D0 with what you want the SR to be, and you can turn on the S bit in it if you so choose.Load A0 with the target address you want to jump to.
But one thing to keep in mind, as soon as you turn on SR, the MMU will switch to context 0, so you have to do a bit more work to get back to whatever context your application was in after the escalation. You probably could write some code to some memory that's shared across all 4 contexts if you know what address that would be at, and use that. Possibly ALTSCREEN could make a good victim for such purposes since it's writable.
This wouldn't be useful for LisaEm work, but could be useful if you want to do weird stuff inside LOS like mess with running apps, etc.
1/0022102a (0 0/0/0) : 301f : 0. : 451 : MOVE.W (A7)+,D0 SRC:clk:0000000071466a6c +8 clks
1/0022102c (0 0/0/0) : 2049 : .I : 416 : MOVE.L A1,A0 SRC:clk:0000000071466a74 +4 clks
1/0022102e (0 0/0/0) : 4e47 : NG : 740 : TRAP #7 SRC:clk:0000000071466a78 +4 clks
reg68k.c:reg68k_internal_vector:1963:Entering: internal_vector - VECTOR:39 (0x27 (39) trap #7 (D0=2700->SR, JMP (A0=00220fc0) ), addr_err:00000000 oldpc:00221030, pc24:0022102e, reg68k_pc:0022102e| 17:10: 37.4 1900440184
1/00220700 (0 0/0/0) : 5c4f : .O : 808 : ADDA.W #6,A7 SRC:clk:0000000071466ad3 +8 clks
1/00220702 (0 0/0/0) : 46c0 : F. : 650 : MOVETSR.W D0 SRC:clk:0000000071466adb +12 clks
1/00220704 (0 0/0/0) : 4ed0 : N. : 759 : JMP.L (A0) SRC:clk:0000000071466ae7 +8 clks
-
It sounds like you need some kind of... trapper keeper
Seems like the trap doesn't touch any of the registers---could you save enough information in D1-D7/A1-A7 so that the routine at (A0) can figure out what it needs to know to restore the old context?
ISTR that the folks at CMU who made that Apple Lisa demo talked about using some kinds of privilege escalation---but they never detailed what they did.
-
Forgive this off-topic post - while I know exactly what you mean by privilege escalation/supervisor mode, I can't help but think of this.
-
It sounds like you need some kind of... trapper keeper
Well played sir, I see what you did there (https://youtu.be/SgO_GiBxkFA?t=13) :)
Seems like the trap doesn't touch any of the registers---could you save enough information in D1-D7/A1-A7 so that the routine at (A0) can figure out what it needs to know to restore the old context?
ISTR that the folks at CMU who made that Apple Lisa demo talked about using some kinds of privilege escalation---but they never detailed what they did.
Yeah, so this call is used pretty often within Lisa Office System. I'm not sure why they needed this mechanism at all, since as soon as you invoke a trap, you're inside supervisor mode and context 0 automatically, they could have then dropped privileges using a write to the SR on the way back or through RTE. So it's yet another kludge that's also a security hole.
So the MMU will switch to whatever context segment1 and segment2 latches are set to when the 68000 Supervisor flag is zero, and will always go to context 0 when the supervisor flag is 1. So you can actually use a 2nd call to this trap from supervisor land to return back to where you were. So you don't have to worry about the MMU context switch back to your code, you only need to somehow pass a return address to your target code. You can get this via LEA pointing to where you want it to return to, and pass it through one of the A registers.
Or you can do the record thing where you fill out a struct (record in pascal speak) with whatever params you want, including the return address, save this in common space (memory shared by all 4 MMU contexts) and set a pointer to this record via one of the A regs, such as A3, set A0 and D0 to your target address and SR, and trap.
The only weird MMU context is the SIO space, for which there are MMU functions/procedures in the OS itself, so no need to do that manually.
To find common space, you can compile in a call the MMU dump routine from LisaEm and examine the output file, I remember seeing that there are large swaths of space shared in all 4 contexts. These are always going to be in the same address spaces.
Rant about efficiency:
In LOS there's many ABIs doing things such as the Aline traps and TRAP #5 mechanisms. i.e. pascal libs that call a trap than then resolve to a JMP table offset by D7 (or by the 2nd word following the A-Line opcode) and each layer makes heavy use of the stack making each call very slow.] Some of this is likely so kludgy possibly because it was written by different people at different times, backwards compatibility with LOS1 and LOS2, introduction of QuickDraw, and perhaps back and forth with the Mac guys and possibly needing some compatibility with that.
I'd chalk a lot of this up to meeting deadlines and making stuff work rather than making it efficient, and clean.
It also seems at a cursive glance that the OS system calls aren't fully documented, but rather their equivalent pascal library modules are, so what's in the Operating System manual PDF isn't the true OS. Keeping those internal JMP tables for both the TRAP #5 and A-line mechanisms somewhat makes sense if you want to keep a stable ABI between releases, but then all the layers around them make it very inefficient. Some of this is possibly due to the pascal compiler not optimizing to use registers rather than the stack when making procedure/function calls, etc. but that's neither here nor there.
As I reread the OS manual for LOS, I'm convinced these guys were familiar with Unix and implemented something similar. The odd thing is the use of - instead of / as a file system separator, and the device names hanging off the file system is a lot like Windows NT, so possibly there was some VMS influence there too? (i.e. see EXEC call, named pipes, directory reading calls, etc.)
-
Forgive this off-topic post - while I know exactly what you mean by privilege escalation/supervisor mode, I can't help but think of this.
Ah yes, the infamous Catalina/Vista edition of LOS
-
Ah yes, the infamous Catalina/Vista edition of LOS
Hey at least in Windows, UAC lets you run the program anyway without having to go to the Control Panel and manually adding the program to an allowed list :D
As I reread the OS manual for LOS, I'm convinced these guys were familiar with Unix and implemented something similar. The odd thing is the use of - instead of / as a file system separator, and the device names hanging off the file system is a lot like Windows NT, so possibly there was some VMS influence there too? (i.e. see EXEC call, named pipes, directory reading calls, etc.)
I seem to remember the Lisa team being mostly a bunch of mainframe and minicomputer guys so to me it makes sense that they'd be pulling in mainframe and minicomputer ideas into the hardware and software. The Lisa's MMU is discreet logic because the 68000 had no concept of memory protection, no? And yeah, I've read all the underlying OS documents and it just screams that the software team was trying to be so forward-thinking - but that, and probably trying to pull in mainframe and minicomputer features into a micro probably was part of why the darned thing ran so slow in my opinion.