Re: [PATCH 2/2] aarch64: Make glibc.mem.tagging SXID_ERASE

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 10/04/2023 10:23, Siddhesh Poyarekar wrote:
> The actual problem I'm trying to solve is to get rid of SXID_IGNORE and
> SXID_NONE and the first step is to drop users of those levels. Supporting
> those levels requires additional processing in __libc_enable_secure, which
> is a source of bugs like CVE-2023-4911.  I'm not convinced that we really
> *need* to have tunables go across sxid boundaries, so I want to flip the
> question around: do you think it is *necessary* for memory tagging tunables
> to percolate sxid boundaries? If not, then they should stay at SXID_ERASE.

...

> The end goal here is to drop everything but SXID_ERASE so that we don't have
> to do string twiddling under __libc_enable_secure.
> 
> The other alternative to achieve the same effect (i.e. not twiddle strings
> in __libc_enable_secure) could be to make *everything* SXID_IGNORE, which
> would then leave GLIBC_TUNABLES untouched for non-setuid children to do what
> they please with it.

personally i think setuid binaries should not touch the
env, just ignore it, so everything SXID_IGNORE.

it's not just the string twiddling but tunables_strdup
is a problem too (it can fail, needs early alloc,..).
ideally tunables_init would be a nop with AT_SECURE and
otherwise parsed the env var without malloc and touching
the env[] array passed by the kernel.