From owner-freebsd-arch  Tue Nov  7 14:21:50 2000
Delivered-To: freebsd-arch@freebsd.org
Received: from critter.freebsd.dk (fw2.aub.dk [195.24.1.195])
	by hub.freebsd.org (Postfix) with ESMTP id 675C337B479
	for <arch@freebsd.org>; Tue,  7 Nov 2000 14:21:46 -0800 (PST)
Received: from critter (localhost [127.0.0.1])
	by critter.freebsd.dk (8.11.1/8.9.3) with ESMTP id eA7MLkD28043
	for <arch@freebsd.org>; Tue, 7 Nov 2000 23:21:46 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: arch@freebsd.org
Subject: Green/Yellow/Red state for the VM system.
From: Poul-Henning Kamp <phk@freebsd.org>
Date: Tue, 07 Nov 2000 23:21:46 +0100
Message-ID: <28041.973635706@critter>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


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