Date: Tue, 07 Nov 2000 23:21:46 +0100 From: Poul-Henning Kamp <phk@freebsd.org> To: arch@freebsd.org Subject: Green/Yellow/Red state for the VM system. Message-ID: <28041.973635706@critter>
next in thread | raw e-mail | index | archive | help
Varios people have heard about this in private conversations before,
so it's probably time for me to pull the plug and plug it publically.
To all of you northern californians, this proposal should come as
nothing new at all, you've seen your electrical grid do this again
this summer: You cut some load entirely in order to keep the
majority of the grid intact.
We need to do the same thing about resource-shortages in the kernel.
The easiest way to deal with overload and DoS attacks is to recognize
them as such, go into defensive mode and weather it.
If we implement a generic facility for this, we will have a lot less
worries about future DoS attacks, because our generic mechanism will
deal with a lot of them on its own.
The facility I hinted at in an earlier email is this:
The VM system maintains an enum variables:
enum {GREEN, YELLOW, RED} kvm_light;
When kvm_light changes value, a kernel event-handler list is activiated.
GREEN means "No worries". And signals that all kernel code can go
about their business as usual.
YELLOW means "Don't make it any worse". This state is set as a high
water mark, and tries to prevent us from ever entering:
RED which means "Disaster on our hands.".
Various pieces of code can use these state changes to modify their
behaviour according to the state of the kvm_light. Here are
some straw-man examples, just to show the concept:
vfs_name_cache:
Yellow:
Drop two entries every time we make one.
Red:
Drop all entries, make no new ones.
Vnode system:
Yellow:
Allocate no new vnodes.
Red:
Garbage collect and free vnodes.
(yes, this *is* possible, but only as a last resort thing.)
IP:
Yellow:
Expire cloned routes faster.
Stop generating ICMP packets.
Stop forwarding packets.
Red:
Expire all cloned routes now.
TCP:
Yellow:
Accept no new TCP connections.
Reduce outgoing TCP windows.
Drop all sessions which have not passed
a packet in the last N seconds.
Red:
Drop all un-assembled fragments.
Drop all "final-stages" TCP pcbs.
Drop all sessions which have not passed
a packet in the last M seconds. (M << N)
Now, before anyone starts point indignated fingers in RFC's and
other such moral high-ground, let me just make it perfectly clear
that YELLOW isn't set until the system detects the risk of meltdown
and RED is the meltdown.
Think of YELLOW as being set a little while before you cannot log
into the console in finite time anymore and usually decide to give
the machine a reboot/reset to get it back into action.
RED is when the machine would normally wedge solid or panic.
As can be seen from the above, the only and entire impact on the
VM system is to maintain the kvm_light variable and call the
eventahandler when it is changed. The rest of this is about getting
individual parts of the kernel to behave more responsible in YELLOW,
and to start pumping water all they can in RED.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28041.973635706>