public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Masoud Sharbiani" <masouds@google.com>,
	"Kirill Korotaev" <dev@openvz.org>,
	linux-kernel@vger.kernel.org
Subject: Re: i386-show-unhandled-signals-v3
Date: Thu, 26 Jul 2007 13:59:46 +0200	[thread overview]
Message-ID: <200707261359.46936.ak@suse.de> (raw)
In-Reply-To: <20070726031406.3866ddc5.akpm@linux-foundation.org>

On Thursday 26 July 2007 12:14:06 Andrew Morton wrote:
> On Thu, 26 Jul 2007 11:46:23 +0200 Andi Kleen <ak@suse.de> wrote:
> 
> > 
> > > Look: if there's a way in which an unprivileged user can trigger a printk
> > > we fix it, end of story. 
> > 
> > I'm firmly against disabling it on x86-64 by default.
> 
> We know you are, and the consensus and past practice disagree with you, as
> you well know.

Well that doesn't mean that the practice makes much sense.

Security (which is probably too strong a word for these relatively
weak DoS anyways; it's not like anybody's data gets leaked like
Alan hinted at with his bogus analogy) is only useful if it's perfect; if it 
has holes that cannot be plugged it is just wasted effort and likely 
harming other good causes (like bug free software) 
 
> > The printks are extremly
> > useful and have found many bugs in the past.
> 
> So you turn it on if your applications are playing up.  bfd.

You might not know applications are segfaulting. e.g. when I originally
enabled it we found that a few obscure cases in a default system
were occasionally segfaulting, but nobody noticed because there
wasn't a really visible malfunction. Still fixing those made
a better system.
 
> Still waiting for your report of all the other means by which unpriviliged
> users can spam the logs, btw.  Of course, your attitude here makes a
> mockery of all our other care and effort in this area.

One standard way is to overflow the socket limits or the TCP memory allocation 
for example. Or just run the system out of memory; that will get plenty of logs
(don't say ulimit now, you know as well as me that they are not good enough
to prevent oom from users). Or use an unaligned a.out executable.

That was just from a quick look, I'm sure there are more.

Some of these are rate limited, but rate limiting just means it will take longer
to fill the disk. 

There are also a couple (rate limited ones) that can be triggered from the network.

Anyways if you feel strongly about it then rate limit the x86-64 ones
(Masoud's patch did this anyways); but please don't turn them off.

-Andi

  reply	other threads:[~2007-07-26 12:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-18 15:47 i386-show-unhandled-signals-v3 Masoud Asgharifard Sharbiani
2007-07-25 14:45 ` i386-show-unhandled-signals-v3 Kirill Korotaev
2007-07-25 14:50   ` i386-show-unhandled-signals-v3 Masoud Sharbiani
2007-07-25 15:01     ` i386-show-unhandled-signals-v3 Kirill Korotaev
2007-07-25 14:57   ` i386-show-unhandled-signals-v3 Andi Kleen
2007-07-25 21:04     ` i386-show-unhandled-signals-v3 Andrew Morton
2007-07-25 21:07       ` i386-show-unhandled-signals-v3 Masoud Sharbiani
2007-07-25 23:25         ` i386-show-unhandled-signals-v3 Andrew Morton
2007-07-25 23:40           ` i386-show-unhandled-signals-v3 Masoud Asgharifard Sharbiani
2007-07-25 23:58             ` i386-show-unhandled-signals-v3 Andrew Morton
2007-07-26  3:21               ` i386-show-unhandled-signals-v3 Masoud Sharbiani
2007-07-26  4:15             ` i386-show-unhandled-signals-v3 Andrew Morton
2007-07-26  9:13           ` i386-show-unhandled-signals-v3 Rene Herman
2007-07-26  9:46           ` i386-show-unhandled-signals-v3 Andi Kleen
2007-07-26 10:14             ` i386-show-unhandled-signals-v3 Andrew Morton
2007-07-26 11:59               ` Andi Kleen [this message]
2007-07-26 12:18                 ` i386-show-unhandled-signals-v3 Alan Cox
2007-07-26 10:16             ` i386-show-unhandled-signals-v3 Alan Cox
2007-07-26 10:17               ` i386-show-unhandled-signals-v3 Rene Herman
2007-07-26 10:25                 ` i386-show-unhandled-signals-v3 Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200707261359.46936.ak@suse.de \
    --to=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=dev@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masouds@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox