From mboxrd@z Thu Jan 1 00:00:00 1970 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=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1572 invoked from network); 16 Sep 2023 06:54:29 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 16 Sep 2023 06:54:29 -0000 Received: (qmail 11294 invoked by uid 550); 16 Sep 2023 06:54:24 -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 10235 invoked from network); 16 Sep 2023 06:54:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694847251; x=1695452051; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LyXkahdQFrY1S+DbYKE9tjBBug0XtLJvZQeGuBhki+U=; b=UOJA1OUjXsZGhI8L4161UQlFw1b+Fr3w3Owj5QHtbjf5UxH33+5VIgFeXoquRwQbBV iqyQP/0Jl4DFjAxPeAqYqs+c4ILR+8xxlrTRxJoAoB7B1xBwnP6s47Wco/ctiMmqWthk jTv1vu3u/06Cu4xNmQpdmhBV7ZbzjRTqyvTbPI1qnK1tNzcTovxmBazFlaQLu+ojKDFc gtRkA0Zt7uH3NVn6IIh/OPzyWbAJTGWXagtL4ojXCw5/fGJQm0Vcu06sg3BzK9DOMAmm TDZIIr8TcqgsXA9WzcRIyb+6AlhaK0HJUnHOitjpMJhfuVEkMFFMS2Z1UTY1GI5VjA6R WKsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694847251; x=1695452051; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LyXkahdQFrY1S+DbYKE9tjBBug0XtLJvZQeGuBhki+U=; b=Y81i872w6kdPVFvAH2daYVMi6FQft6YXunIga4fpxS1ZA7Ye9sAAMhD2jPaLzU3d5f dp/hv4Vj85mllGDp32CrMlphTQ/l9PY2BqqhNa86EwQblpZt7ZGiYjhoaD6rUYm6dk6y c3/xEDtonpc4le7+LjaK8e1ztbkv1gDdum4Bch3qnP7a2g0e4nArtM6n/tjpDr+//33B Jwg8fJQkSUQczl/g74OfnbUhPoiAYV+lu6GG0wrEkCg5oUf4t91EKY5+B1CoX1EhtlFd QWBlK2Hk38D3JHZ1yN/lLKpxLNN0CvKEF6Wz3COwGtJ08eUusLVj2R+Au7Mgz/9+/KL1 N45w== X-Gm-Message-State: AOJu0YxsnBR0ktJz4BTMEnejB2RR9vc2VNBPKHXjjYRanENa05cUP2PA Ggrn75wp3+qbclWm0uoUzLaPgahySa8tBNJY7S0= X-Google-Smtp-Source: AGHT+IHTtdJuJ2Lf+bemJBPoL6bnxjGX6AfZqS5DvzSu8uuIebIsKghX0MGtwb2SEspavol/Nw2aj3wWZGxODOpYs7A= X-Received: by 2002:a9d:4e90:0:b0:6be:e1cd:7326 with SMTP id v16-20020a9d4e90000000b006bee1cd7326mr4267776otk.4.1694847251377; Fri, 15 Sep 2023 23:54:11 -0700 (PDT) MIME-Version: 1.0 References: <20230908174939.80579-1-jamestiotio@gmail.com> <20230909004835.GD4163@brightrain.aerifal.cx> <20230914112308.bc1833d3f827ada2d1b7d85c@zhasha.com> <20230914121834.GE4163@brightrain.aerifal.cx> In-Reply-To: <20230914121834.GE4163@brightrain.aerifal.cx> From: James R T Date: Sat, 16 Sep 2023 14:53:35 +0800 Message-ID: To: Rich Felker , Joakim Sindholt Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] Add a safe dequeue integrity check for mallocng On Thu, Sep 14, 2023 at 5:23=E2=80=AFPM Joakim Sindholt wrote: > > It's a little confusing but assert() in mallocng is not real assert(): > http://git.musl-libc.org/cgit/musl/tree/src/malloc/mallocng/glue.h#n33 > The issue is that if memory is under control of an attacker then doing > anything at all, especially running the stdio machinery, is unsafe. To > that end musl uses a_crash() here which expands to a minimal set of > instructions to crash the process: > http://git.musl-libc.org/cgit/musl/tree/arch/x86_64/atomic_arch.h#n106 > > Furthermore, musl doesn't use any of thosed tagged branch tricks and I > personally doubt it would make any difference. > Ah okay, got it. On Thu, Sep 14, 2023 at 8:18=E2=80=AFPM Rich Felker wrote= : > > Yes. mallocng is written such that you could use the normal assert > with it, but presently it's just expanding to a_crash(). At some point > this might be revamped to crash with a message string in a particular > register or argument slot or something so that you get a bit more > meaningful information if looking at it in a debugger. And indeed, the > reason not to do any message printing, etc. is that you're running in > a known-compromised process state where any further complex execution > is unsafe (e.g. if the out-of-band malloc metadata was clobbered, the > function pointers in stderr might also have been clobbered, since the > latter are *easier to reach* than the OOB metadata). > Hmm sure, that makes sense. > > Yes, the only reason libm.h has them is because nsz is using the code > in other environments that want them, and it made sense to avoid > gratuitous differences. We don't generally use those in musl. If the > compiler isn't generating good code and puts the failure path as a hot > path, we probably should explore whether the compiler is missing that > it's a does-not-return thing (which should always be treated as cold). > But indeed I doubt it makes a difference. > Got it. I will send in a new patch to simply use an assertion instead then. Thank you for the detailed explanations! Best regards, James Raphael Tiovalen