Message ID | 20210707182610.3940620-1-adhemerval.zanella@linaro.org |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 68A47396E43A for <patchwork@sourceware.org>; Wed, 7 Jul 2021 18:26:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 68A47396E43A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1625682398; bh=1vLlxUdCiwN8LzQt9h22bMzzth3MOb+YdSBal0hIcRQ=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=joktGvWkHfPzC2ZsAh0qrKZaDx5q/TdUNJ8orb1HzQ+YJ7es7d4VTUeTGV1KGky1Q C7k9m5j3xFSTbR9B9koQZtNEouU89xvYx3fTXPnz2CcPD/RNGkn99FLNCdLqFU16Le qnCvvE48dWTKddU8gbknkPJEdAbE4Aki9IOaDaBs= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id 03167386EC2F for <libc-alpha@sourceware.org>; Wed, 7 Jul 2021 18:26:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 03167386EC2F Received: by mail-pg1-x52c.google.com with SMTP id a2so3174258pgi.6 for <libc-alpha@sourceware.org>; Wed, 07 Jul 2021 11:26:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=1vLlxUdCiwN8LzQt9h22bMzzth3MOb+YdSBal0hIcRQ=; b=kNRjLcgF9D4Iise7+1O+rS/2PkZso13tXmnPSBqyj1+KeMcOYw/1CmhUfx8GEdc4Eq CxxO5ohFRep+sKm9SJvC4SeiWpO8H+8a+XxIF1KHlSkQnmh3N+JkVg6Xh2vZMFACo69k cg4j4CdtKl+hzxW23R+0l+KctF9QC1zqHHImv3Hmax+h1BOvzuaXir6XSbzZrs3y/YTj SvW5hn1+1d+knYQ/dOOnKa3X5z4cp99/+Xv0skp1w7SLOAiDGskUEFu3rabMMcY2o/Xy qcw5e/aweJg3E6Epmgq3LjXRU4H2jAbx7fhkqgYDWG+MxJxiZaHqw4sp7bAJumHq59av 4d9g== X-Gm-Message-State: AOAM533qG9zXCdTEdnDhGfMKjm0OFGitk2hfSrVieBcPyg7ON7wXO/sp sxiHLzmujEkWBm6KoERQItr+3Qy63dqxRA== X-Google-Smtp-Source: ABdhPJxKRRDyd53Fy3qKzvjjLD1q3PROEW9iuhfN7qOwfLaAjA9DK14tIvX1vIJh1xmq3pk90fwwOw== X-Received: by 2002:a05:6a00:26e6:b029:326:8d88:43e2 with SMTP id p38-20020a056a0026e6b02903268d8843e2mr3024039pfw.81.1625682375689; Wed, 07 Jul 2021 11:26:15 -0700 (PDT) Received: from birita.. ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id fv8sm18868662pjb.21.2021.07.07.11.26.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jul 2021 11:26:15 -0700 (PDT) To: libc-alpha@sourceware.org Subject: [PATCH 0/5] Some rtld-audit fixes Date: Wed, 7 Jul 2021 15:26:05 -0300 Message-Id: <20210707182610.3940620-1-adhemerval.zanella@linaro.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Adhemerval Zanella <adhemerval.zanella@linaro.org> Cc: John Mellor-Crummey <johnmc@rice.edu> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Some rtld-audit fixes
|
|
Message
Adhemerval Zanella
July 7, 2021, 6:26 p.m. UTC
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
Comments
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