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.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE,T_TVD_FUZZY_SECURITIES autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20537 invoked from network); 20 Jul 2023 13:03:28 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Jul 2023 13:03:28 -0000 Received: (qmail 15903 invoked by uid 550); 20 Jul 2023 13:03:23 -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 15853 invoked from network); 20 Jul 2023 13:03:22 -0000 Date: Thu, 20 Jul 2023 15:03:10 +0200 From: Szabolcs Nagy To: Rich Felker Cc: Stefan Jumarea , musl@lists.openwall.com, Razvan Deaconescu , Michalis Pappas Message-ID: <20230720130310.GA3448312@port70.net> Mail-Followup-To: Rich Felker , Stefan Jumarea , musl@lists.openwall.com, Razvan Deaconescu , Michalis Pappas References: <20230720015122.GO4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20230720015122.GO4163@brightrain.aerifal.cx> Subject: Re: [musl] Project Proposal MTE Support * Rich Felker [2023-07-19 21:51:22 -0400]: > On Wed, Jul 19, 2023 at 10:37:06AM +0300, Stefan Jumarea wrote: > > Hello all, > >=20 > > With the present, I would like to discuss the prospect of adding MTE su= pport in > > the Musl memory allocator. > >=20 > > Currently, (starting with release 1.2.1, August 2020, commit 503bd39766= 23)[1], Musl > > introduces a new "malloc" implementation ("mallocng"), which solves a l= ot of the > > intended malloc-hardening issues. However, further hardening can be imp= lemented, > > including MTE (Memory Tagging Extension) support. >=20 > 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. note: it is not quite "hard access control" because *(p+off) can still access anything when off is attacker controlled: the top bits of p are not protected so the tag can change and there are only 16 tags, so it can be guessed. (in principle the compiler could fix this by always masking "off" in ptr arithmetic, but that's not implemented and has costs.) i tried mallocng with mte at some point (and worked on the glibc mte malloc too). one issue was the 4b in-band data (at end of prev slot), it should not be in the same mte granule (16b) as user data otherwise it can be corrupted and more importantly there is an access issue as the tag of that granule may change async. (glibc had a similar issue which meant that mte support required more wasteful layout for small allocations even if tagging got disabled: we dont want enable/disable to change the layout so mte can be used to debug heap issues. upstream glibc does not support mte by default for this reason: it's a configure time option.) another issue was that MADV_FREE clears the tags, so heap memory owned by the malloc implementation (meta data) must use 0 tag instead of a different dedicated tag. note: tagging must be posible to turn off for a process because some sw assumes page size granule protection (does oob read access) or uses pointer top bits in some way. > > We are using Musl as the primary libc within Unikraft, a Unikernel Deve= loping Kit[2], > > and we support MTE on the low-level memory allocator. This however lack= s 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. > >=20 > > Our goal is to have MTE protection implemented in a fine-grained alloca= tor > > (i.e. Musl "malloc" implementation), that will successfully prevent mem= ory safety > > violations. > >=20 > > 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 architect= ure > > provides ways to optimize the implementation for functions like "calloc= " or > > large "malloc" blocks (instructions like "store allocation tag with zer= oing", > > "sdgz", "store allocation tag for blocks", "sdgm"), along with an async= hronous > > way to check for a Tag Check Fault (e.g. on IRQs, on task / thread swit= ches, etc.). async tag check is not very useful for debugging nor for security (essentially the failure is delayed to the next syscall and the damage can be done by that time). there is asymmetric mode (sync read check, async write check) which may be useful but requires newer arch. > >=20 > > A bit about myself, my name is =C8=98tefan Jum=C4=83rea, I am an underg= raduate student in > > the final year at University Politehnica of Bucharest[3], and I=E2=80= =99ve been part of the > > Unikraft OSS project[2] for almost two years. > > I would like to make this my diploma project (due June 2024). > >=20 > > 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 conside= r? >=20 > 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). note that sparc adi is less practical as its granule is 64b (cache line size) which blows up small allocations. >=20 > 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. >=20 > Rich