Message ID | 572262D0.6050803@redhat.com |
---|---|
State | Dropped |
Headers |
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: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> 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 <fweimer@redhat.com>, Ulrich Drepper <drepper@gmail.com> References: <57169D19.2030109@redhat.com> <CAOPLpQeV+hGcBZosGgN=8zZ9aycoFVG_BW9r9xDLQ4L0V8o=sA@mail.gmail.com> <5721C7C2.1080805@redhat.com> Cc: GNU C Library <libc-alpha@sourceware.org> From: Carlos O'Donell <carlos@redhat.com> 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> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit |
Commit Message
Carlos O'Donell
April 28, 2016, 7:21 p.m. UTC
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 >> <carlos@redhat.com> 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?
Comments
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 > >> <carlos@redhat.com> 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.
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 >>>> <carlos@redhat.com> 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. Cheers, Carlos.
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 > >>>> <carlos@redhat.com> 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? ...
On 05/05/2016 05:29 PM, Steven Munroe wrote: > 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 >>>>>> <carlos@redhat.com> 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? ... Library auditing has been in place since glibc 2.4 (2006-03-06). When architectures add new registers which are used in a procedure call they should also add them to the auditing interface (otherwise auditors can't inspect them) and they also need to be saved/restored to/from the auditing data structures. It might be a rare enough situation that nobody has noticed that those specific registers are not in the interface. Could someone from IBM audit sysdeps/powerpc/bits/link.h to see what's missing for ppc and ppc64?
On Fri, 2016-05-06 at 10:22 -0400, Carlos O'Donell wrote: > On 05/05/2016 05:29 PM, Steven Munroe wrote: > > 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 > >>>>>> <carlos@redhat.com> 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? ... > > Library auditing has been in place since glibc 2.4 (2006-03-06). > > When architectures add new registers which are used in a procedure call > they should also add them to the auditing interface (otherwise auditors > can't inspect them) and they also need to be saved/restored to/from the > auditing data structures. > > It might be a rare enough situation that nobody has noticed that those > specific registers are not in the interface. > > Could someone from IBM audit sysdeps/powerpc/bits/link.h to see what's > missing for ppc and ppc64? > I have reviewed sysdeps/powerpc/bits/link.h in the context of 1) Power Architecture® 32-bit Application Binary Interface Supplement 1.0 2) 64-bit PowerPC ELF Application Binary Interface Supplement 1.9 3) Power Architecture 64-Bit ELF V2 ABI Specification as well as current GCC usage. link.h matches PPC64 V1 and PPC64 V2 for both ABI and current practice. It is a close match to PPC32 practice but the ABI is more permissive for return values. This is primarily to support complex double on embedded PPC32 without FPRs. PPC32 using HW float would use the normal FPRs for complex return and so is not a concern for this API. Given the caveat above I think the this interface is stable for the 3 ABIs.
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