You're right, but panic() is seldom the right solution, even in such case.
In most cases, killing the process generating the noise (or all the
processes of its uid) is enough and keeps the system more robust. Even if
the system runs out of log-space and fails to stop the noise-maker, it can
usually take down network interfaces and alert the admin. Still cleaner
than crashing. Thats what Cray Unicos does when low on certain resources.
It stops the attack while minimizing recovery time. (Rebooting these
beasts can be painful). The system stops network traffic while it still
has some space left, and panics only if it still runs out of space
(unlikely). No audit trail lost and its more graceful.
I'm not saying there is no possible situation where crashing
is required, but its rare.
>
> Security requirements are heavily dependant on role and people sometimes
> forget that. Being down is bad news for an ecommerce site but in many
> other situations its infinite preferably to most other situations
>
Right. Thats why such systems usually come clustered. The panic()ed
system stays down until checked, but another system takes its role.
Still, military systems have to "think twice" before resorting to crash.
Remember that they're usually attacked just as war commences and all hell
breaks loose. If your defense systems are too easy to DoS, you can't rely
on them and their secrecy won't help you. In such cases an unreliable
system can be worse than no system at all. If allies could DoS the Enigma
and force the Nazis to use their fallback system (which was kinda lame),
they wouldn't have to spend resources on cracking the Enigma.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/