From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail6.bemta7.messagelabs.com (mail6.bemta7.messagelabs.com [216.82.255.55]) by kanga.kvack.org (Postfix) with ESMTP id CEE466B016F for ; Tue, 16 Aug 2011 05:06:39 -0400 (EDT) Received: by bkbzt4 with SMTP id zt4so4929221bkb.14 for ; Tue, 16 Aug 2011 02:06:36 -0700 (PDT) Date: Tue, 16 Aug 2011 13:05:40 +0400 From: Vasiliy Kulikov Subject: Re: [RFC] x86, mm: start mmap allocation for libs from low addresses Message-ID: <20110816090540.GA7857@albatros> References: <20110812102954.GA3496@albatros> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: "H. Peter Anvin" Cc: Thomas Gleixner , Ingo Molnar , kernel-hardening@lists.openwall.com, Peter Zijlstra , Andrew Morton , x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org On Fri, Aug 12, 2011 at 18:19 -0500, H. Peter Anvin wrote: > Vasiliy Kulikov wrote: > > >This patch changes mmap base address allocator logic to incline to > >allocate addresses from the first 16 Mbs of address space. These > >addresses start from zero byte (0x00AABBCC). ... To make it clear: The VM space is not significantly reduced - an additional gap, which is used for ASCII-protected region, is calculated the same way as the common mmap gap is calculated. The maximum size of the gap is 1MB for the upstream kernel default ASLR entropy - a trifle IMO. If the new allocator fails to find appropriate vma in the protected zone, the old one tries to do the job. So, no visible changes for userspace. As to the benefit: 1) For small PIE programs, which don't use much libraries, all executable regions are moved to the protected zone. 2) For non-PIE programs if image starts from 0x00AABBCC address and fits into the zone the same rule of small libs applies. 3) For non-PIE programs with images above 0x01000000 and/or programs with much libraries some code sections are outsize of the protected region. The protection works for (1) and (2) programs. It doesn't work for (3). (1) is not too seldom. Programs, which need such protection (network daemons, programs parsing untrusted input, etc.), are usually small enough. In our distro, Openwall GNU/*/Linux, almost all daemon programs fit into the region. As the changes are not intrusive, we'd want to see this feature in the upstream kernel. If you know why the patch cannot be a part of the upstream kernel - please tell me, I'll try to address the issues. Thanks, -- Vasiliy Kulikov http://www.openwall.com - bringing security into open computing environments -- 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: email@kvack.org