From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 16A3C2B1D1 for ; Tue, 11 Jun 2024 21:39:47 +0200 (CEST) Received: (qmail 11302 invoked by uid 550); 11 Jun 2024 19:39:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11266 invoked from network); 11 Jun 2024 19:39:43 -0000 Date: Tue, 11 Jun 2024 21:39:33 +0200 From: Szabolcs Nagy To: Stefan Jumarea Cc: Rich Felker , musl@lists.openwall.com Message-ID: <20240611193933.GH3766212@port70.net> Mail-Followup-To: Stefan Jumarea , Rich Felker , musl@lists.openwall.com References: <20240610123624.305051-2-stefanjumarea02@gmail.com> <20240611140922.GF3766212@port70.net> <20240611144624.GP10433@brightrain.aerifal.cx> <20240611164222.GQ10433@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [musl] [PATCH] mallocng: Add MTE support for Aarch64 * Stefan Jumarea [2024-06-11 20:13:28 +0300]: > On Tue, Jun 11, 2024 at 12:42:22PM -0400, Rich Felker wrote: > > On Tue, Jun 11, 2024 at 06:37:11PM +0300, Stefan Jumarea wrote: > > > On Tue, Jun 11, 2024 at 10:46:25AM -0400, Rich Felker wrote: > > > > On Tue, Jun 11, 2024 at 04:09:22PM +0200, Szabolcs Nagy wrote: > > > > > * Stefan Jumarea [2024-06-10 15:36:25 +0300]: > > > > > > This was done since MTE has a 16 byte granule for tagging. > > > Makes more sense to do this where the class is selected, yes. I'm not > > > sure about making it work for smaller allocations, I'll try to think of > > > a way to cover that. > > > > Is there any way to perform a "load, ignoring tag mismatch" operation? > > > > Yes, there is the `ldg` instruction that can load the tag of a given > address, so we can use that. > there is no atomic load with tag ignored. ldg+ld works if you know the memory tag cannot change asynchronously. writing to the tco register can disable (and then enable) tag checks (see the linux docs). i think it's a bad idea to share the same 16byte granule between user allocation and in-band malloc meta data for the next allocation, the two can be independently freed and thus the tag of the granule can change asynchronously when accessed. and using tco to access the in-band data might have overheads. moving the in-band meta data to another granule is imho the right solution but it costs more space than the compact mallocng design.