From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 6176E3858D28 for ; Fri, 5 Nov 2021 14:38:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6176E3858D28 Received: by mail-pl1-x62a.google.com with SMTP id t21so11204152plr.6 for ; Fri, 05 Nov 2021 07:38:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w7QAUsN3OoLgYJuAGBYC34XUJtp1Cz1AVAvV2fXttLY=; b=dn4OKkwzf+MqMsk20haLzlSc5pD117E5y3unP/KN5czvKzBQRcOwCJ1bs51ynMOHaP vIfT9T/+EOTO3VeuTM6owDhYyF1GmG15zmB+5zSPvwUPfIjsNDXubnf+Z5nOQ8TowOE+ h7Zzu+N6UuPmAUQvrf/kMmRRk/t1AjHZy2HYMaztU5nobKdBCzAU69wffT6ycTReNV7R vBOOWJDPtODDt7M6gao/xKckdAgn7/ZdgfqojGasLrh68flE5yH5S1liFuvKHgyvvsD0 6I5KxRBT4a7S08VDxRbM3BnetpPXngDAmo7wK0qPGbrCp+gL8MLE/clp+OaM7QXyqbVK iSjQ== X-Gm-Message-State: AOAM532yVNFDWYyit00tp6ZT438GWHOcD1dQVoDxQVmmBsj/la9P5XP4 jMm3XanROYe0MoSamrCQ9MoHPzMCgDlywWpKIMAPQk7J X-Google-Smtp-Source: ABdhPJyglFOicJa6kJC+1HTrpz7MohBPJsuEcfO8lNw3eXNnqPp5CQmtHaoQpKiNnbvsITWKJRPg/2pzCRULQ6MCtls= X-Received: by 2002:a17:90b:3a85:: with SMTP id om5mr31186154pjb.28.1636123094561; Fri, 05 Nov 2021 07:38:14 -0700 (PDT) MIME-Version: 1.0 References: <27f078539ae2a5b390705ac6fa1a7437ae8ce97c.1636120354.git.fweimer@redhat.com> <87r1buu10l.fsf@oldenburg.str.redhat.com> In-Reply-To: <87r1buu10l.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Fri, 5 Nov 2021 07:37:38 -0700 Message-ID: Subject: Re: [PATCH 2/2] elf: Detect PT_LOAD segments that extend beyond EOF and refuse loading To: Florian Weimer Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3023.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 14:38:17 -0000 On Fri, Nov 5, 2021 at 7:31 AM Florian Weimer wrote: > > * H. J. Lu: > > > On Fri, Nov 5, 2021 at 7:01 AM Florian Weimer via Libc-alpha > > wrote: > >> > >> We occasionally see elf/tst-debug1 failing with a SIGBUS error > >> with some toolchain versions (recently on aarch64 only). This test > >> tries to emulate loading separated debuginfo, but whether the test > >> object triggers the crash depends on many factors. Accurately > >> rejected separated debuginfo in dlopen probably needs ELF markup, > >> at least if this is to be done efficiently using program headers > >> only. But this change still improves user experience slightly. > >> We already obtain the file size from the kernel in most cases, > >> so no additional system call is added. > > > > Under what conditions does the test trigger SIGBUS? > > If the separated debuginfo object is shorter than the original object, > and the dynamic loader tries to access something in the load segment > that extends beyond the end of the file. I suspect triggering the > actual crash depends on placement of the dynamic segments and of > relocation targets. > > > Does your patch makes the test pass or just turn SIGBUS into a > > different failure? > > It makes the test pass because the dlopen reports the new error for this > particular error condition. Of course, the test can still crash due to > invalid data in the dynamic segment if we are unlucky. So dlopen should reject it. Can you identify the broken tools which generate such input files and black list them for this test? Of course, ld.so can improve sanity checks. But we need really broken inputs for such checks. -- H.J.