From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +A52LTNBpmAbVQAAWB0awg (envelope-from ) for ; Thu, 20 May 2021 07:00:03 -0400 Received: by simark.ca (Postfix, from userid 112) id AA8CB1F11C; Thu, 20 May 2021 07:00:03 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 918071E813 for ; Thu, 20 May 2021 07:00:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D82DA3950C01; Thu, 20 May 2021 11:00:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D82DA3950C01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1621508401; bh=U1xhnBCW0qVn+rIpLl4h20G9hEY4MpQjiKtLus+MoOk=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=k+1s/l4LgPBhFa1E8RkEE/HowtKNdXOepma9xSDAq3qnXbqafwRsoRXzyXYTyXQrg 9xXp1KMirg9MzTBq5H6GS36nkXLFuSfkHC4Gw2H7Z5sdaVP2vgs1UyRXORQ5bJq+04 8dGg1T2CireZqeFvM9DgYgDBuEuDQX1BhjTwgRes= Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by sourceware.org (Postfix) with ESMTPS id 5DC9C389852E for ; Thu, 20 May 2021 10:59:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5DC9C389852E Received: by mail-qk1-x733.google.com with SMTP id k127so15635812qkc.6 for ; Thu, 20 May 2021 03:59:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=U1xhnBCW0qVn+rIpLl4h20G9hEY4MpQjiKtLus+MoOk=; b=gunxUowURLjk95lhffNYczjMygqRyMqYtBlMPtTQBY/gwX7oKqVAcM6p1ekN/hCZx3 e/y4zhRmL9KeQRuvEUz1erL/9g4CvfatqQWz+RD69/mv1FSbaEXu1vgXct9ehbHlo7bp lEymgdiLMAANJihxP1VIkdgUq2giphnPqDeI2U1jM1pdHSKgMydByQE2ez5nxkjHJyHQ T0asoT0cflm+e8qhF0kIYotFxN19oO+ZvQihA8FkOn8XkqjhCKtGxvDyVA9jn3vag5Ul bca4IbJG5NU4Vy4pBneyEV2sgNmwQK2Kb86Tc2ac8dMRBl0kVaU/2xLbAArs1tvz8ceQ kw5g== X-Gm-Message-State: AOAM530nMU8jIdw1QeIuyFbe8QCFp27u9bcxrghq4KoUvtd+DP87ou80 7Uu3pu5IG5IPLNYXBuTk4z6Epg== X-Google-Smtp-Source: ABdhPJwm+xipGzzKUGz81yA2gqaukFMsyJybQTUvXJIBuAK529sDEXALlvJTLBNLGLMZ8p09/rNhiQ== X-Received: by 2002:a37:270d:: with SMTP id n13mr4253988qkn.146.1621508398915; Thu, 20 May 2021 03:59:58 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:40ad:7d01:76a7:460e:59bb? ([2804:7f0:4841:40ad:7d01:76a7:460e:59bb]) by smtp.gmail.com with ESMTPSA id s11sm1619385qti.6.2021.05.20.03.59.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 May 2021 03:59:58 -0700 (PDT) Subject: Re: [PATCH] [AArch64] Sanitize the address before working with allocation tags To: Alan Hayward References: <20210518201953.3491983-1-luis.machado@linaro.org> <59E75A3D-8F25-4E34-AFF9-1EAD2F51B9FC@arm.com> Message-ID: <163b00bd-eb75-6e1d-4840-602b8aceed8b@linaro.org> Date: Thu, 20 May 2021 07:59:54 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <59E75A3D-8F25-4E34-AFF9-1EAD2F51B9FC@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Luis Machado via Gdb-patches Reply-To: Luis Machado Cc: nd , "gdb-patches\\@sourceware.org" Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 5/20/21 5:38 AM, Alan Hayward wrote: > > >> On 18 May 2021, at 22:20, Luis Machado via Gdb-patches wrote: >> >> On 5/18/21 5:33 PM, Simon Marchi wrote: >>> On 2021-05-18 4:19 p.m., Luis Machado via Gdb-patches wrote: >>>> Remove the logical tag/top byte from the address whenever we have to work with >>>> allocation tags. >>> Can you explain a bit more why this is needed? What down the line >>> doesn't like to receive an address with a logical tag? >> >> We shouldn't be passing an address with a non-zero top byte (or tag) to a ptrace request, for example. It may work (in fact, it works) but we are not supposed to rely on it. So we sanitize the pointer before it gets to fetch_memtags/store_memtags. >> >> This is clarified in the AArch64 Tagged Address ABI document (https://www.kernel.org/doc/html/latest/arm64/tagged-address-abi.html). >> >> In an upcoming patch to support memory tags in core files (https://sourceware.org/pipermail/gdb-patches/2021-May/178973.html), this address also gets passed down to the core target's fetch_memtags implementation. It needs to compare addresses, so it doesn't make sense to let through an address with a non-zero top byte, or else we risk not having a match due to differences in the upper byte. >> > > > Would it make sense to put the address_significant() at the beginning of aarch64_mte_get_atag()? > That’d ensure any future code that calls aarch64_mte_get_atag() is safe too. And it would mean the higher functions are dealing with a single address throughout. Yes and no. I didn't want to pollute aarch64_mte_get_atag by passing gdbarch just to be able to call address_significant. Alternatively, we could just remove the top byte by hand without using address_significantm, since we're within the AArch64 target anyway. > > Alternatively, it could even move down into target_fetch_memtags() instead (same with target_store_memtags), but I’m less keen on that. Yes. I considered that, but all the implementations would have to sanitize the address. We don't know what kinds of targets will want to implement those functions, so we can't safely assume they want to strip the top bytes. And, again, we'd need to pass/fetch the gdbarch from within the native layers just so we can call address_significant. > > > Alan. >