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=-1.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26595 invoked from network); 19 Jul 2023 07:37:24 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Jul 2023 07:37:24 -0000 Received: (qmail 24393 invoked by uid 550); 19 Jul 2023 07:37:21 -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 24361 invoked from network); 19 Jul 2023 07:37:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689752229; x=1692344229; h=content-transfer-encoding:content-disposition:mime-version :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=kuPZmrW02j+mwtxi0fWIjEagMOP1Usu2Qje8H6GFi7M=; b=IFPvlJ7ZLXSaQqwFKlRVeyKWPtfTMtLPSC1xWNNAMDtlhh74tvekieugSBkppLj9Xl NTl53V6v06oT2Cez1SHAeKJsGC9yXSeH3R443gtn2uXO72xGSP0qxzHvg4Q4/fRWwU22 mUQL7yo6D7TqE2ejcqOQ5soOAzk3SiX/UeY/kNQ7LqkfyxvFmUUjICBLraLsHKoNJJjO cSAptG57zWnanOaMXTM+S+VPegvJg+qy6C26kJCSCnV0ev80uLtqLQtB7Tl5tr0aExAb pPEvJyJ24i0h+1XE3FCT9to04G2IqSIHc07q+q4M3Z3E3fmKYvT5ZtGQx/gEUfs/X7AH adDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689752229; x=1692344229; h=content-transfer-encoding:content-disposition:mime-version :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kuPZmrW02j+mwtxi0fWIjEagMOP1Usu2Qje8H6GFi7M=; b=mAMtcI71o+jBuYf1v6W0Mut/TCvtRKC0kALOr1J/tGSVq/1QxNXOFfz5b1DmXuynzG ey5k+2PxIcDcsx1UlEl56Mn+/GY/LwHLuaMrGGfstILYeMH46wzZDxu8oa834GfUxfvs rWud3iiig5xP94XlIUTz0THP7SLP5j4HdUk3l4/hxp3Mb5hLENZP5XJkr6LNC6LW+70d nWDETBgbaagwDyJPV8684k9qdl9xLNtQ7JGf3dlTN50PtVZOPf7KJ8CGIuNa5eZ04NnL xtAqd80xcAjEPfZ5pWg8vUbDYbGF+5T21u/qJeDxNU7qvnGQowJf3YhNf87uqvbxhz8s Gbeg== X-Gm-Message-State: ABy/qLb4UAsbkSP92L0asvhzbjQ9CyDoGceRcT+y6iRSillMqZMwVmKA 3UHJ+vZ8w8a+EPoqzwphiKDRXZSlXzM= X-Google-Smtp-Source: APBJJlHH7TJuxPnGvuYaM2WWd9IrJoLNQbYwapVA9zTy20UO84BfhEdOq+skRJd5sellZsbF9Sv8Tw== X-Received: by 2002:a5d:4e41:0:b0:314:1483:d8ad with SMTP id r1-20020a5d4e41000000b003141483d8admr15853659wrt.44.1689752228710; Wed, 19 Jul 2023 00:37:08 -0700 (PDT) Date: Wed, 19 Jul 2023 10:37:06 +0300 From: Stefan Jumarea To: musl@lists.openwall.com Cc: dalias@aerifal.cx, Razvan Deaconescu , Michalis Pappas Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Subject: [musl] Project Proposal MTE Support Hello all, With the present, I would like to discuss the prospect of adding MTE support in the Musl memory allocator. Currently, (starting with release 1.2.1, August 2020, commit 503bd3976623)[1], Musl introduces a new "malloc" implementation ("mallocng"), which solves a lot of the intended malloc-hardening issues. However, further hardening can be implemented, including MTE (Memory Tagging Extension) support. We are using Musl as the primary libc within Unikraft, a Unikernel Developing Kit[2], and we support MTE on the low-level memory allocator. This however lacks a lot in terms of granularity, as the internal allocator has a page-size minimum allocation level, and tagging one page at the time still allows for memory safety violations in the area of one page. Our goal is to have MTE protection implemented in a fine-grained allocator (i.e. Musl "malloc" implementation), that will successfully prevent memory safety violations. Extended measurements will need to be done in order to provide a clear overview over the performance impact that using MTE will have, but the architecture provides ways to optimize the implementation for functions like "calloc" or large "malloc" blocks (instructions like "store allocation tag with zeroing", "sdgz", "store allocation tag for blocks", "sdgm"), along with an asynchronous way to check for a Tag Check Fault (e.g. on IRQs, on task / thread switches, etc.). A bit about myself, my name is Ștefan Jumărea, I am an undergraduate student in the final year at University Politehnica of Bucharest[3], and I’ve been part of the Unikraft OSS project[2] for almost two years. I would like to make this my diploma project (due June 2024). Is it something of interest in the Musl community? Is it planned work, is there anyone else working on it? If not, I would like to start working on the project in the next weeks. Do you have any comments, suggestions, or other things I should consider? [1]: https://git.musl-libc.org/cgit/musl/commit/?id=503bd3976623493a10b0f32c617feb51f9ba04c8 [2]: https://unikraft.org/ [3]: https://upb.ro/en Thank you, Stefan