[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTim3h2EBcEUP19S2Z0CKA7Oe3k5pB=4LjXsOR3F9@mail.gmail.com>
Date: Tue, 14 Dec 2010 07:49:37 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Suzuki K. Poulose" <suzuki@...ibm.com>
Cc: linux-kernel@...r.kernel.org,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
Christoph Hellwig <hch@....de>,
Masami Hiramatsu <mhiramat@...hat.com>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Daisuke HATAYAMA <d.hatayama@...fujitsu.com>,
Andi Kleen <andi@...stfloor.org>,
Roland McGrath <roland@...hat.com>,
Amerigo Wang <amwang@...hat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Oleg Nesterov <oleg@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC] [Patch 0/21] Non disruptive application core dump infrastructure
On Tue, Dec 14, 2010 at 1:52 AM, Suzuki K. Poulose <suzuki@...ibm.com> wrote:
>
> This is series of patches implementing an infrastructure for capturing the core
> of an application without disrupting its process semantics.
>
> The infrastructure makes use of the freezer subsystem in kernel to freeze the
> threads and then collect the information to generate the core.
This seems to be a fundamentally flawed approach.
>From a security standpoint, it looks like a total disaster. A frozen
process is really hard to get rid of, so it looks like an obvious DoS
attack to just create lots of processes, then sneakily freeze them
all, and then laugh at the poor system admin who has no idea what's
going on. While frozen, the things are basically unkillable but look
entirely normal, no?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists