Re: Library auditing interface stability?

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

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.