From owner-freebsd-current@FreeBSD.ORG Sun Sep 23 11:34:45 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56DA316A419 for ; Sun, 23 Sep 2007 11:34:45 +0000 (UTC) (envelope-from andrea@webcom.it) Received: from www.webcom.it (gen053.n002.c03.escapebox.net [213.73.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id 11C1C13C4A3 for ; Sun, 23 Sep 2007 11:34:45 +0000 (UTC) (envelope-from andrea@webcom.it) Received: from andrea by webcom.it with local (Exim 3.36 #1) id 1IZPTU-0008Wk-00 for current@freebsd.org; Sun, 23 Sep 2007 11:18:08 +0000 Date: Sun, 23 Sep 2007 11:18:08 +0000 From: Andrea Campi To: current@freebsd.org Message-ID: <20070923111808.GD31406@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Sender: Andrea Campi Cc: Subject: jemalloc malloc_usable_size() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2007 11:34:45 -0000 Hi all, for a university project, I have been working on a LD_PRELOAD wrapper for the string.h functions, similar in concept to HeapShield [1]. In short, I wrap all functions, determine the size of the usable allocation, then (if available) I translate the original call into a safer one (strcpy becomes strlcpy, and so on). I have been mostly targeting 6.x, where I wrote my own code to figure out the allocation size. On 7.x though, I figured I could use malloc_usable_size(). However, I encountered a few problems. First of all, jemalloc makes no effort (neither here nor in free(3)) to survive being called with non-malloc'ed pointers. If you do that and asserts are on, you will get an abort, but if they are not your process will likely die an horrible death--but there's no explicit guarantee of that. I suppose that's fine (we are talking major WTFs after all) in general, although it would be nice to have more control. phkmalloc had more limit checking, so bad pointers (text / stack) were reliably detected. Worse, malloc_usable_size() fails if you pass it a pointer inside a malloc'ed region. Again, you get an assert if that's enable, otherwise you probably get a random value. The reason for this is in arena_salloc, where the passed pointer is compared to the calculated page, to determine whether we are dealing with a small or large allocation. Unfortunately, I don't see an easy fix for this. Do you have any suggestion, or should I just give up on using malloc_usable_size()? As an aside: regardless of my purely educational exercise, what do you guys think of putting such checks in the libc itself? The performance impact is relatively small, and the benefits in terms of detecing and preventing heap buffer overflows huge. That's all the more important with jemalloc, which is (relatively) less safe that phkmalloc in fact of such attacks. Bye, Andrea 1: http://www.cs.umass.edu/~emery/pubs/06-28.pdf -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it.