All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ted Ts'o" <tytso@mit.edu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Michel Lespinasse <walken@google.com>,
	Hugh Dickins <hughd@google.com>,
	Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <david@fromorbit.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Nick Piggin <npiggin@kernel.dk>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Rik van Riel <riel@redhat.com>,
	Kosaki Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Theodore Tso <tytso@google.com>,
	Michael Rubin <mrubin@google.com>,
	Suleiman Souhlal <suleiman@google.com>,
	Dustin Kirkland <kirkland@canonical.com>
Subject: Re: [PATCH 3/3] mlock: avoid dirtying pages and triggering writeback
Date: Fri, 19 Nov 2010 18:22:54 -0500	[thread overview]
Message-ID: <20101119232254.GA28151@thunk.org> (raw)
In-Reply-To: <20101119145442.ddf0c0e8.akpm@linux-foundation.org>

On Fri, Nov 19, 2010 at 02:54:42PM -0800, Andrew Morton wrote:
> 
> Dirtying all that memory at mlock() time is pretty obnoxious.
> ...
> So all that leaves me thinking that we merge your patches as-is.  Then
> work out why users can fairly trivially use mlock to hang the kernel on
> ext2 and ext3 (and others?) 

So at least on RHEL 4 and 5 systems, pam_limits was configured so that
unprivileged processes could only mlock() at most 16k.  This was
deemed enough so that programs could protect crypto keys.  The
thinking when we added the mlock() ulimit setting was that
unprivileged users could very easily make a nuisance of themselves,
and grab way too much system resources, by using mlock() in obnoxious
ways.

I was just checking to see if my memory was correct, and to my
surprise, I've just found that Ubuntu deliberately sets the memlock
ulimit to be unlimited.  Which means that Ubuntu systems are
completely wide open for this particular DOS attack.  So if you
administer an Ubuntu-based server, it might be a good idea to make a
tiny little change to /etc/security/limits.conf....

							- Ted

WARNING: multiple messages have this Message-ID (diff)
From: Ted Ts'o <tytso@mit.edu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Michel Lespinasse <walken@google.com>,
	Hugh Dickins <hughd@google.com>,
	Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <david@fromorbit.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Nick Piggin <npiggin@kernel.dk>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Rik van Riel <riel@redhat.com>,
	Kosaki Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Theodore Tso <tytso@google.com>,
	Michael Rubin <mrubin@google.com>,
	Suleiman Souhlal <suleiman@google.com>,
	Dustin Kirkland <kirkland@canonical.com>
Subject: Re: [PATCH 3/3] mlock: avoid dirtying pages and triggering writeback
Date: Fri, 19 Nov 2010 18:22:54 -0500	[thread overview]
Message-ID: <20101119232254.GA28151@thunk.org> (raw)
In-Reply-To: <20101119145442.ddf0c0e8.akpm@linux-foundation.org>

On Fri, Nov 19, 2010 at 02:54:42PM -0800, Andrew Morton wrote:
> 
> Dirtying all that memory at mlock() time is pretty obnoxious.
> ...
> So all that leaves me thinking that we merge your patches as-is.  Then
> work out why users can fairly trivially use mlock to hang the kernel on
> ext2 and ext3 (and others?) 

So at least on RHEL 4 and 5 systems, pam_limits was configured so that
unprivileged processes could only mlock() at most 16k.  This was
deemed enough so that programs could protect crypto keys.  The
thinking when we added the mlock() ulimit setting was that
unprivileged users could very easily make a nuisance of themselves,
and grab way too much system resources, by using mlock() in obnoxious
ways.

I was just checking to see if my memory was correct, and to my
surprise, I've just found that Ubuntu deliberately sets the memlock
ulimit to be unlimited.  Which means that Ubuntu systems are
completely wide open for this particular DOS attack.  So if you
administer an Ubuntu-based server, it might be a good idea to make a
tiny little change to /etc/security/limits.conf....

							- Ted

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-11-19 23:23 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-17 12:23 [PATCH 0/3] Avoid dirtying pages during mlock Michel Lespinasse
2010-11-17 12:23 ` Michel Lespinasse
2010-11-17 12:23 ` [PATCH 1/3] do_wp_page: remove the 'reuse' flag Michel Lespinasse
2010-11-17 12:23   ` Michel Lespinasse
2010-11-17 12:23 ` [PATCH 2/3] do_wp_page: clarify dirty_page handling Michel Lespinasse
2010-11-17 12:23   ` Michel Lespinasse
2010-11-17 12:23 ` [PATCH 3/3] mlock: avoid dirtying pages and triggering writeback Michel Lespinasse
2010-11-17 12:23   ` Michel Lespinasse
2010-11-17 12:57   ` Nick Piggin
2010-11-17 12:57     ` Nick Piggin
2010-11-17 15:28     ` Peter Zijlstra
2010-11-17 15:28       ` Peter Zijlstra
2010-11-17 22:05       ` Michel Lespinasse
2010-11-17 22:05         ` Michel Lespinasse
2010-11-17 22:18         ` Peter Zijlstra
2010-11-17 22:18           ` Peter Zijlstra
2010-11-17 23:11         ` Dave Chinner
2010-11-17 23:11           ` Dave Chinner
2010-11-17 23:31           ` Michel Lespinasse
2010-11-17 23:31             ` Michel Lespinasse
2010-11-19  1:46             ` Dave Chinner
2010-11-19  1:46               ` Dave Chinner
2010-11-17 23:52           ` Ted Ts'o
2010-11-17 23:52             ` Ted Ts'o
2010-11-18  0:53             ` Andrew Morton
2010-11-18  0:53               ` Andrew Morton
2010-11-18 11:03               ` Michel Lespinasse
2010-11-18 11:03                 ` Michel Lespinasse
2010-11-18 13:37           ` Christoph Hellwig
2010-11-18 13:37             ` Christoph Hellwig
2010-11-18 17:41             ` Hugh Dickins
2010-11-18 17:41               ` Hugh Dickins
2010-11-19  7:23               ` Michel Lespinasse
2010-11-19  7:23                 ` Michel Lespinasse
2010-11-19 13:38                 ` Theodore Tso
2010-11-19 13:42                 ` Theodore Tso
2010-11-19 13:42                   ` Theodore Tso
2010-11-19 15:06                   ` Christoph Hellwig
2010-11-19 15:06                     ` Christoph Hellwig
2010-11-19 22:54                 ` Andrew Morton
2010-11-19 22:54                   ` Andrew Morton
2010-11-19 23:22                   ` Ted Ts'o [this message]
2010-11-19 23:22                     ` Ted Ts'o
2010-11-20  0:29                     ` Dustin Kirkland
2010-11-19 23:31                   ` Michel Lespinasse
2010-11-19 23:31                     ` Michel Lespinasse
2010-11-19 23:54                 ` Dave Chinner
2010-11-19 23:54                   ` Dave Chinner
2010-11-18  5:46       ` Nick Piggin
2010-11-18  5:46         ` Nick Piggin
2010-11-18 10:43         ` Theodore Tso
2010-11-18 10:43           ` Theodore Tso
2010-11-18 13:39           ` Christoph Hellwig
2010-11-18 13:39             ` Christoph Hellwig
2010-11-18 18:00             ` Hugh Dickins
2010-11-18 18:00               ` Hugh Dickins

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=20101119232254.GA28151@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=hughd@google.com \
    --cc=kirkland@canonical.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mrubin@google.com \
    --cc=npiggin@kernel.dk \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=suleiman@google.com \
    --cc=tytso@google.com \
    --cc=walken@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.