mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <>
To: Stefan Jumarea <>
Cc:, Razvan Deaconescu <>,
	Michalis Pappas <>
Subject: Re: [musl] Project Proposal MTE Support
Date: Wed, 19 Jul 2023 21:51:22 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <ZLeSohZHT2xHA/xx@stefan-IdeaPad-5-15ARE05>

On Wed, Jul 19, 2023 at 10:37:06AM +0300, Stefan Jumarea wrote:
> 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.

mallocng was designed with the idea of possible future MTE use in
mind. At the time, I seem to recall there were obstacles to being able
to use MTE, so it wasn't pursued. But it's definitely an interesting
and powerful direction, one of the few ISA-level hardening features
that's actually a hard access control boundary rather than loads of
complexity to make ROP slightly harder.

> 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?

There is no immediate plan. Probably the first steps need to be
figuring out some abstractions needed, particularly a way for the
implementation to take tagged pointers from the caller and do the
arithmetic to access partly out-of-band data (like the group header)
with a different/zero tag. These should be able to collapse out to
no-ops on archs without MTE, as well as be defined in a manner to work
on other archs with comparable features (like the classic sparc prior
art for this, if we ever get the sparc port added, or any future archs
that add such a thing).

I know there were past discussions on this and I may have some
separate notes of my own from when mallocng was created, so I'll see
what I can dig up that might be of use.


  reply	other threads:[~2023-07-20  1:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19  7:37 Stefan Jumarea
2023-07-20  1:51 ` Rich Felker [this message]
2023-07-20  5:47   ` Stefan Jumarea
2023-07-20 13:03   ` Szabolcs Nagy
2023-07-20 19:02     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).