linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael H. Warfield" <mhw@wittsend.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: jakob@unthought.net, linux-kernel@vger.kernel.org
Subject: Re: /proc/<n>/maps getting _VERY_ long
Date: Sun, 5 Aug 2001 20:41:43 -0400	[thread overview]
Message-ID: <20010805204143.A18899@alcove.wittsend.com> (raw)
In-Reply-To: <20010805171202.A20716@weta.f00f.org> <E15TNbk-0007pu-00@the-village.bc.nu> <20010806010738.B11372@unthought.net> <200108052341.f75Nfhx08227@penguin.transmeta.com>
In-Reply-To: <200108052341.f75Nfhx08227@penguin.transmeta.com>; from torvalds@transmeta.com on Sun, Aug 05, 2001 at 04:41:43PM -0700

On Sun, Aug 05, 2001 at 04:41:43PM -0700, Linus Torvalds wrote:

	[...]

	I haven't been following this thread previously so I may be
way off base on this, but this caught my attention...

> So we certainly used to do more aggressive merging.

> We could merge more, but I'm not interested in working around broken
> applications. Right now we sanely merge the cases of consecutive
> anonymous mmaps, but we do _not_ merge cases where the app plays silly
> games, for example.

	Hmmm...  Apps that play silly games (intentionally) and
(deliberately) broken apps begin to fall into my territory.  Does
it become possible for a user application to create a system wide
denial of service by playing silly games or does this only affect
the application itself?  Yes, I know there are always ways of creating
denial of service attacks ala fork bombs and such, and I'm coming in on
this thread late, I'm just wondering about the scope of impact of "a
broken application" and does it give some leverage that can be
exploited by some misbehaving individual on a system?

> I'd like to know more than just the app that shows problems - I'd like
> to know what it is doing.

	Bruce Schneier put it best...  Fighting with broken applications
and classical "QA" and testing is programming for Murphy's computer.
Stuff goes bump in the night and broken apps cause bad things to happen.
In the security realm, we are programming for Satan's computer and have
to consider "apps that show problems" in the face of malicious intent.
What if what it is doing is trying to bring the system to its knees?

	If it only causes problems for the broken app, that's fine.  If it
causes problems for the rest of the system, that could be bad.

> 		Linus

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!


  reply	other threads:[~2001-08-06  0:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-04 15:43 /proc/<n>/maps getting _VERY_ long Chris Wedgwood
2001-08-05  2:17 ` Rik van Riel
2001-08-05  5:12   ` Chris Wedgwood
2001-08-05 13:06     ` Alan Cox
2001-08-05 13:18       ` Chris Wedgwood
2001-08-05 23:07       ` Jakob Østergaard
2001-08-05 23:41       ` Linus Torvalds
2001-08-06  0:41         ` Michael H. Warfield [this message]
2001-08-06  1:01           ` Linus Torvalds
2001-08-06  1:17             ` H. Peter Anvin
2001-08-06  4:26               ` Linus Torvalds
2001-08-06  6:30                 ` H. Peter Anvin
2001-08-06 18:41                 ` Jamie Lokier
2001-08-10 21:55                   ` Linus Torvalds
2001-08-10 22:00                     ` H. Peter Anvin
2001-08-10 23:03                       ` Nicolas Pitre
2001-08-10 23:26                       ` Linus Torvalds
2001-08-10 23:55                         ` Rik van Riel
2001-08-11  1:04                     ` Pavel Machek
2001-08-06 11:52               ` Alan Cox
2001-08-06 12:23                 ` Chris Wedgwood
2001-08-06 13:17                   ` Alan Cox
2001-08-06 13:55                     ` Chris Wedgwood
2001-08-06  9:43         ` [LONGish] Brief analysis of VMAs (was: /proc/<n>/maps getting _VERY_ long) Chris Wedgwood
2001-08-05  6:44 /proc/<n>/maps getting _VERY_ long David Luyer
2001-08-05  7:21 ` Anders Eriksson

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=20010805204143.A18899@alcove.wittsend.com \
    --to=mhw@wittsend.com \
    --cc=jakob@unthought.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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;
as well as URLs for NNTP newsgroup(s).