linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@kernel.org>
To: Theodore Tso <tytso@mit.edu>
Cc: Dan Rosenberg <drosenberg@vsecurity.com>,
	Matt Mackall <mpm@selenic.com>,
	cl@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] Make /proc/slabinfo 0400
Date: Fri, 4 Mar 2011 08:52:04 +0200	[thread overview]
Message-ID: <AANLkTimpfk8EHjVKYsJv0p_G7tS2yB-n=PPbD2v7xefV@mail.gmail.com> (raw)
In-Reply-To: <2DD7330B-2FED-4E58-A76D-93794A877A00@mit.edu>

On Mar 3, 2011, at 5:30 PM, Dan Rosenberg wrote:
>> I appreciate your input on this, you've made very reasonable points.
>> I'm just not convinced that those few real users are being substantially
>> inconvenienced, even if there's only a small benefit for the larger
>> population of users who are at risk for attacks.  Perhaps others could
>> contribute their opinions to the discussion.

On Fri, Mar 4, 2011 at 2:50 AM, Theodore Tso <tytso@mit.edu> wrote:
> Being able to monitor /proc/slabinfo is incredibly useful for finding various
> kernel problems.  We can see if some part of the kernel is out of balance,
> and we can also find memory leaks.   I once saved a school system's Linux
> deployment because their systems were crashing once a week, and becoming
> progressively more unreliable before they crashed, and the school board
> was about to pull the plug.

Indeed. However, I'm not sure we need to expose the number of _active
objects_ to non-CAP_ADMIN users (which could be set to zeros if you
don't have sufficient privileges). Memory leaks can be detected from
the total number of objects anyway, no?

On Fri, Mar 4, 2011 at 2:50 AM, Theodore Tso <tytso@mit.edu> wrote:
> I wonder if there is some other change we could make to the slab allocator
> that would make it harder for exploit writers without having to protect the
> /proc/slabinfo file.  For example, could we randomly select different free
> objects in a page instead of filling them in sequentially?

We can do something like that if we can live with the performance costs.

--
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 internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-03-04  6:52 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-03 17:50 Dan Rosenberg
2011-03-03 18:17 ` Dave Hansen
2011-03-03 18:29   ` Dan Rosenberg
2011-03-03 20:58 ` Matt Mackall
2011-03-03 21:16   ` Dan Rosenberg
2011-03-03 21:44     ` Matt Mackall
2011-03-03 22:30       ` Dan Rosenberg
2011-03-03 23:08         ` Matt Mackall
2011-03-04  0:32           ` Dave Hansen
2011-03-04  0:50         ` Theodore Tso
2011-03-04  6:52           ` Pekka Enberg [this message]
2011-03-04 17:36             ` Dave Hansen
2011-03-04 17:48               ` Linus Torvalds
2011-03-04 18:14                 ` Matt Mackall
2011-03-04 20:02                   ` Pekka Enberg
2011-03-04 20:31                     ` Matt Mackall
2011-03-04 20:42                       ` Dan Rosenberg
2011-03-04 20:56                         ` Pekka Enberg
2011-03-04 21:08                           ` Dan Rosenberg
2011-03-04 21:30                             ` Pekka Enberg
2011-03-04 21:44                               ` Dan Rosenberg
2011-03-04 22:10                                 ` Pekka Enberg
2011-03-04 22:14                                   ` Pekka Enberg
2011-03-04 23:02                                     ` Matt Mackall
2011-03-05 16:25                                       ` Ted Ts'o
2011-03-06 13:19                                         ` Alan Cox
2011-03-07 14:56                                           ` Dan Rosenberg
2011-03-07 16:02                                             ` Matt Mackall
2011-03-04 20:37                     ` Dan Rosenberg
2011-03-04 20:58                       ` Pekka Enberg
2011-03-04 21:10                         ` Dan Rosenberg
2011-03-06  0:42                           ` Jesper Juhl
2011-03-06  0:57                             ` Dan Rosenberg
2011-03-06  1:09                             ` Matt Mackall
2011-03-06  1:15                               ` Jesper Juhl
2011-03-07 16:40                                 ` Christoph Lameter
2011-03-04 21:12                         ` Matt Mackall
2011-03-04 11:58           ` Alan Cox
2011-03-07 14:19 [PATCH] Make /proc/slabinfo 040 George Spelvin
2011-03-07 17:49 ` [PATCH] Make /proc/slabinfo 0400 George Spelvin

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='AANLkTimpfk8EHjVKYsJv0p_G7tS2yB-n=PPbD2v7xefV@mail.gmail.com' \
    --to=penberg@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=drosenberg@vsecurity.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=mpm@selenic.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /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