From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20972 invoked by alias); 26 Mar 2013 11:12:43 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 20946 invoked by uid 89); 26 Mar 2013 11:12:36 -0000 X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 26 Mar 2013 11:12:33 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2QBCVWU025526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Mar 2013 07:12:32 -0400 Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r2QBCTa2022490 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Mar 2013 07:12:31 -0400 Message-ID: <5151829D.1040104@redhat.com> Date: Tue, 26 Mar 2013 11:12:00 -0000 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Caroline Tice CC: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Vtable pointer verification (corruption/attach detection -- new feature References: <5108F147.60307@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-03/txt/msg01056.txt.bz2 On 02/01/2013 12:42 AM, Caroline Tice wrote: >> If this data could be emitted in a >> declarative fashion, it might be possible to emit it by default, in a >> separate ELF section. This way, it is always there when needed, and it >> wouldn't have any performance impact if not used. > > That might be possible; it would need to be carefully organized > though. If is not enough to have a list of all vtable addresses; we > need to know, for each virtual class (where by virtual class I mean a > class for which a vtable might be generated) the set of vtables that > is is legal for an object of that class to point to (i.e. for a base > class, it can point to its own vtable or to the vtable of any of its > descendants in the inheritance hierarchy). At present, you emit calls to the __VLTRegisterPair() function to implement the registration, correct? I wonder if it's possible to list the arguments to the calls instead (possibly in such a way that no relocations are needed). Initialization for verification mode would pick up this data, performing the registration. Outside verification mode, this data would just be ignored (and no ELF constructor needs to be executed). >> C++ virtual method calls are efficient, but they have >> their problems. The vtable needs relocation (contributing to startup cost), >> and we have the fragile base class problem (which severely constrains the >> evolution of separately-compiled base classes). Assuming that we need the >> vtable check and it has non-trivial cost, it might make sense to revamp C++ >> virtual method dispatch altogether, addressing both security and modularity >> issues. > > That might be best, but we don't have the authority to unilaterally > make a change of this magnitude to the standard. ;-) This would only affect the cross-vendor C++ ABI, not the standard itself. -- Florian Weimer / Red Hat Product Security Team