[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131213111027.75bcc430@alan.etchedpixels.co.uk>
Date: Fri, 13 Dec 2013 11:10:27 +0000
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Kees Cook <keescook@...omium.org>
Cc: Ryan Mallon <rmallon@...il.com>, "Theodore Ts'o" <tytso@....edu>,
vegard.nossum@...cle.com, LKML <linux-kernel@...r.kernel.org>,
Tommi Rantala <tt.rantala@...il.com>,
Ingo Molnar <mingo@...nel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Andy Lutomirski <luto@...capital.net>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Alan Cox <alan@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jason Wang <jasowang@...hat.com>,
"David S. Miller" <davem@...emloft.net>,
Dan Carpenter <dan.carpenter@...cle.com>,
James Morris <james.l.morris@...cle.com>
Subject: Re: [PATCH 1/9] Known exploit detection
> Totally true, but there's a million way to DoS a local machine. At
> least this way shows who's doing it. It's the DoSes that don't include
> attribution that I worry about. :)
So long as they compile out to nothingness for all the systems where this
stuff is useless (ie most of them because they are embedded or phones
etc) I don't see a big problem.
Note however if you trip one of those in any code with the console lock
held and your log goes to the consoles due to printk level or similar
you'll probably hang the box.
There are some other lock sequences that are going to do that too, so it
can't be placed arbitarily but will need the locking assumptions for each
non-obvious one documented clearly.
Alan
--
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