Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932613Ab1CDVNA (ORCPT ); Fri, 4 Mar 2011 16:13:00 -0500 Received: from waste.org ([173.11.57.241]:43451 "EHLO waste.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932540Ab1CDVM6 (ORCPT ); Fri, 4 Mar 2011 16:12:58 -0500 Subject: Re: [PATCH] Make /proc/slabinfo 0400 From: Matt Mackall To: Pekka Enberg Cc: Dan Rosenberg , Linus Torvalds , Dave Hansen , Theodore Tso , 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> <1299262495.3062.298.camel@calx> <1299271041.2071.1398.camel@dan> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Mar 2011 15:12:55 -0600 Message-ID: <1299273175.3062.327.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: 1866 Lines: 39 On Fri, 2011-03-04 at 22:58 +0200, Pekka Enberg wrote: > On Fri, Mar 4, 2011 at 10:37 PM, Dan Rosenberg wrote: > > This patch makes these techniques more difficult by making it hard to > > know whether the last attacker-allocated object resides before a free or > > allocated object. Especially with vulnerabilities that only allow one > > attempt at exploitation before recovery is needed to avoid trashing too > > much heap state and causing a crash, this could go a long way. I'd > > still argue in favor of removing the ability to know how many objects > > are used in a given slab, since randomizing objects doesn't help if you > > know every object is allocated. > > So if the attacker knows every object is allocated, how does that help > if we're randomizing the initial freelist? First note that all of these attacks are probabilistic. Now, with a randomized free list, if I create 1000 objects of type B, then, on average, the partially-filled page the next allocation comes from will be half-full of B objects. Thus, the next object will have a 50% chance of being in the right spot for an exploit. Now if I delete the 800th B object, it's probably on a slab that's otherwise full of B objects since we fill partial slabs before creating new ones. If my next allocation comes from that slab, it will thus get a spot that's almost guaranteed to be in the right spot. Similarly, if I create 1000 objects and then delete every tenth one, I've now got a swiss cheese heap where just about every hole is well-positioned. -- 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/