* Library auditing interface stability? @ 2016-04-19 21:03 Carlos O'Donell 2016-04-20 14:25 ` Ulrich Drepper 0 siblings, 1 reply; 9+ messages in thread From: Carlos O'Donell @ 2016-04-19 21:03 UTC (permalink / raw) To: GNU C Library Do we care about the ABI and API stability of the library auditing interface? In particular the La_*_regs and La_*_retval which contains additional registers as we expand the supported ISAs. I think the answer is: The library auditing interface is only stable from release to release, and when a new release comes out you have to rebuild your auditor modules. Cheers, Carlos. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library auditing interface stability? 2016-04-19 21:03 Library auditing interface stability? Carlos O'Donell @ 2016-04-20 14:25 ` Ulrich Drepper 2016-04-28 8:20 ` Florian Weimer 0 siblings, 1 reply; 9+ messages in thread From: Ulrich Drepper @ 2016-04-20 14:25 UTC (permalink / raw) To: Carlos O'Donell; +Cc: GNU C Library 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library auditing interface stability? 2016-04-20 14:25 ` Ulrich Drepper @ 2016-04-28 8:20 ` Florian Weimer 2016-04-28 19:22 ` Carlos O'Donell 0 siblings, 1 reply; 9+ messages in thread From: Florian Weimer @ 2016-04-28 8:20 UTC (permalink / raw) To: Ulrich Drepper, Carlos O'Donell; +Cc: GNU C Library 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. Florian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library auditing interface stability? 2016-04-28 8:20 ` Florian Weimer @ 2016-04-28 19:22 ` Carlos O'Donell 2016-05-05 14:56 ` Steven Munroe 0 siblings, 1 reply; 9+ messages in thread From: Carlos O'Donell @ 2016-04-28 19:22 UTC (permalink / raw) To: Florian Weimer, Ulrich Drepper; +Cc: GNU C Library 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? -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library auditing interface stability? 2016-04-28 19:22 ` Carlos O'Donell @ 2016-05-05 14:56 ` Steven Munroe 2016-05-05 15:57 ` Carlos O'Donell 0 siblings, 1 reply; 9+ messages in thread From: Steven Munroe @ 2016-05-05 14:56 UTC (permalink / raw) To: Carlos O'Donell, tulioqm Cc: Florian Weimer, Ulrich Drepper, GNU C Library 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library auditing interface stability? 2016-05-05 14:56 ` Steven Munroe @ 2016-05-05 15:57 ` Carlos O'Donell 2016-05-05 21:29 ` Steven Munroe 0 siblings, 1 reply; 9+ messages in thread From: Carlos O'Donell @ 2016-05-05 15:57 UTC (permalink / raw) To: munroesj, tulioqm; +Cc: Florian Weimer, Ulrich Drepper, GNU C Library 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. -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library auditing interface stability? 2016-05-05 15:57 ` Carlos O'Donell @ 2016-05-05 21:29 ` Steven Munroe 2016-05-06 14:22 ` Carlos O'Donell 0 siblings, 1 reply; 9+ messages in thread From: Steven Munroe @ 2016-05-05 21:29 UTC (permalink / raw) To: Carlos O'Donell Cc: tulioqm, Florian Weimer, Ulrich Drepper, GNU C Library 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? ... ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library auditing interface stability? 2016-05-05 21:29 ` Steven Munroe @ 2016-05-06 14:22 ` Carlos O'Donell 2016-05-10 14:28 ` Steven Munroe 0 siblings, 1 reply; 9+ messages in thread From: Carlos O'Donell @ 2016-05-06 14:22 UTC (permalink / raw) To: munroesj; +Cc: tulioqm, Florian Weimer, Ulrich Drepper, GNU C Library 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? -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Library auditing interface stability? 2016-05-06 14:22 ` Carlos O'Donell @ 2016-05-10 14:28 ` Steven Munroe 0 siblings, 0 replies; 9+ messages in thread From: Steven Munroe @ 2016-05-10 14:28 UTC (permalink / raw) To: Carlos O'Donell Cc: tulioqm, Florian Weimer, Ulrich Drepper, GNU C Library 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-05-10 14:28 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-19 21:03 Library auditing interface stability? Carlos O'Donell 2016-04-20 14:25 ` Ulrich Drepper 2016-04-28 8:20 ` Florian Weimer 2016-04-28 19:22 ` Carlos O'Donell 2016-05-05 14:56 ` Steven Munroe 2016-05-05 15:57 ` Carlos O'Donell 2016-05-05 21:29 ` Steven Munroe 2016-05-06 14:22 ` Carlos O'Donell 2016-05-10 14:28 ` Steven Munroe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).