From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 570601F8C6 for ; Tue, 17 Aug 2021 12:54:31 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 50273382D83A for ; Tue, 17 Aug 2021 12:54:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 50273382D83A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629204869; bh=mzM3c5z+9jzCM/QigGIBI5zgfYkyIbMuAFuNiPWLQdM=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=O2zK6pgyb9SOPrj3v5zxKxCjD7WAkB/kBFpN2n+veAgg5xQOhgb0u9+tU3x/vf7b2 dQM1GL4B4C3nH55hlOkSmjQMuvPSA8LfPs9p6a6d8qRSyevgQ7aFjFMxQeRsi5puKw +IzDDMw2LOvHLADjGp8tOjPAFGW1zrQQBvLBuz38= Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 7058F3853C16 for ; Tue, 17 Aug 2021 12:54:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7058F3853C16 Received: by mail-pl1-x632.google.com with SMTP id l11so24793959plk.6 for ; Tue, 17 Aug 2021 05:54:10 -0700 (PDT) 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=mzM3c5z+9jzCM/QigGIBI5zgfYkyIbMuAFuNiPWLQdM=; b=ogjTQGCRPf9746HIx4MLVv3KdOAHWAmB5jsRkUnlGJyVQZe3ZmTcWhayTkaUjrMWKs hakxO6307kevSlz1sz7B73YuoYzHiCwgDAbNxHE1s16WhgquL/2CBoR137lpUZqswl8s oIjvXP6TNAGGQaIlQQ24p52UY8UB7HnwHErmiBsdzkVvJDP6rj9LYuH7zFxdgD+pkUwU 96WUq0M73OeMvR8i4F72CRo+j21SjVOJWftzyQp1iEKve1Qten2GqrZUxsAvgKxz9EY5 6mCH32Abm82eotP3bOnq/r1g0bUsbKeBStVxP2qvPrzmyHLGPihhcbh8rjogOaQzavw4 OAjA== X-Gm-Message-State: AOAM531RnOYr5Ww+0sK6vbwa29daBjlQQAnIIkUrh0KZN6kNlbdons0o 61WUzZuOAShnFOUHXF5i1SMwTtAABd10PSQRshk= X-Google-Smtp-Source: ABdhPJwtoLi0ufEBL9HBv037VoHDXWHaVkO2f6myIizclzyNnkO9Ak+C1TsFiIOg0P2faWOth3Z94+NDrCta2n/jEOA= X-Received: by 2002:a17:90b:14c3:: with SMTP id jz3mr3489004pjb.153.1629204849282; Tue, 17 Aug 2021 05:54:09 -0700 (PDT) MIME-Version: 1.0 References: <20210805131358.300475-1-hjl.tools@gmail.com> <20210805131358.300475-2-hjl.tools@gmail.com> <87bl63giup.fsf@oldenburg.str.redhat.com> <20210812120115.GN20410@arm.com> <20210817123258.GF25257@arm.com> In-Reply-To: <20210817123258.GF25257@arm.com> Date: Tue, 17 Aug 2021 05:53:32 -0700 Message-ID: Subject: Re: [PATCH v5 1/1] : An API for tagged address To: Szabolcs Nagy Content-Type: text/plain; charset="UTF-8" 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: , From: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: Florian Weimer , GNU C Library , "Kirill A . Shutemov" , Joseph Myers Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Tue, Aug 17, 2021 at 5:33 AM Szabolcs Nagy via Libc-alpha wrote: > > The 08/12/2021 13:01, Szabolcs Nagy via Libc-alpha wrote: > > The 08/12/2021 10:36, Florian Weimer wrote: > > > I still don't see a way how we can split tag address bits used by the > > > implementation (glibc, sanitizers) and the application. > ... > > so one approach is to just disallow user tags, only sanitizer > > and similar tools can tag (and i think hwasan can coordinate > > with glibc via less formal api/abi that we can change later) > > to expand on this: i think we should just focus on the hwasan > use-case. there may be other use-cases for tagged addresses, > but we need more experience before we can design a generic api. > hwasan can just poke at implementation internals and have > target specific logic for now. Agreed. My motivation is hwasan. > allowing application code to use the tag bits can break c > semantics and compiler assumptions too easily. > > and we should not require hwasan to use libc apis to work > with tagged addresses, that would slow it down. There is no reason why a libc API should be slow. Currently, LAM enabled libsanitizer/hwasan has #include bool lam_failed = set_tagged_address_mask (TAGGED_ADDRESS_MASK (57)) We only need this function to enable LAM in libsanitizer/hwasan and inform glibc that LAM is enabled. The rest of functions in are used to make memmove and memmove tests LAM compatible. We can move them to internal header files. > so i think we don't need the tagged address representation > related apis. we may need something __hwasan_init can call > to set up os support. on aarch64 that's a prctl now, but a > libc api would allow us to disable hwasan from glibc (e.g. > if there are elf markings for incompatible dsos), i don't set_tagged_address_mask can be used to enable and disable LAM/TBI. memmove needs to know if LAM/TBI is enabled or not to work correctly. > know if that makes sense (does hwasan have a fall back if > there is no os support?). > It is a hard error for hwasan if LAM/TBI isn't available. Thanks. -- H.J.