From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11200 invoked by alias); 5 May 2016 21:29:28 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 11188 invoked by uid 89); 5 May 2016 21:29:27 -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,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=VMX, Hx-languages-length:2580, H*Ad:U*drepper X-HELO: e33.co.us.ibm.com X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: munroesj@linux.vnet.ibm.com X-IBM-RcptTo: drepper@gmail.com;carlos@redhat.com;fweimer@redhat.com;libc-alpha@sourceware.org Subject: Re: Library auditing interface stability? From: Steven Munroe Reply-To: munroesj@linux.vnet.ibm.com To: "Carlos O'Donell" Cc: tulioqm@br.ibm.com, Florian Weimer , Ulrich Drepper , GNU C Library In-Reply-To: <572B6D65.1040502@redhat.com> References: <57169D19.2030109@redhat.com> <5721C7C2.1080805@redhat.com> <572262D0.6050803@redhat.com> <1462460184.9421.3.camel@oc7878010663> <572B6D65.1040502@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 05 May 2016 21:29:00 -0000 Message-ID: <1462483759.9421.6.camel@oc7878010663> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16050521-0009-0000-0000-000030B23CCC X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused X-SW-Source: 2016-05/txt/msg00091.txt.bz2 On Thu, 2016-05-05 at 11:57 -0400, Carlos O'Donell wrote: > On 05/05/2016 10:56 AM, Steven Munroe wrote: > > On Thu, 2016-04-28 at 15:21 -0400, Carlos O'Donell wrote: > >> 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? > >> > >> 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 > >> --- > >> > >> 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? > >> > > > > I am not sure if the audit modules need to now or care about PPC VSX or > > TAR, but if memory serves. VSX was added after the audit API. > > Is VSX or TAR part of the procedure call sequence? > > The La_*_regs structure allows an audit module to modify incoming > registers to the function using the PLT hook being provided by the > audit infrastructure. > Not VSX or TAR but VMX regs are, which GLIBC was library audit added? ...