From owner-freebsd-arch@FreeBSD.ORG Sat Apr 19 01:23:31 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 988D0106564A for ; Sat, 19 Apr 2008 01:23:31 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.2.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7F68FC15 for ; Sat, 19 Apr 2008 01:23:31 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp8.server.rpi.edu (8.13.1/8.13.1) with ESMTP id m3J0MFF1031362; Fri, 18 Apr 2008 20:22:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <20080418165859.GD4840@obiwan.tataz.chchile.org> Date: Fri, 18 Apr 2008 20:22:13 -0400 To: Marcel Moolenaar , Jeremie Le Hen From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-RPI-SA-Score: undef - spam scanning disabled X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.228 Cc: freebsd-arch@FreeBSD.org Subject: Re: Integration of ProPolice in FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2008 01:23:31 -0000 At 11:46 AM -0700 4/18/08, Marcel Moolenaar wrote: >On Apr 18, 2008, at 9:58 AM, Jeremie Le Hen wrote: >>This should theorically work for all arch as, from what I've read, >>ProPolice takes place at the intermediate representation level of the >>compiler. This should therefore be architecture agnostic. > >The question is whether it will actually make a difference on ia64? > >The stack does not contain any of the "objects" that ProPolice >tries to protect from "stack-smashing" attacks, so what good is the >added overhead? On ia64 we have a large set of userland programs running C code. We run the same C code there which which we run on all other architectures. ProPolice will take a certain class of *actual* bugs in that C code, and turn those into fatal bugs on the platforms where ProPolice does work. By making those bugs much more visible on our high-volume platforms, it will also greatly increase the chance that someone will take the time to find and fix the *actual* bug. The bug in C. The bug in C code which we are running on ia64. Even if Propolice could never be made to work on ia64, the presence of it on other hardware platforms will benefit users on ia64. >>Basically, a "canary" is randomly chosen when the program starts (this >>part lives in libc). GCC inserts code in prologue and epilogue of all >>functions that contains a buffer of 8 or more bytes. In the prologue, >>the canary is pushed on the stack right after the return valued has been >>pushed, and this value is then checked in function epilogue. If the >>value in the stack has changed, there has been a buffer overflow > >The ia64 architecture has been designed to eliminate use of the >stack as much as possible for performance reasons. ProPolice does >add significant overhead for no good reason AFAICT. We can certainly have a different default for propolice/SSD support on FreeBSD/ia64 than we default to for other architectures. That is a very reasonable idea. I, for one, am very interested in Propolice support in FreeBSD, at least as an easy-to-set option. By that I mean: I don't mind what the default is, just as long as there is an easy and safe way to specify that you want propolice support at buildworld time. Right now we're in a situation where someone can specify it by making a few updates, but then that person is *really* screwed if they lose the updates by mistake. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA