> But you'd need kernel mode for that; this is a DoS attack (one of the
> first?) launched by a user.
The userland DoS I remember:
main() {
while(1)
fork();
}
And in fact I tried it once on the 11/45 I had access to. Not pretty.
It can be made less disastrous by judicious addition of a wait(); call.
--Milo, wondering how contemporary UNIX will deal with such
pathological behavior....
--
Milo Velimirović
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA
43 48 48 N 91 13 53 W
--
There's a reason Dennis Ritchie and Ken Thompson have been awarded
the U.S. National Medal of Technology (1998) and are fellows of the
Computer History Museum Online. Dave Cutler hasn't and isn't.
"You are not expected to understand this."
[ Meant to go to list, but sent to DMR only by mistake. ]
On Wed, 4 Oct 2006 dmr(a)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
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
Hi,
at
http://www.ba-stuttgart.de/~helbig/os/script/chapt2.2
I tried to explain the dynamic memory allocation in Unix V6.
Greetings,
Wolfgang
--
"Dijkstra is right, but you don't say such things!"
(A less courageous programmer)
hi Brantley,
Now I start to understand what's going on.
But do you mean 0744 by 0743?
0743 mov (sp), r0
0744 mov $_u, r0
And 2230 should be 2229, which is:
2229 sureg();
Thanks &
Regards,
Qinglai
On 10/3/06, Brantley Coile <brantley(a)coraid.com> wrote:
> Rp->p_addr is the address of the swappable image in core. The process
> image begins with the user segment for that process. Line 0743 maps
> the upage into the current address space (KISA6) and _retu loads
> previously saved sp and r5 from there. Notice that on line 2230
> Ken reloads the other memory mapping registers.
>
> Read the section `Memory Management' starting on page 2-4 for background
> on this.
>
>
> U.u_rsave is just a constant location in memory. Notice that rp->p_addr
> isn't a byte address but a core click address in units of 64 bytes.
>
> Hope that helps.
>
> Brantley
>
> > The final question is about how savu/retu work.
> >
> > savu:
> > line 0729 and line 0730: r5 and sp are saved to (r0) and (r0)+, which
> > are the address of u.u_rsav.
> >
> > retu:
> > 0746 and 0747: sp and r5 are read from (r0) and (r0)+, which is
> > "rp->p_addr" (see line 2228). It looks weird to me. (Okay...I have to
> > confess I look stupid here...) When making call to retu, why bother
> > "retu(rp->p_addr)"? Why not calling with "retu(u.u_rsav)"? Does it
> > mean that rp->p_addr == u.u_rsav?
>
>
hi All,
Again, I run into problems when reading slp.c and savu/retu.
Actually, I have 3 questions.
First, I doubt whether all processes share one "u" or each process has
its own "u".
line 0402: One allocated per process.
It seems that each process has its own user structure.
But the "u" is defined as a universal variable (line 0459), and the
line 0407 clearly states that the "u" resides at virtual kernel loc
140000.
So isn't it saying that there's only one "u" in the core memory?
This concept is very important, because it's bound tightly with
savu/retu mechanism.
---------------------------------------------------------------------------
Now comes the second question:
The savu procedure is supposed to save r5 and sp to u.u_rsav,
and the retu is supposed to reset the r5 and sp with the saved values.
If each process has its own u, then savu/retu simply work fine.
But if all processes share one u, the newest call to savu will
overwrite the previously saved values of r5 and sp, so that retu is
not able to get back the r5/sp again!
The story is like this:
1889: r5/sp of process #1 are saved to u.u_rsav
2189: r5/sp of process #0 are saved! Thus overwriting the values of process #1.
So when we are coming to 2228, how can retu work in a way as it is expected to?
-----------------------------------------------------------------------------
The final question is about how savu/retu work.
savu:
line 0729 and line 0730: r5 and sp are saved to (r0) and (r0)+, which
are the address of u.u_rsav.
retu:
0746 and 0747: sp and r5 are read from (r0) and (r0)+, which is
"rp->p_addr" (see line 2228). It looks weird to me. (Okay...I have to
confess I look stupid here...) When making call to retu, why bother
"retu(rp->p_addr)"? Why not calling with "retu(u.u_rsav)"? Does it
mean that rp->p_addr == u.u_rsav?
OMG, I am totally confused...
--------------------------------------------------------------------------------
I guess It's kind of boring to read my question...but hopefully
someone can give me some hint...Thanks in advance!
Regards,
Qinglai
hi all,
I just started to read the source code of V6 with Lion's book.
But before I went far I was stopped by m40.s
0636: mov $USIZE-1/<8|6, (r1)+
What does the slash "/" stand for?
I guess this line should be
mov $USIZE-1<<8|6, (r1)+
Is "/<" the same as "<<"?
I checked in Unix PDP11 Assemble Refrence Manual but didn't find a clue.
Is it the right place to ask such question?
Thanks in advance
Regards,
Qinglai