From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54798 invoked by alias); 22 Mar 2018 16:07:04 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 54779 invoked by uid 89); 22 Mar 2018 16:07:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-oi0-f41.google.com Received: from mail-oi0-f41.google.com (HELO mail-oi0-f41.google.com) (209.85.218.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Mar 2018 16:06:56 +0000 Received: by mail-oi0-f41.google.com with SMTP id u141-v6so7809610oif.1 for ; Thu, 22 Mar 2018 09:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t5ldZaQikBWrLouoxsjg38aSfI76pmTr7inqRh4YtzQ=; b=gy+ud30YoW3/hF+K4ZzSHoCVpsOJu4DPhhTyuQAV1cUcT3jwr6rMwjPi3nRisjVUdo LviBwJSPgzHMH/ejQ/8Gh7yZciq8ErWU20pO+H9OEgP8WuqXncAJn1oAKxTiHf5FmOMY KKSVZnsHgRvuvWojntG6/TXh2UDsJBX645I4VtOT3DfbbVOZOwago28S/RXUQPqDFR4x 7txw2DqEnabg2NrDF+bMmbvShludg5h2U5w2i/ZmJE/6EKLsvh8qYatLDN/TVPJM/LlX 80cccTupFyzcU3K/674khzibNIgS6SzptMCoHauRavSDXx7Fi2ZZwILMvC90qfyLoLrm /RxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t5ldZaQikBWrLouoxsjg38aSfI76pmTr7inqRh4YtzQ=; b=DlO5b33JGI6pwMmY4XfQdi7axTa1HwyVFi7tXDarT1foPT878BUrAa1zxpYTCKTrmp P93IKP/wXGis/9ROBUyfZRh7hwOFYnkXwUnNj/jGxgJ28+fUDz36Ye6NnIIOMHr3jd7o TN7+QeiiUbsD4AzwYIyK5aIiadQMufpeCvSyzyQUE6HTaSVRpHKA3b+yPkT762xWRi8P PXtSelMIO6TKmwglH2wkoxwxl4Z91aiFB5Eo+739oTNvpuuniDxKxtvRkWNU5escl8jr dfIui+xgAxZj4g2vUQ7MoV+kTO7diosViWM5JLsBocbJ8ciPYjpZ601FIhdzNsLa0xqE oy9A== X-Gm-Message-State: AElRT7G1gbfff+Lnxkr8H+iImLPDh4kcadPOBC/JHHXPLJdxAboZOntO wmdWdCYx65NmJkIOzLaNyVrssV9ZZhoy2Tq3y6s= X-Google-Smtp-Source: AG47ELu9SC3ADDwn64D7I3tymClKvKtD64JQ1oPOwSmKhfPMYHbvN4oohV7KjK0dFB3+ZHLEpXN602hZMAyt0tdQq2s= X-Received: by 10.202.195.141 with SMTP id t135mr13903804oif.311.1521734815056; Thu, 22 Mar 2018 09:06:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.10.20 with HTTP; Thu, 22 Mar 2018 09:06:54 -0700 (PDT) In-Reply-To: References: <20180317133115.GA4681@gmail.com> From: "H.J. Lu" Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Audit external function called indirectly via GOT To: Generic System V Application Binary Interface Cc: "Carlos O'Donell" , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00021.txt.bz2 On Thu, Mar 22, 2018 at 9:02 AM, Cary Coutant wrote: >>> My suggestion was that the GOT entry could be statically initialized >>> by the linker to point to the provisional PLT entry, rather than >>> forcing the dynamic loader to go through all this messy computation. >>> If auditing is not enabled, it would process the GLOB_DAT relocation >>> normally, and set the GOT entry to point to the actual function, >> >> elf_machine_plt_address in my glibc patch: >> >> https://github.com/hjl-tools/glibc/commit/aa8f2f5b9f395769f30d776649a11c2a045dd9e2 >> >> has >> >> if (__glibc_unlikely (GLRO(dl_naudit) > 0) >> && map->l_info[ADDRIDX (DT_GNU_PLT)] >> && map->l_info[DT_JMPREL] >> && ELFW(ST_TYPE) (refsym->st_info) == STT_FUNC) >> { >> Find the matching JUMP_SLOT relocation. >> } >> else >> Use the original resolution. >> >> If LD_AUDIT is unused, the whole thing is skipped. >> >>> bypassing the provisional PLT and PLTGOT entries completely. If >>> auditing is enabled, it could simply ignore the GLOB_DAT relocation >>> (or, if the binary is PIE, it could process it as a RELATIVE >>> relocation), and the -fno-plt calls will end up jumping to the >>> provisional PLT entry. >>> >>> (This is already how we handle the PLTGOT entries: the linker >>> statically initializes the entries to point to part (b)* of the PLT >>> entry, while putting JUMP_SLOT relocations for those entries into the >>> JMPREL table.) >>> >>> I think if you do that, none of these extra dynamic table entries will >>> be needed, except for the IGNORE_JMPREL flag that indicates there are >>> no JMPREL slots other than those for the provisional PLT entries. How >>> useful is that flag? If the final program has even one external call >>> that was *not* compiled with -fno-plt, you won't be able to set it. >>> Would it be better to partition the JMPREL and PLT tables into >>> "regular" and "provisional" entries? That would take just a single new >>> DT_PROVISIONAL_JMPREL entry to tell the dynamic loader where the >>> JMPREL entries for the provisional PLT entries begin; it can ignore >>> everything past that point when auditing is turned off. >> >> These new dynamic tags are used to compute PLT offset from GOT offset. >> See elf_machine_plt_address in my patch. > > Kinda reminds me of "These go to 11." > > What I'm suggesting eliminates the need for the dynamic loader to > compute the PLT offset from the GOT offset, and therefore eliminates > the need for all these additional DT entries. > >>> I suppose you may also want to partition the GLOB_DAT relocations, so >>> that the dynamic loader can easily figure out which ones to ignore >>> when auditing is enabled. That would take another dynamic table entry. >>> >>> Now, why do we need both the regular GOT entry and the provisional >>> PLTGOT entry? If the program is linked with -z relro and lazy binding, >>> you can put the GOT entries in the RELRO segment, and the PLTGOT >>> entries in writable data. That gives you the security when auditing is >>> turned off, and the ability to dynamically patch the PLTGOT when it's >>> turned on. In any other case, however, I see no reason to have both. >>> If you get rid of the GOT entry, and have the point of call jump >>> indirectly through the PLTGOT entry, which is initialized to point to >>> part (b) of the PLT entry, everything should work the same as without >>> -fno-plt. Essentially, all -fno-plt would do is inline part (a) of the >>> PLT entry. >> >> I want to use both so that GOT is read-only after relocation in >> normal case and the writable PLTGOT is only used for LD_AUDIT. > > But if the program isn't linked with relro, the PLTGOT entries remain > writable and you have no need for both. If it's linked with immediate > binding and relro, the PLTGOT entries become relro, and again you have > no need for both. The only case where you can make an argument for > both is when the program is linked with both relro and lazy binding. > But I don't see why you need the additional security if you're not > bothering to link with immediate binding. > On Linux, -z relro is the default. With -fno-plt, lazy binding is off. That is why I need both GOT and PLTGOT. Since PLTGOT is usually unused, the writable PLTGOT isn't a security issue. -- H.J.