FYI...
Just a friendly reminder - DoS Happens! Start your homework early!
-Ian
----------
Ian Becker UNIX Systems Administrator
ibecker(a)fas.harvard.edu FAS Computer Services
(617) 495-9768 Harvard University
---------- Forwarded message ----------
Date: Wed, 21 Mar 2001 02:57:02 -0500 (EST)
From: FAS Computer Services <announce(a)fas.harvard.edu>
To: netcontacts(a)noc.fas.harvard.edu
Newsgroups: harvard.hascs
Subject: Unscheduled Network Service Interruption (03/20/01)
An extended period of network service interruptions was
experienced starting shortly after 7PM this evening. Our
problems began in the wake on a TCP SYN based Denial of
Service attack involving multiple external sources against
multiple destinations inside the FAS Network.
In an effort to bring this situation under control, and due to
there being no discernable pattern to attacks that would
readily respond to temporary filtering, implementing
widespread active TCP SYN protection mechanisms on our border
appeared to be our only effective solution. Although we have
had this screening in place for some time on a limited subset
of FAS networks, the existing border gateway facility did not
possess the resources to support such a expansion of the
service. We were then presented with a bit of a no-win
situation -- to allow the attacks to continue in hopes they
would subside created a bandwidth problem, and attempting to
implement widespread reactive TCP SYN protection created a
resource problem.
In response, we opted to accelerate the work scheduled for
tomorrow morning and brought the new temporary border router
on-line. Although the initial focus of tomorrow's maintenance
window was simply to lay the groundwork for future work get
the new facility up running the status quo, we escalated some
of the resource work in hope of getting the TCP SYN protection
mechanism in place. The good news is that it is in place and
ready for evaluation next time we see similar DoS activity,
the bad is that it did not come without a fight.
Unfortunately, this turned into a bug hunt, as we experienced
a variety of transition stability problems under load. In the
end, after exhaustive configuration and software release
analysis, a hardware problem was found.
Moving to an alternate interface appears to have stabilized
the link, and we have not seen a repeat of the previous
behavior as of 1:36AM. Although we will continue to monitor
the link, please report any ongoing problems you feel may be
related to this event to your support resource.
FAS Network Operations
When ram_bootsrap() finishes, firstpaddr is set to 102400 and lastpaddr is
set to 524288. However, when I then call vm_boostrap() and inside
vm_boostrap call ram_stealmem() with an argument of 1 to get a single page
worth of memory, it fails; gdb, within ram_stealmem, says that both
firstpaddr and lastpaddr are 0, and because of this it returns 0. This
causes my entire system to fail because it couldn't get any memory. Any
ideas on what I'm doing wrong? Is it incorrect to call vm_boostrap
immediately after ram_bootsrap in the boot() function? I had to move
vm_bootstrap to before scheduler_bootstrap() because the scheduler bootstrap
needs to kmalloc in order to create its queues.
Thanks,
Steve
Did anyone else notice that ice/fas was acting super sluggish to dead for most
of the night? In particular 9-11 PM?
--arvin
*******************************************
On reflecting at dinner that he had done nothing to help anybody
all day, he uttered these memorable and praiseworthy words.
"Friends, I have lost a day."
-Suetonius
We're having trouble compiling our asst3 using the solution set. We added
vm.c to the vm directory, added it to the conf.kern, and did the whole
config and make depend thing. When we try to compile, we get a ton of parse
errors in machine/vm.h, which is included from vm.h which is included at the
very top of our vm.c file. The first parse error happens on the typedef
u_int32_t paddr_t line. Any ideas why this is happening? We're stumped!
Thanks,
Steve
a couple of bugs were found in the asst2 sol set (concerning dup2'ing a fd
to itself and waiting on your own pid). corrected versions have been
posted to the website, along with a patch for those of you already using
the solution set. that patch is also attached to this email.
-amos
Finally, System/161 is released for real and available on the
downloads page. We apologize for taking so long on this.
I have also installed the new version in the cs161 account on ICE.
This has one possible consequence if you've already started coding
asst3: the new version will complain if you load duplicate TLB entries
(which is prohibited by the MIPS spec) instead of just behaving
erratically. So if you suddenly start getting errors about duplicate
TLB entries that you weren't getting before, that's why...
Also, by popular demand, this version has better latency modeling in
emufs. This means you can put your swap file(s) on emufs if you like.
However, I still recommend writing your VM system so it swaps to a
single arbitrary vnode.
If you download your own copy of sys161, please check periodically for
new versions.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
Besides the matmult fix, there are three additional patches you will
want to apply:
- one that keeps array.c from passing NULL to kfree();
- one that fixes the argument handling in bin/mv;
- one that fixes a silly mistake in the sfs filesystem.
You won't actually need the last two until asst4, but we recommend you
apply the patches now to make sure you don't forget.
The three patches above have *not* been mailed to the list. They are
posted on the downloads page.
In addition to those, there are three other patches posted as well:
- the fix to bitmap.c that was mailed out the week before last;
- the fix to testbin/crash that was discussed around the same time;
- and the matmult patch I just mailed out.
Please check to make sure you have all of them applied to your system.
If you have questions or concerns, please contact the teaching staff.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
The "matmult" test program was accidentally sized to be geared to a
system with 2 megabytes of main memory instead of 512k. Apart from the
memory size, making it this large also makes it prohibitively slow.
Please change the "Dim" #define from 725 to 360, as per this patch:
Index: src/testbin/matmult/matmult.c
===================================================================
RCS file: /disk/disk0/cs161/CVSREPO/os161/src/testbin/matmult/matmult.c,v
retrieving revision 1.1
diff -u -r1.1 matmult.c
--- matmult.c 2001/02/01 17:59:41 1.1
+++ matmult.c 2001/03/19 20:23:11
@@ -10,7 +10,7 @@
#include <unistd.h>
#include <stdio.h>
-#define Dim 725 /* sum total of the arrays doesn't fit in
+#define Dim 360 /* sum total of the arrays doesn't fit in
* physical memory
*/
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu | http://www.eecs.harvard.edu/vino
