From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) by sourceware.org (Postfix) with ESMTPS id 8BF01386103A for ; Thu, 26 Nov 2020 15:51:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8BF01386103A Received: by mail-ot1-x343.google.com with SMTP id h39so2228125otb.5 for ; Thu, 26 Nov 2020 07:51:31 -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=Xw7Dom6OfkL4WPpP91hjD5s585v9pnsf0EEAx5S4Ubs=; b=Q9C0XL5h8f+5t/HtVPOmedthYVtcxpe4G+xnNEPrFi6p7t1zlS2TqEsGzRmf44DXsz sMhaV712hicVab5RHY13pUx1Sh/RP//TypxUBNb/D6HVtR2vDG/+To5Pbf0jDNFMzX/p e6AuwqCRd3+5yBgWMajeIGx+d0idXQSVxBE0gAFTob0qVrTijOhW3cgi/8Wa2K+sKI8h P9OXJ2wWUuD03mLoz1w4N0dqBQrS8c5DOAYuEeI3PlhRrp2W8z7yHZqfwzQ6CyReSqn1 vnRJ2oSZ1JFa0aqUDMdv3gUOpTipEfzIdYDfID3bLMD1JTXRWCl9opxgysYWiOKSFhrZ 6V+Q== X-Gm-Message-State: AOAM533/jyoAoxj5HA2gWq1hLd1I/tEZeHOrGXzj6M2ZlCIM7Ir1sD+B gCAGWqWSHmLnHX0Uzj4/T8j8xld6HGzm1ESRy9rcU+K8 X-Google-Smtp-Source: ABdhPJyelieF3yo2mYKSWCCqfCcvTHXTsIm45NZiBW1YufTFxG64JnqcYn8Q83DoPpPixsG0SXydyhK8cyNG5Ja+gbY= X-Received: by 2002:a05:6830:214c:: with SMTP id r12mr2696653otd.90.1606405890986; Thu, 26 Nov 2020 07:51:30 -0800 (PST) MIME-Version: 1.0 References: <20201123154236.25809-1-rearnsha@arm.com> <20201123154236.25809-3-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> In-Reply-To: <6173c59d-ee67-9499-ac61-c2dd37b56c67@foss.arm.com> From: "H.J. Lu" Date: Thu, 26 Nov 2020 07:50:54 -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: Thu, 26 Nov 2020 15:51:33 -0000 On Thu, Nov 26, 2020 at 7:48 AM Richard Earnshaw wrote: > > On 26/11/2020 15:27, Siddhesh Poyarekar wrote: > > On 11/26/20 7:45 PM, Richard Earnshaw wrote: > >> Sure, I can do that if you really think it's the right thing (I presume > >> this has already been done for other tunables on other architectures, so > > > > There's sysdeps/aarch64/dl-tunables.list too, so there's no additional > > plumbing needed... > > > >> that there isn't a lot of additional plumbing needed). But is it? It > >> seems odd to me that the generic malloc code would read a tunable that > >> only existed in a particular sysdep configuration. There has to exist > >> some mechanism for the machine independent code to know that the tagging > >> behaviour is needed. > > > > ... but I see your point. How about if we look at the patchset as > > follows, which should make it more clearer. It doesn't really change > > your patchset in any major way (other than fixing failures and review > > comments), it's only to make the story behind it and hence the design > > decisions more deliberate. > > > > The first part of the patchset (1-3) enables infrastructure to enable > > memory tagging in glibc. At the project level, this involves adding > > tagging calls (can't call them hooks because that name's taken and also > > invoke nightmares for some) in malloc to allow tagging malloc'd objects. > > The tagging calls are nops in the default case but support could be > > added either at the architecture level or in the form of a software > > implementation. > > > > The library could add more tag calls in other parts of the library to > > colour them library-internal (e.g. dynamic linker data, glibc internal > > data) but that's for later. > > > > This basically means that memory tagging becomes a library-wide concept > > and hence the glibc.mem.tagging tunable and configury should be > > implemented project-wide, i.e. the way you've done it with your v3 > > patchset with just the tunable naming changed. > > > > The second part (6-8, assuming 4 and 5 get subsumed into 3) of the > > patchset implements aarch64 architecture support for memory tagging. > > This involves enabling tagging for the entire process using prctl at > > startup and tagging malloc'd objects. It is unavoidable that tunables > > will eventually have processwide impact and not just in the library; > > there's precedent for that in x86 CET. > > > > What do you think? > > I think it's exactly the way the patch set was structured, I just wasn't > explicit in saying that :) > > > > > On a slightly different but related point, you may want to think about > > inheritance of the glibc.mem.tagging tunable when you work on v4, i.e.: > > > > 1. Should child processes inherit them? If you're modeling it along the > > lines of MALLOC_CHECK_ (i.e. diagnostics only) then you'd want to keep > > it as default, i.e. no inheritance. However if you model it as a > > hardening feature, you may want to set security_level to IGNORE so that > > children inherit tagging and forking doesn't become a way to escape > > tagging protections. > > > > 2. Should setxid children inherit enabled memory tagging? Again if > > you're modeling it as a hardening feature, then maybe you want to set > > security_level to NONE so that it is inherited by setxid children. I > > think it will be the first tunable to cross that boundary if you decide > > to take that route! > > > > A good question. I'd say at this point it's a bit more of a debugging > feature (at least until things have settled down); but longer term it > may well become a hardening feature as well. Before we can go down that > route, though we'll need to sort out how to mark binaries that are > genuinely incompatible with MTE. We already know that python's object > management code violates MTE assumptions, for example; either that will > need to be fixed, or we'll need a route to automatically disable MTE > when running programs like that. I think we need to address binary marking first before adding MTE to glibc. > So perhaps for now, we'd want to inherit it through normal fork() type > calls, but perhaps not for setxid at this stage, but we may want to > widen it later. On the other hand, for a security feature you'd perhaps > want a more robust (harder to turn off) mechanism than just modifying a > user-level environment variable. > > R. > > > Siddhesh > -- H.J.