[0/5] Some rtld-audit fixes

  This patchset fixes some rtld-audit issues brought by John
Mellor-Crummey [1] while trying to use it along with the HPCToolkit
tool.  This should cover the issues listed as 'Tier 1' [2], modulo
the aarch64 one, which I plan to address in a different patch set.

The first patch fixes a regression issue introduced by a
__libc_early_init() change.

The second patch is long-standing issue where the lazy resolution
trampolines are used even when the audit modules does not implement
the PLT or symbol binding callback.  The original patch from
Alexander Monakov is incomplete, since it also requires to take
la_symbind{32,64} in consideration.

The third patch add some tests to check if TLSDESC works along with
audit modules.

The forth patch fixes an issue when a dlmopen failure in a audit
module callback trigger an assert.

The final patch fixes another dlmopen failure when audit module
is used along with dlmopen.  This patch was proposed along with 
RTLD_SHARED support, so I added a regression test.

[1] https://sourceware.org/pipermail/libc-alpha/2021-June/127636.html
[2] https://docs.google.com/document/d/1dVaDBdzySecxQqD6hLLzDrEF18M1UtjDna9gL5BWWI0/edit#

Adhemerval Zanella (4):
  elf: Fix audit regression
  elf: Avoid unnecessary slowdown from profiling with audit (BZ#15533)
  elf: Add audit tests for modules with TLSDESC
  elf: Do not fail for failed dlopem on audit modules (BZ #28061)

Vivek Das Mohapatra (1):
  elf: Suppress audit calls when a (new) namespace is empty (BZ #28062)

 elf/Makefile                   |  44 +++++++++++-
 elf/dl-load.c                  |   7 +-
 elf/dl-open.c                  |   4 +-
 elf/dl-reloc.c                 |  13 +++-
 elf/rtld.c                     |   8 +--
 elf/tst-audit-tlsdesc-audit.c  |  23 ++++++
 elf/tst-audit-tlsdesc-dlopen.c |  67 +++++++++++++++++
 elf/tst-audit-tlsdesc.c        |  60 ++++++++++++++++
 elf/tst-audit17.c              |  25 +++++++
 elf/tst-audit18a.c             |  39 ++++++++++
 elf/tst-audit18b.c             |  30 ++++++++
 elf/tst-audit18bmod.c          |  22 ++++++
 elf/tst-audit19.c              |  25 +++++++
 elf/tst-audit20.c              | 128 +++++++++++++++++++++++++++++++++
 elf/tst-audit20mod.c           |  26 +++++++
 elf/tst-auditmod-tlsdesc1.c    |  41 +++++++++++
 elf/tst-auditmod-tlsdesc2.c    |  33 +++++++++
 elf/tst-auditmod17.c           |  24 +++++++
 elf/tst-auditmod18a.c          |  25 +++++++
 elf/tst-auditmod18b.c          |  48 +++++++++++++
 elf/tst-auditmod19.c           |  57 +++++++++++++++
 elf/tst-auditmod20.c           |  73 +++++++++++++++++++
 include/link.h                 |   2 +
 23 files changed, 810 insertions(+), 14 deletions(-)
 create mode 100644 elf/tst-audit-tlsdesc-audit.c
 create mode 100644 elf/tst-audit-tlsdesc-dlopen.c
 create mode 100644 elf/tst-audit-tlsdesc.c
 create mode 100644 elf/tst-audit17.c
 create mode 100644 elf/tst-audit18a.c
 create mode 100644 elf/tst-audit18b.c
 create mode 100644 elf/tst-audit18bmod.c
 create mode 100644 elf/tst-audit19.c
 create mode 100644 elf/tst-audit20.c
 create mode 100644 elf/tst-audit20mod.c
 create mode 100644 elf/tst-auditmod-tlsdesc1.c
 create mode 100644 elf/tst-auditmod-tlsdesc2.c
 create mode 100644 elf/tst-auditmod17.c
 create mode 100644 elf/tst-auditmod18a.c
 create mode 100644 elf/tst-auditmod18b.c
 create mode 100644 elf/tst-auditmod19.c
 create mode 100644 elf/tst-auditmod20.c
  

Adhemerval,

We are delighted to see your patches for the most troublesome problems (our Tier 1 issues) in glibc 2.34!! We look forward to installing a version of glibc with these patches soon and testing them.

In your email below, you mention that the ARM bugs are not fixed with this patch set and that they will be handled in a different patch set. Are you expecting that patch set to make it into 2.34 or not?
--
John Mellor-Crummey		Professor
Dept of Computer Science	Rice University
email: johnmc@rice.edu		phone: 713-348-5179

> On Jul 7, 2021, at 1:26 PM, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
> 
> This patchset fixes some rtld-audit issues brought by John
> Mellor-Crummey [1] while trying to use it along with the HPCToolkit
> tool.  This should cover the issues listed as 'Tier 1' [2], modulo
> the aarch64 one, which I plan to address in a different patch set.
> 
> The first patch fixes a regression issue introduced by a
> __libc_early_init() change.
> 
> The second patch is long-standing issue where the lazy resolution
> trampolines are used even when the audit modules does not implement
> the PLT or symbol binding callback.  The original patch from
> Alexander Monakov is incomplete, since it also requires to take
> la_symbind{32,64} in consideration.
> 
> The third patch add some tests to check if TLSDESC works along with
> audit modules.
> 
> The forth patch fixes an issue when a dlmopen failure in a audit
> module callback trigger an assert.
> 
> The final patch fixes another dlmopen failure when audit module
> is used along with dlmopen.  This patch was proposed along with 
> RTLD_SHARED support, so I added a regression test.
> 
> [1] https://sourceware.org/pipermail/libc-alpha/2021-June/127636.html
> [2] https://docs.google.com/document/d/1dVaDBdzySecxQqD6hLLzDrEF18M1UtjDna9gL5BWWI0/edit#
> 
> Adhemerval Zanella (4):
>  elf: Fix audit regression
>  elf: Avoid unnecessary slowdown from profiling with audit (BZ#15533)
>  elf: Add audit tests for modules with TLSDESC
>  elf: Do not fail for failed dlopem on audit modules (BZ #28061)
> 
> Vivek Das Mohapatra (1):
>  elf: Suppress audit calls when a (new) namespace is empty (BZ #28062)
> 
> elf/Makefile                   |  44 +++++++++++-
> elf/dl-load.c                  |   7 +-
> elf/dl-open.c                  |   4 +-
> elf/dl-reloc.c                 |  13 +++-
> elf/rtld.c                     |   8 +--
> elf/tst-audit-tlsdesc-audit.c  |  23 ++++++
> elf/tst-audit-tlsdesc-dlopen.c |  67 +++++++++++++++++
> elf/tst-audit-tlsdesc.c        |  60 ++++++++++++++++
> elf/tst-audit17.c              |  25 +++++++
> elf/tst-audit18a.c             |  39 ++++++++++
> elf/tst-audit18b.c             |  30 ++++++++
> elf/tst-audit18bmod.c          |  22 ++++++
> elf/tst-audit19.c              |  25 +++++++
> elf/tst-audit20.c              | 128 +++++++++++++++++++++++++++++++++
> elf/tst-audit20mod.c           |  26 +++++++
> elf/tst-auditmod-tlsdesc1.c    |  41 +++++++++++
> elf/tst-auditmod-tlsdesc2.c    |  33 +++++++++
> elf/tst-auditmod17.c           |  24 +++++++
> elf/tst-auditmod18a.c          |  25 +++++++
> elf/tst-auditmod18b.c          |  48 +++++++++++++
> elf/tst-auditmod19.c           |  57 +++++++++++++++
> elf/tst-auditmod20.c           |  73 +++++++++++++++++++
> include/link.h                 |   2 +
> 23 files changed, 810 insertions(+), 14 deletions(-)
> create mode 100644 elf/tst-audit-tlsdesc-audit.c
> create mode 100644 elf/tst-audit-tlsdesc-dlopen.c
> create mode 100644 elf/tst-audit-tlsdesc.c
> create mode 100644 elf/tst-audit17.c
> create mode 100644 elf/tst-audit18a.c
> create mode 100644 elf/tst-audit18b.c
> create mode 100644 elf/tst-audit18bmod.c
> create mode 100644 elf/tst-audit19.c
> create mode 100644 elf/tst-audit20.c
> create mode 100644 elf/tst-audit20mod.c
> create mode 100644 elf/tst-auditmod-tlsdesc1.c
> create mode 100644 elf/tst-auditmod-tlsdesc2.c
> create mode 100644 elf/tst-auditmod17.c
> create mode 100644 elf/tst-auditmod18a.c
> create mode 100644 elf/tst-auditmod18b.c
> create mode 100644 elf/tst-auditmod19.c
> create mode 100644 elf/tst-auditmod20.c
> 
> -- 
> 2.30.2
>
  

On 07/07/2021 16:02, John Mellor-Crummey wrote:
> Adhemerval,
> 
> We are delighted to see your patches for the most troublesome problems (our Tier 1 issues) in glibc 2.34!! We look forward to installing a version of glibc with these patches soon and testing them.
> 
> In your email below, you mention that the ARM bugs are not fixed with this patch set and that they will be handled in a different patch set. Are you expecting that patch set to make it into 2.34 or not?

Hi John,

It is unlikely that they will make into 2.34 because we in the slush freeze
that precedes the release and I haven't posted them previously. And they
most likely required a ldaudit version bump.  I am aiming for next 2.35
release.
  

Thanks for the clarification that the ARM patches will miss 2.34. That is what I expected.

Now I am a bit worried. Are your expecting the LD_AUDIT patches you posted today to make it into 2.34 or will they be delayed until 2.35 as well?
--
John Mellor-Crummey		Professor
Dept of Computer Science	Rice University
email: johnmc@rice.edu		phone: 713-348-5179

> On Jul 7, 2021, at 2:09 PM, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
> 
> 
> 
> On 07/07/2021 16:02, John Mellor-Crummey wrote:
>> Adhemerval,
>> 
>> We are delighted to see your patches for the most troublesome problems (our Tier 1 issues) in glibc 2.34!! We look forward to installing a version of glibc with these patches soon and testing them.
>> 
>> In your email below, you mention that the ARM bugs are not fixed with this patch set and that they will be handled in a different patch set. Are you expecting that patch set to make it into 2.34 or not?
> 
> Hi John,
> 
> It is unlikely that they will make into 2.34 because we in the slush freeze
> that precedes the release and I haven't posted them previously. And they
> most likely required a ldaudit version bump.  I am aiming for next 2.35
> release. 
>
  

actually, i am out july 17-30. schedule it the following week. the delay will not be a peoblem with the dept. 

(sent from my phone)

> On Jul 7, 2021, at 3:09 PM, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
> 
> 
> 
>> On 07/07/2021 16:02, John Mellor-Crummey wrote:
>> Adhemerval,
>> 
>> We are delighted to see your patches for the most troublesome problems (our Tier 1 issues) in glibc 2.34!! We look forward to installing a version of glibc with these patches soon and testing them.
>> 
>> In your email below, you mention that the ARM bugs are not fixed with this patch set and that they will be handled in a different patch set. Are you expecting that patch set to make it into 2.34 or not?
> 
> Hi John,
> 
> It is unlikely that they will make into 2.34 because we in the slush freeze
> that precedes the release and I haven't posted them previously. And they
> most likely required a ldaudit version bump.  I am aiming for next 2.35
> release. 
>
  

sorry. my reply went to the wrong recipients.

(sent from my phone)

> On Jul 7, 2021, at 8:09 PM, John Mellor-Crummey <johnmc@rice.edu> wrote:
> 
> actually, i am out july 17-30. schedule it the following week. the delay will not be a peoblem with the dept. 
> 
> (sent from my phone)
> 
>> On Jul 7, 2021, at 3:09 PM, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
>> 
>> 
>> 
>>>> On 07/07/2021 16:02, John Mellor-Crummey wrote:
>>> Adhemerval,
>>> 
>>> We are delighted to see your patches for the most troublesome problems (our Tier 1 issues) in glibc 2.34!! We look forward to installing a version of glibc with these patches soon and testing them.
>>> 
>>> In your email below, you mention that the ARM bugs are not fixed with this patch set and that they will be handled in a different patch set. Are you expecting that patch set to make it into 2.34 or not?
>> 
>> Hi John,
>> 
>> It is unlikely that they will make into 2.34 because we in the slush freeze
>> that precedes the release and I haven't posted them previously. And they
>> most likely required a ldaudit version bump.  I am aiming for next 2.35
>> release. 
>>
  

* John Mellor-Crummey via Libc-alpha:

> Now I am a bit worried. Are your expecting the LD_AUDIT patches you
> posted today to make it into 2.34 or will they be delayed until 2.35
> as well?

Let me approach this differently.  Why is the glibc 2.34 release
important to you?

To be honest, I expect whether the fixes land in glibc 2.34 or 2.35 has
little impact on when the changes land in the hands of your users.  So
far, everything looks backportable.  I'm aware of just one distribution
with long-term support that plans to use glibc 2.34 (Red Hat Enterprise
Linux 9), and given that there is a strong desire to have the changes in
Red Hat Enterprise Linux 8, we'd have to backport them to Red Hat
Enterprise Linux 9 if they aren't included in the glibc 2.34 release
proper.  (I'd consider a LAV_CURRENT bump backportable, too.)

Thanks,
Florian
  

Florian,

I’d like these fixes for a supercomputer being delivered in the fall. I have a discussion next week about getting a glibc that I need on the system. Having a version that I can name that will be finalized imminently will help with that. I don’t know anything about the glibc release schedule. When would you expect 2.35 to be finalized?

(sent from my phone)

> On Jul 8, 2021, at 2:26 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 
> * John Mellor-Crummey via Libc-alpha:
> 
>> Now I am a bit worried. Are your expecting the LD_AUDIT patches you
>> posted today to make it into 2.34 or will they be delayed until 2.35
>> as well?
> 
> Let me approach this differently.  Why is the glibc 2.34 release
> important to you?
> 
> To be honest, I expect whether the fixes land in glibc 2.34 or 2.35 has
> little impact on when the changes land in the hands of your users.  So
> far, everything looks backportable.  I'm aware of just one distribution
> with long-term support that plans to use glibc 2.34 (Red Hat Enterprise
> Linux 9), and given that there is a strong desire to have the changes in
> Red Hat Enterprise Linux 8, we'd have to backport them to Red Hat
> Enterprise Linux 9 if they aren't included in the glibc 2.34 release
> proper.  (I'd consider a LAV_CURRENT bump backportable, too.)
> 
> Thanks,
> Florian
>
  

* John Mellor-Crummey:

> Florian,
>
> I’d like these fixes for a supercomputer being delivered in the
> fall. I have a discussion next week about getting a glibc that I need
> on the system. Having a version that I can name that will be finalized
> imminently will help with that. I don’t know anything about the glibc
> release schedule. When would you expect 2.35 to be finalized?

It's scheduled for February 2022.

I agree that you need to talk to your software technology partner.  I
doubt they would want to use glibc 2.34 so closely after the upstream
release.  They will have to backport the fixes to their stabilized
environment.

Thanks,
Florian