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=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 4B9AD2A605 for ; Tue, 11 Jun 2024 19:13:43 +0200 (CEST) Received: (qmail 11762 invoked by uid 550); 11 Jun 2024 17:13:39 -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 11727 invoked from network); 11 Jun 2024 17:13:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718126011; x=1718730811; darn=lists.openwall.com; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8Gq8oLBRw7sVJdplTeE39Q8p3t73FmnBab2TTCuHLSU=; b=WDEMoBnk2LxjqUtPnkHrv96ScAVKVAt56uRb6SDCgueVlFY3gPXLq9GiDX0/czejKl XRZhwCvoQkt1jarnhsD887SUcfAQ3ziFBCofr0lrOS/WflzNu3Z2fB2JbtYjFajFcGRB trNj1oThrgdRrH/Wru9vt/Sh2p4KwvCyYpKFnW15T/U4BIWcvQHeR3PoaNqy3kTnn9z9 Lqpoh6B6a2h5Hpjc3khTe6gKfh1LNAaK2gWTtfUT1UoGRLywdNhqg3emVpawoNKQYPJ4 lGDLARj3GVIU76yTJcxRr5HUtMeuy8KaaazIocQxgtwp+bSi9p5j9ggDteIQE9R0aLaY 1alg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718126011; x=1718730811; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8Gq8oLBRw7sVJdplTeE39Q8p3t73FmnBab2TTCuHLSU=; b=umCBA2Tsj/DuaNvfWSzw6Cwllcl5hSLhrnUTzGNZr9aacpwSWap/nkpanLx94UWhVb BbG3ErFGHk/10PRxPZYenah2doRLLVtNPCPOKaHZ5qxhNXl/xhnQ1QBJEXhVu3t5t4uQ IeVpBdaY5xv76T1fJfaEuB3FCDCoGyXhe4vzgz4r+ULD0oxi4wzy084xIU0clnfOqHXY cVjhBbHRgqIFeXSYwePzyEHtHAkt21Cj/RTIBbkAa8GP/WP2/4Daw83tWJZjJjTIRmCd m7RPkQYtuEQDbuO9EnEomFAPWknWG+x/FUB4e+vUEghX+j3249resNrFt29NBaQlEuIZ hDdA== X-Gm-Message-State: AOJu0YxLpYiJfKzJ6QNp7iTxQQGS7llFfgl26MpGfvePYpe6vFfuKFOR VuC3dciiRmfh4+aibhFwe7JsfKNXX4SWEDWGsYLaBOJRiWmgwwnoLl6DOQRa X-Google-Smtp-Source: AGHT+IESQ6Iai68e2vkyQw6dFriBOOCIo2smFn1b3JePW91oXenx83KozZkzqOxC3AqVjNGXO9Mw3g== X-Received: by 2002:a05:600c:4507:b0:422:3da0:3ca3 with SMTP id 5b1f17b1804b1-4223da03f77mr27272245e9.34.1718126010400; Tue, 11 Jun 2024 10:13:30 -0700 (PDT) Date: Tue, 11 Jun 2024 20:13:28 +0300 From: Stefan Jumarea To: Rich Felker Cc: musl@lists.openwall.com Message-ID: 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=utf-8 Content-Disposition: inline In-Reply-To: <20240611164222.GQ10433@brightrain.aerifal.cx> Subject: Re: [musl] [PATCH] mallocng: Add MTE support for Aarch64 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. > > > > iirc i changed IB when i tried out mte with mallocng. > > > > > > > > i would avoid excessive ifdefs in the code, e.g. by using > > > > 'p = untag(p);' and define untag appropriately in a header. > > > > (this might as well do the tag checks when mte is enabled, > > > > Agree, will do. > > > > > > > > Yes. > > > > > > > but might need special-casing 0 sized allocations.) > > > > > > Zero-sized allocations could maybe be implemented as a wrong tag? But > > > then we'd need a way for free to let them pass untrapped. > > > > > > > Hm, a wrong tag seems like a nice idea, but I don't see an easy way to > > let the free pass untrapped. > > You'd need to be able to peek at the metadata and see that it's > zero-sized. > > > Can we do a special case and return NULL on > > zero-size allocations? > > Nope, that's not an option. While the standard allows it, it's awful > behavior and fundamentally inconsistent with how realloc works (null > return is ambiguous between failure to realloc, in which case old > object would still exit, and successful realloc to size zero, in which > case old object does not exist). I see, makes sense. Stefan