* [pups] Issues of AUUGN @ 2006-10-04 7:00 Dave Horsfall 2006-10-04 8:22 ` Johnny Billquist 0 siblings, 1 reply; 5+ messages in thread From: Dave Horsfall @ 2006-10-04 7:00 UTC (permalink / raw) [ Meant to go to list, but sent to DMR only by mistake. ] On Wed, 4 Oct 2006 dmr at plan9.bell-labs.com wrote: > > It contains the famous Thrust Meter, a few papers by Yours Truly, and > > I think it has the short assembly program that would bring a PDP-11/70 > > to its knees (the infamous "SPL" firmware bug). > > Was this the feature (not really a bug; it's in the manual) that SPL > suppressed interrupts for one instruction after the SPL? I suppose it > was indeed a bug that this happened even in user mode where SPL was > intended to be a no-op. Yep, that's the one. I regard it as a bug because it indeed happened in user mode... > I remember trying this. It depends on completely filling memory with > SPLs, which I could not figure out how to do using an instruction > sequence. However, putting a bunch of SPLs into a file and reading it > in over the program did the job. There was a clever assembly program that did it; it relied upon the instruction counter wrapping around (I can't remember in which direction, or whether it first relocated itself). Anyone, it managed to fill memory with SPLs, so the next instruction after overwriting its last instruction was SPL, and for the foreseeable future after that... If I find the article I'll post it here; I don't think there are too many 11/70s still in public operation. > It was a bit hard to break out of--the halt switch didn't work. At first > I thought that power-off was the only solution, but it turned out that > holding down both reset and halt simultaneously did the job. I'll remember that, should I ever see an emulator :-) I still remember Ian Johnstone cursing me... -- Dave ^ permalink raw reply [flat|nested] 5+ messages in thread
* [pups] Issues of AUUGN 2006-10-04 7:00 [pups] Issues of AUUGN Dave Horsfall @ 2006-10-04 8:22 ` Johnny Billquist 2006-10-04 10:22 ` Dave Horsfall 0 siblings, 1 reply; 5+ messages in thread From: Johnny Billquist @ 2006-10-04 8:22 UTC (permalink / raw) Dave Horsfall wrote: > [ Meant to go to list, but sent to DMR only by mistake. ] > > On Wed, 4 Oct 2006 dmr at plan9.bell-labs.com wrote: > >>>It contains the famous Thrust Meter, a few papers by Yours Truly, and >>>I think it has the short assembly program that would bring a PDP-11/70 >>>to its knees (the infamous "SPL" firmware bug). >> >>Was this the feature (not really a bug; it's in the manual) that SPL >>suppressed interrupts for one instruction after the SPL? I suppose it >>was indeed a bug that this happened even in user mode where SPL was >>intended to be a no-op. > > Yep, that's the one. I regard it as a bug because it indeed happened in > user mode... > >>I remember trying this. It depends on completely filling memory with >>SPLs, which I could not figure out how to do using an instruction >>sequence. However, putting a bunch of SPLs into a file and reading it >>in over the program did the job. > > There was a clever assembly program that did it; it relied upon the > instruction counter wrapping around (I can't remember in which direction, > or whether it first relocated itself). Anyone, it managed to fill memory > with SPLs, so the next instruction after overwriting its last instruction > was SPL, and for the foreseeable future after that... It would have to wrap forwards. Basically, if you just have a MOV (PC)+,(R0)+ SPL #7 and make sure that the rest of the memory don't do anything overly foolish, and make sure that R0 starts pointing after this piece, it will eventually fill the whole memory. The final step will be the MOV which overwrites itself with an SPL, and then we're done. However, another way of achieving this, if you have some kind of control of the MMU is to just fill one page with SPLs, and then remap all of your memory to be that page. The last page you remap is just the page that holds all the code doing the setup. I'm not sure you can control that under Unix well enough, but in RSX this wouldn't be impossible, I think. > If I find the article I'll post it here; I don't think there are too many > 11/70s still in public operation. Well, ours is occasionally. It's off at the moment, since we're not allowed to consume that much money anymore, but Magica.Update.UU.SE is just a key turn away from being online. >>It was a bit hard to break out of--the halt switch didn't work. At first >>I thought that power-off was the only solution, but it turned out that >>holding down both reset and halt simultaneously did the job. > > I'll remember that, should I ever see an emulator :-) I still remember > Ian Johnstone cursing me... :-) Oh, that would be having the HALT switch down and pressing the START switch, by the way. That combination will trigger a Unibus reset, and will bring the CPU out of almost all catatonic states that I've seen, including serious bus problems. Johnny ^ permalink raw reply [flat|nested] 5+ messages in thread
* [pups] Issues of AUUGN 2006-10-04 8:22 ` Johnny Billquist @ 2006-10-04 10:22 ` Dave Horsfall 2006-10-04 11:11 ` Johnny Billquist 0 siblings, 1 reply; 5+ messages in thread From: Dave Horsfall @ 2006-10-04 10:22 UTC (permalink / raw) On Wed, 4 Oct 2006, Johnny Billquist wrote: > > There was a clever assembly program that did it; it relied upon the > > instruction counter wrapping around (I can't remember in which > > direction, or whether it first relocated itself). Anyone, it managed > > to fill memory with SPLs, so the next instruction after overwriting > > its last instruction was SPL, and for the foreseeable future after > > that... > > It would have to wrap forwards. Basically, if you just have a > > MOV (PC)+,(R0)+ > SPL #7 Yes, that's it! Except it was SPL 0; not that it made any difference, but it was just as devastating in user mode. Damn; I'm still trying to visualise how it works... It took me ages, the first time I saw it; I *think* it propagates the MOV throughout memory, leaving a trail of SPLs behind it? > and make sure that the rest of the memory don't do anything overly > foolish, [...] Not a problem in user mode? > However, another way of achieving this, if you have some kind of control > of the MMU is to just fill one page with SPLs, and then remap all of > your memory to be that page. The last page you remap is just the page > that holds all the code doing the setup. But you'd need kernel mode for that; this is a DoS attack (one of the first?) launched by a user. > > If I find the article I'll post it here; I don't think there are too > > many 11/70s still in public operation. > > Well, ours is occasionally. It's off at the moment, since we're not > allowed to consume that much money anymore, but Magica.Update.UU.SE is > just a key turn away from being online. Cool :-) > > I'll remember that, should I ever see an emulator :-) I still > > remember Ian Johnstone cursing me... > > :-) It was two words: "YOU XXXX!" (an indelicate term for a part of the female anatomy) followed by the phone being slammed down... > Oh, that would be having the HALT switch down and pressing the START > switch, by the way. That combination will trigger a Unibus reset, and > will bring the CPU out of almost all catatonic states that I've seen, > including serious bus problems. Interesting. I knew the HALT switch didn't halt the box right away; bus transfers still completed so we were taught to W/PROT the RK-05s *after* hitting HALT, but I didn't know it worked in combination. -- Dave ^ permalink raw reply [flat|nested] 5+ messages in thread
* [pups] Issues of AUUGN 2006-10-04 10:22 ` Dave Horsfall @ 2006-10-04 11:11 ` Johnny Billquist 0 siblings, 0 replies; 5+ messages in thread From: Johnny Billquist @ 2006-10-04 11:11 UTC (permalink / raw) Dave Horsfall wrote: > On Wed, 4 Oct 2006, Johnny Billquist wrote: > >>>There was a clever assembly program that did it; it relied upon the >>>instruction counter wrapping around (I can't remember in which >>>direction, or whether it first relocated itself). Anyone, it managed >>>to fill memory with SPLs, so the next instruction after overwriting >>>its last instruction was SPL, and for the foreseeable future after >>>that... >> >>It would have to wrap forwards. Basically, if you just have a >> >> MOV (PC)+,(R0)+ >> SPL #7 > > Yes, that's it! Except it was SPL 0; not that it made any difference, but > it was just as devastating in user mode. Interesting thing, though. I didn't know that SPL blocked interrupts for the next instruction. Always something more to learn... > Damn; I'm still trying to visualise how it works... It took me ages, the > first time I saw it; I *think* it propagates the MOV throughout memory, > leaving a trail of SPLs behind it? Nope. That snippet I wrote now just copies the SPL in the instruction after the MOV to wherever R0 is pointing. The key is that both these instructions takes just one word. Actually, here is an improved version: MOV (PC)+,R0 .WORD FOO FOO: MOV (PC)+,-(R0) SPL #0 BR FOO (Sorry about the DEC syntax, I've never learned as) This code will work fine no matter what is in memory, and no matter where we have the program. This code will start by overwriting the .WORD FOO with the SPL, then overwrite the MOV, and then continue backwards, wrap around, write from the end of memory back towards the branch. When we overwrite the branch instruction we will no longer be in our tight loop. However all other memory than what we have here is now containing the SPL instruction, so running through that is no problem, and we will wrap to the start of the memory and at a later time once again come to the MOV (PC)+,-(R0), which this time will overwrite the SPL instruction with the SPL instruction. Basically just a decrement of R0. Next time around, it will overwrite the MOV (PC)+,-(R0), which will leave just the SPL instructions left. My first version will write forwards, without an explicit loop, so it requires that the rest of the memory didn't modify R0 and didn't branch backwards in a never-ending loop not including the MOV. Perhaps an even more devious piece of code is: MOV -(PC),-(PC) even though it won't hang the machine. :-) >>However, another way of achieving this, if you have some kind of control >>of the MMU is to just fill one page with SPLs, and then remap all of >>your memory to be that page. The last page you remap is just the page >>that holds all the code doing the setup. > > But you'd need kernel mode for that; this is a DoS attack (one of the > first?) launched by a user. You wouldn't need kernel mode if you were programming in RSX, since there are system calls to remap your memory in that OS. You cannot remap it arbitrarily, but you can remap it enough to set this up. >>>If I find the article I'll post it here; I don't think there are too >>>many 11/70s still in public operation. >> >>Well, ours is occasionally. It's off at the moment, since we're not >>allowed to consume that much money anymore, but Magica.Update.UU.SE is >>just a key turn away from being online. > > Cool :-) Heck, we actually have two. But one is enough to have standing ready. We're a computer club, so we exist at the mercy of our university. Our second machine used to run 2.11BSD, but is now in storage. *sigh* Wish we had a little more money designated for our fun. :-) >>Oh, that would be having the HALT switch down and pressing the START >>switch, by the way. That combination will trigger a Unibus reset, and >>will bring the CPU out of almost all catatonic states that I've seen, >>including serious bus problems. > > Interesting. I knew the HALT switch didn't halt the box right away; bus > transfers still completed so we were taught to W/PROT the RK-05s *after* > hitting HALT, but I didn't know it worked in combination. Yeah, the HALT switch will stop the machine at the next instruction fetch. That is, unless you have the S.INST/S.CYCLE switch thrown to the S.CYCLE position, which will cause the machine to stop at the next clock cycle. The thing to realize is that the START switch always performs a bus reset, and then it usually also starts the clocks running in the machine. However, if the HALT switch is active, the clocks won't start running (obviously), so all that remains is the bus reset. Hmm, thinking about this, I wonder how much the CPU is reset by the start switch as well. Maybe I should check if the CPU registers are cleared and so on... The MMU is definitely cleared. Another thing is debugging on the front panel. You have START and CONT, which both will start the CPU clocks. The difference is wether a reset of the machine is done or not. If you want to debug a program from the front panel, you keep the HALT switch down, and pull the CONT switch to step a single instruction or single cycle (depending on the switch). If you raise the HALT switch, CONT will cause the processor to proceed from wherever it is at the moment, while a START also will start the processor, but will reset a number of things so things will not actually be able to proceed as nothing happened. Johnny ^ permalink raw reply [flat|nested] 5+ messages in thread
* [pups] Issues of AUUGN... @ 2006-10-04 4:31 dmr 0 siblings, 0 replies; 5+ messages in thread From: dmr @ 2006-10-04 4:31 UTC (permalink / raw) Dave Horsfall mentioned, about some old editions of AUUGN, > It contains the famous Thrust Meter, a few papers by Yours Truly, and I > think it has the short assembly program that would bring a PDP-11/70 to > its knees (the infamous "SPL" firmware bug). Was this the feature (not really a bug; it's in the manual) that SPL suppressed interrupts for one instruction after the SPL? I suppose it was indeed a bug that this happened even in user mode where SPL was intended to be a no-op. I remember trying this. It depends on completely filling memory with SPLs, which I could not figure out how to do using an instruction sequence. However, putting a bunch of SPLs into a file and reading it in over the program did the job. It was a bit hard to break out of--the halt switch didn't work. At first I thought that power-off was the only solution, but it turned out that holding down both reset and halt simultaneously did the job. Dennis ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-10-04 11:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-10-04 7:00 [pups] Issues of AUUGN Dave Horsfall 2006-10-04 8:22 ` Johnny Billquist 2006-10-04 10:22 ` Dave Horsfall 2006-10-04 11:11 ` Johnny Billquist -- strict thread matches above, loose matches on Subject: below -- 2006-10-04 4:31 dmr
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).