From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 26 23:51:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2099F24; Thu, 26 Jun 2014 23:51:06 +0000 (UTC) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1BC5268B; Thu, 26 Jun 2014 23:51:06 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id nu7so4798198obb.16 for ; Thu, 26 Jun 2014 16:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jonqx7usY9hytMnogVYV7pUg7SZ7FL5dfb3869UYZtw=; b=DV4hYfoO1vAwLKE8uSk3F97CI4zogoofls+HHKHyI9B4J2JBBN7L/IT14htT/G2KgB lzynFSCeQ4sxg1AX9xiPUc4aAfQSnn/o4xGFK7WPDxR4EDGvFb2PuycWqgzb4bxLw8WD gl/LYDZJ5XanEn7nlan6HMr1jxGhpLrbrQxvJ773NAn4ao5D1hqBbo/Pgnp4Qgi1gdEe +RsgJzd6+dqPYDbLhcS0cGcHs3MKXLIk5yWEu+UXH+1xt3Jd8ucLsRv7USCeJBWrXHER uF2koRUFPbzIPTtfTworrTZmkXv20JiSVWVjifIfQJ2RsrFbmZtwT0pkAGVVxkUVWU4v 0lCA== MIME-Version: 1.0 X-Received: by 10.60.123.103 with SMTP id lz7mr10546765oeb.18.1403826665961; Thu, 26 Jun 2014 16:51:05 -0700 (PDT) Received: by 10.182.216.197 with HTTP; Thu, 26 Jun 2014 16:51:05 -0700 (PDT) In-Reply-To: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> Date: Fri, 27 Jun 2014 01:51:05 +0200 Message-ID: Subject: Re: Help With ASLR From: Oliver Pinter To: Shawn Webb Content-Type: text/plain; charset=ISO-8859-1 Cc: pageexec@freemail.hu, freebsd-hackers@freebsd.org, hunger@hunger.hu, kib@freebsd.org, alc@rice.edu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 23:51:07 -0000 CC PaXTeam, Hunger On 6/27/14, Shawn Webb wrote: > Hey All, > > I've exchanged a few helpful emails with kib@. He has glanced over the > ASLR patch we have against 11-CURRENT (which is also attached to this > email as a reference point). He has suggested some changes to the VM > subsystem that I'm having trouble getting my head wrapped around. > > Essentially, he suggests that instead of doing the randomization in > various places like the ELF loader and sys_mmap, we should modify > vm_map_find() in sys/vm/vm_map.c to apply the randomization there. > > Here's his suggestion in full (I hope he doesn't mind me directly > quoting him): > > The mapping address randomization can only be performed in the > vm_map_find(). This is the place where usermode mapping flags are > already parsed, and the real decision for the placement is done, with > all the contextual information collected, the fixed requests are not > passed there. Doing the 'randomization' in vm_mmap() means that the > mmap command must be parsed twice, which presented patch fails to do > in any sane way. Only mappings in the usermode maps should be > randomized. > > Current patch does not randomize the mapping location at all, it only > randomizes the hint address passed from the userspace, which is > completely useless. It also fails to correct the address to honour > the placement flags like MAP_32BIT or MAP_ALIGNMENT_MASK. What must > be done is vm_map_find() requesting vm_map_findspace() for the address > hole of the size of the requested mapping + (number of address bits to > randomize << PAGE_SHIFT). Then, the rng value should be obtained and > final location for the mapping calculated as return value + (rng << > PAGE_SHIFT). > > If no address space hole exists which can satisfy the enlarged > request, either a direct fallback to the initial length should be > performed (I prefer this), or exponential decrease of the length up to > the initial size done, and findspace procedure repeated. > > Also, the vm_map_find() knows about the superpages hint for the > mapping being performed, which allows to not break superpages. When > superpage-aligned mapping is requested, SUPERPAGE_SHIFT (available > from pagesizes[1]) should be used instead of PAGE_SHIFT in the formula > above, and probably, a different amount of address bits in the page > table page level 2 to randomize, selected. > === end of kib@ suggestions === > > I have a few concerns, though: > > 1) vm_map_find is also used when loading certain bits of data in the > kernel (like KLDs, for example); > 2) It's not possible to tell in vm_map_find if we're creating a mapping > for the stack, the execbase, or any other suitable mmap call. We apply > ASLR differently based on those three aspects; > 3) vm_map_find is also used in initializing the VM system upon boot. > What impacts would this cause? > > I would really appreciate any feedback. Thank you in advance for any > help or guidance. > > Thanks, > > Shawn >