From patchwork Thu Apr 28 19:21:52 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carlos O'Donell X-Patchwork-Id: 616390 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3qwmtB3Ycxz9t8j for ; Fri, 29 Apr 2016 05:22:10 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b=aVvXC5A0; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=LF/wpZQB1HmKFNgx fumr0xQ/KHBYedIs2la8kzAFL88dNGWo6/ZvJ/NBwPAvWypUjPWfwDoqoK62clcb 4HFRZvRDYMrtXmBgQhxWBkDh8xkVMDzme9eHkiH86cYl15cE8LYdhn1BJIdJfXHy i2TjPyycwglFesDmZKRH4sUBpYk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=xJ3vuz+1eyjRCSbuQiYNia JRMo4=; b=aVvXC5A0vAw8a7sk1D8cILn5oZeVCH4R5F3ieMlD6CazkYjUg5ScCa Xfq3jUQbgmAY2y/ydPtVZWksecdVSM3AIkLnHSnatAkOmDi8F0qFasKNu9aOJ3w1 quLKKm5n3ZOhnSSLYnBCwOWhyENHTxYji0ZsnCa0kheN5K+8LZbKU= Received: (qmail 52229 invoked by alias); 28 Apr 2016 19:22:03 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 52213 invoked by uid 89); 28 Apr 2016 19:22:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=958, 95, 8, HTo:U*drepper, activity X-HELO: mail-qg0-f52.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=rDZRNSUsmxBLoorlJ+dq8fYVBYrpyfqZkNsG64gkybc=; b=gr9oA/tLpc7KDC384NncC7je7fnVS4xKiODu7wu4oBZZ+ZX6qrL7te67tLumCXfxue 5Edmvs/H6tXfZYMtpuftv7tESN2DAjDoXIZSvmQ+SX5KsNPoBWSmrgYL0PPvRq55Mt+U MTJtAuxjPI8XNiox+BEcLIrLl6k+jwLEevd2xjwylAXG4mGg0ALPTERwM/yI4GsosNFC hBL92LaYz188eLcNNrQy0AzEjr/ewrX6/RELNFgSIBeiZ5m/20Uvs9P5JMBZrQbvunmU mrC44vkPoaERtLNIMT3Q0hXBsU/OwkEMbrzYGlTjaY2yvNOWMPXLLaCGm5gIwuhjLz3v ukZg== X-Gm-Message-State: AOPr4FVxxb5W67O/ZObtjWNRWG3pRJw/YhkK2bfudoiLo6GsFygeLqBbObd4jxsjl7Dk/vxj X-Received: by 10.140.145.82 with SMTP id 79mr16287536qhr.95.1461871316026; Thu, 28 Apr 2016 12:21:56 -0700 (PDT) Subject: Re: Library auditing interface stability? To: Florian Weimer , Ulrich Drepper References: <57169D19.2030109@redhat.com> <5721C7C2.1080805@redhat.com> Cc: GNU C Library From: Carlos O'Donell Message-ID: <572262D0.6050803@redhat.com> Date: Thu, 28 Apr 2016 15:21:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <5721C7C2.1080805@redhat.com> On 04/28/2016 04:20 AM, Florian Weimer wrote: > On 04/20/2016 04:24 PM, Ulrich Drepper wrote: >> On Tue, Apr 19, 2016 at 5:03 PM, Carlos O'Donell >> wrote: >>> In particular the La_*_regs and La_*_retval which contains >>> additional registers as we expand the supported ISAs. >> >> la_version is there to preserve unlimited backward compatibility. > > We have not used this mechanism when we added support for additional > registers to be passed to the PLT callbacks. Looking at commits > 14c5cbabc2d11004ab223ae5eae761ddf83ef99e and > 5cdd1989d1d2f135d02e66250f37ba8e767f9772, there is no way for an > audit module to notice if these additional fields are maintained by > glibc. I think we should have bumped the la_version number for all changes to the structure for any architecture. Do we fix this by bumping LAV_CURRENT? --- We can't fix audit modules in the field which return 1. We can fix newly compiled audit modules, making them expect a LAV_CURRENT of 3, such that they can't be run with older LAV_CURRENT 1 glibc which doesn't have BIND on x86 or VSX on s390? diff --git a/elf/link.h b/elf/link.h index f448141..cbf94a3 100644 --- a/elf/link.h +++ b/elf/link.h @@ -95,8 +95,13 @@ struct link_map #ifdef __USE_GNU -/* Version numbers for la_version handshake interface. */ -#define LAV_CURRENT 1 +/* Version numbers for la_version handshake interface. + 1 - Initial implementation. + 2 - Added lrv_bnd0 and lrv_bnd1 to La_i86_retval. + 3 - Added lr_v[24,25,26,27,28,29,30,31] to La_s390_64_regs, and + La_s390_32_regs. Added lrv_v24 to La_s390_64_retval and + La_s390_64_retval. */ +#define LAV_CURRENT 3 /* Activity types signaled through la_activity. */ enum