From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) by sourceware.org (Postfix) with ESMTPS id 6F57B3972C0E for ; Fri, 27 Nov 2020 14:54:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6F57B3972C0E Received: by mail-ot1-x341.google.com with SMTP id n11so4931262ota.2 for ; Fri, 27 Nov 2020 06:54:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xRtm0IseAci4KrZaLXDXGfObbLgyCtFPQ7NTt2AAzoU=; b=nPB8owaQlSwhIY7bWhBe4kMGSkSM2+dHDh9JLe7MhBNVHyw+TObxe+UfyL0NBawbwX 9zDJoH4N07ykledFpD/1vN+Jb9N3ugtSvhfWXokdyhDIBYkPFJJetyfYzTv1dwidLMw1 1JTtIlqdIWVsjRU43LNxvubkfn3fXhDOXdgJHv67NLYe7+Xoi9Tr8zpw90RHu4geq0mg ROf70jw6LX/JM+fqHRL+ztm5DyihYb8OyaUsIT70SOOL0oT/8/oSvZKpV1HcfNP9n0lU EpejNadS2Drw7cki1CjXUKT6Ksq0T4lgc7CN32lnP5O9/o02aaSy16xPUaF8wHE1oi5T 0roQ== X-Gm-Message-State: AOAM5319hJZ2j8o4k2lAFOJPAnH8ogAop3XmfhAzkQEqeWbhJB6xIqps h+eCEpf9H+/duLdHlSLZ0G0dYcvfkr78SZum/ZA= X-Google-Smtp-Source: ABdhPJw1bp/OOEaBbM2udqblw/tUJnT4aVTxsCjgBa/1/346Pq6HYsEqzf7ic2Sr5m8PaqD0ol+p8H/6Yam1mPKUlkE= X-Received: by 2002:a05:6830:214c:: with SMTP id r12mr6281878otd.90.1606488897678; Fri, 27 Nov 2020 06:54:57 -0800 (PST) MIME-Version: 1.0 References: <20201123154236.25809-1-rearnsha@arm.com> <378cba09-12c1-59de-578a-1ca3a84015c5@foss.arm.com> <2a2cbd34-8dbc-34af-c5ee-b7d0ef5b48a7@gotplt.org> <26b8b11e-919a-b6e0-ff5f-51e724faffb2@foss.arm.com> <8ddb9604-5a6d-a656-0585-57a1b26c39f6@gotplt.org> <87e8b15f-8c86-4b2c-a5e4-3e70631ea505@gotplt.org> <23a8ad00-a376-48ae-cc6a-2684261146a1@foss.arm.com> <6173c59d-ee67-9499-ac61-c2dd37b56c67@foss.arm.com> <1938dee9-f8e5-ca9a-8f28-efb3ac91bf61@gotplt.org> <23462613-48c0-9fdf-aa89-18c98d9c6656@gotplt.org> <70937aae-cb56-50ad-dd1d-7e6b335ac927@gotplt.org> <605f0816-8a64-1d64-044a-beb5c5ca37bd@foss.arm.com> <74b5295e-2c12-adc1-d27f-342b9b20d84e@gotplt.org> In-Reply-To: From: "H.J. Lu" Date: Fri, 27 Nov 2020 06:54:21 -0800 Message-ID: Subject: Re: [PATCH v3 2/8] elf: Add a tunable to control use of tagged memory To: Richard Earnshaw Cc: Siddhesh Poyarekar , GNU C Library , Richard Earnshaw Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3030.0 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 27 Nov 2020 14:54:59 -0000 On Fri, Nov 27, 2020 at 4:24 AM Richard Earnshaw wrote: > > On 27/11/2020 11:27, Siddhesh Poyarekar wrote: > > On 11/27/20 4:10 PM, Richard Earnshaw wrote: > >> I think that's backwards. The default should be to assume that a binary > >> supports tagging and it should only be disabled if the binary explicitly > >> says that it is incompatible. > > > > Sorry, I assumed an opt-in marker. However opt-in marker being absent > > doesn't really say that the binary does not support tagging, it defers > > the decision to the tunable. > > > >> Requiring a tag to be set before you enable tagging will > >> a) Force a complete recompile of all binaries > > > > Binaries shouldn't be needed to be rebuilt to enable tagging; the > > tunable can do that. If you want distro-wide support for tagging, you > > enable the tunable by default and use the environment variable to opt out. > > > >> b) Result in binaries being incorrectly marked as tagging compatible > >> when they aren't (because they won't really be audited until they start > >> failing). They will then have to be rebuilt again without the tag. > >> > >> Given b) it then seems obvious that the right way to do this is just to > >> mark binaries that are known not to work; after they've been audited to > >> make sure that the reason they don't work is legitimate. > > > > With tunable enabled by default, an opt-out marker makes sense because > > then you only rebuild and mark binaries that don't work with tagging and > > have them opt out. > > > > From a distribution perspective, this could be done in two phases: > > > > 1. Phase 1 where you ave the tunable which is disabled by default and no > > marker present. This makes tagging available to those who want to opt-in > > > > 2. Phase 2 is where the tunable is now enabled by default and can be > > overridden with an opt-out marker. Running this opt-out binary on the > > older version is safe (and shouldn't need an ABI bump) since tunables > > are disabled by default. > > > > Does that make sense? If not then I'd really like to see a more > > detailed description of how you intend to roll this out. > > > > Siddhesh > > Yes, you've captured my thoughts and summarised it better that I was > doing myself. Thank you. > We need a plan for binary marker first. -- H.J.