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 7315A2B4F3 for ; Tue, 11 Jun 2024 17:37:27 +0200 (CEST) Received: (qmail 19590 invoked by uid 550); 11 Jun 2024 15:37:22 -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 19558 invoked from network); 11 Jun 2024 15:37:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718120234; x=1718725034; 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=wr+oY21X1Ze1qqpDLwpRNiwmAo5gUz+WLE5SHRtBRSU=; b=GWWCLjTAkoi8Ar3aW1Jb9fM90cOPabxNK3j8nSF3vTyQ/nZXtDX15v8LAbcj6VChnl AtLSkpuEPyqwTQ35kvclTZPUqPdszDRSZg1wcpImJh2LFRsuYZLQYK6K12fsT+xbBja/ Wcr9LSzuKVXLsyleDEL0m//P9atWxk1JMcBdYz4RZ4KTyNmfqGuL6uohDmYEV8ozC88Z dv+t1HPlkP6t61Zgplq8GOnvbRNPY1qhoMSLxE2wEh24lQpnv2MoeUDWoFw3jYPNdFcb /YxqtzkWBa8b5qRhxceF0C42B0JOc3MtWEg9bHhvuCXISB87cHW/gp6FGcd7OBQFTtZd +lNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718120234; x=1718725034; 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=wr+oY21X1Ze1qqpDLwpRNiwmAo5gUz+WLE5SHRtBRSU=; b=rlHxlNOFwhIZ1GGOG0zBIKgShbcBVkNXw7uMqrzpo50NkJ6QrXF/QcNkHoixbvjDcF phWA7oPKqjBFxqCFoIX3PMQrvUTnZanNYGJdT9ZjEU58tN8z1ECR/1zWncgm/kI9MSPF U7kHR7034uhoEN+txQRLk/Va0euESFIDu+zLabWT7FLoNr9pCBT9J6LOtzm8zxvg7yCL eM/ulW/a1zHhHcGL/BVjptgi9ueDSXPO2eSFbdStnBHAUzDzRzOUr0jAhUxxDwCBNVWk wRKpzhhOEukvy7ZzsPtsb4SjgICvDfFKpL/SlOt5bA45SbjGF2IstkErJd9a7p7ma3DM oIPQ== X-Gm-Message-State: AOJu0Yy1FG1BRNnH5zGx/zdG0SF1Ju7cophx39JUHyWIzQkC8K5efqrH 8mK6KN0lnzjgceOyqr7IFy+gnjTjYbOvPchBntM77tVLmrJnHrqCsqtg+q6J X-Google-Smtp-Source: AGHT+IEFxq/aAEaBtqSEWVwG0sMKpXAZE/JWnOBJ2MCco6PRtXtdf+eAkYB51bceNMSF8pbBQ8emhw== X-Received: by 2002:a17:906:32c7:b0:a68:a137:d041 with SMTP id a640c23a62f3a-a6cd5611ba8mr830976666b.12.1718120233507; Tue, 11 Jun 2024 08:37:13 -0700 (PDT) Date: Tue, 11 Jun 2024 18:37:11 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240611144624.GP10433@brightrain.aerifal.cx> Subject: Re: [musl] [PATCH] mallocng: Add MTE support for Aarch64 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]: > > > @@ -102,17 +107,30 @@ void free(void *p) > > > { > > > if (!p) return; > > > > > > +#ifdef MEMTAG > > > + void *untagged = (void *)((uint64_t)p & ~MTE_TAG_MASK); > > > +#else > > > + void *untagged = p; > > > +#endif > > > + > > > struct meta *g = get_meta(p); > > .... > > > static inline struct meta *get_meta(const unsigned char *p) > > > { > > > assert(!((uintptr_t)p & 15)); > > > - int offset = *(const uint16_t *)(p - 2); > > > - int index = get_slot_index(p); > > > - if (p[-4]) { > > > +#ifdef MEMTAG > > > + const unsigned char *untagged = (const unsigned char *)((uint64_t)p & ~MTE_TAG_MASK); > > > +#else > > > + const unsigned char *untagged = p; > > > +#endif > > > > if free just drops the tag, then incorrectly tagged pointer > > will not be detected. musl does some use-after-free checks, > > so i dont know how important this is, but i'd check that the > > passed pointer matches the memory tag (unless 0 sized and > > that the tag is non-0) otherwise a forged pointer may cause > > corruption. > > Yes. Would just accessing a byte at the start fix this? Yes, a byte access can solve this. Will add. > > > i don't see where you enable tagged pointer abi and checks > > (prctl) or where you add PROT_MTE to the mmapped memory. > > https://www.kernel.org/doc/html/latest/arch/arm64/memory-tagging-extension.html > > https://www.kernel.org/doc/html/latest/arch/arm64/tagged-address-abi.html > > (i think we want the synchronous tag check option.) > > note there is software that assumes page granularity for > > memory protection e.g. does read access at p&-4096, and > > there may software that assumes the top bits of a valid > > pointer is 0 so unconditionally enabling tagging and tag > > checks can be an issue. > > I don't think that's a problem. malloc has no contract to allow those > things. > > > another potential issue is the early ALIGN_UP of the malloc > > size: this overflows malloc(-1) and i think changes > > malloc_usable_size(malloc(1)). > > Yes, I saw that was incorrect and don't understand the motivation. If > it's to avoid tag mismatch at the final 12b, that could be done where > the size class is selected instead. But it would be better if we could > make it work with the tag mismatch (not sure how hard that is) so this > space is still usable (ignoring tag when accessing the header). > 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. > > 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. Can we do a special case and return NULL on zero-size allocations? Stefan