Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759852Ab1CDSPA (ORCPT ); Fri, 4 Mar 2011 13:15:00 -0500 Received: from waste.org ([173.11.57.241]:34872 "EHLO waste.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751790Ab1CDSO7 (ORCPT ); Fri, 4 Mar 2011 13:14:59 -0500 Subject: Re: [PATCH] Make /proc/slabinfo 0400 From: Matt Mackall To: Linus Torvalds Cc: Dave Hansen , Pekka Enberg , Theodore Tso , Dan Rosenberg , cl@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton In-Reply-To: References: <1299174652.2071.12.camel@dan> <1299185882.3062.233.camel@calx> <1299186986.2071.90.camel@dan> <1299188667.3062.259.camel@calx> <1299191400.2071.203.camel@dan> <2DD7330B-2FED-4E58-A76D-93794A877A00@mit.edu> <1299260164.8493.4071.camel@nimitz> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Mar 2011 12:14:55 -0600 Message-ID: <1299262495.3062.298.camel@calx> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2192 Lines: 44 On Fri, 2011-03-04 at 09:48 -0800, Linus Torvalds wrote: > On Fri, Mar 4, 2011 at 9:36 AM, Dave Hansen wrote: > > > > We need to either keep the bad guys away from the counts (this patch), > > or de-correlate the counts moving around with the position of objects in > > the slab. Ted's suggestion is a good one, and the only other thing I > > can think of is to make the values useless, perhaps by batching and > > delaying the (exposed) counts by a random amount. > > We might just decide to expose the 'active' count for regular users > (and then, in case there are tools there that parse this as normal > users, we could set the 'total' fields to be the same as the active > one, possibly rounded up to the slab allocation or something. > > I know, I know, from a memory usage standpoint, 'active' is secondary, > but it still correlates fairly well, so it's still useful. And for > seeing memory leaks (as opposed to slab fragmentation etc issues), > it's actually the interesting case. > > And at the same time, it's actually much less involved with actual > physical allocations than 'total' is, and thus much less of an attack > vector. The fact that we got another socket allocation when we opened > a new socket is not "useful" information for an attacker, not in the > way it is to see a hint of _where_ the socket got allocated. > > Of course, as you say, '/proc/meminfo' still does give you the trigger > for "oh, now somebody actually allocated a new page". That's totally > independent of slabinfo, though (and knowing the number of active > slabs would neither help nor hurt somebody who uses meminfo - you > might as well allocate new sockets in a loop, and use _only_ meminfo > to see when that allocated a new page). I think lying to the user is much worse than changing the permissions. The cost of the resulting confusion is WAY higher. -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/