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

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 04/10/23 11:51, Szabolcs Nagy wrote:
> 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.

Do you mean just drop unsecvars and not filter out glibc environment variables
for AT_SECURE?

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

I complete agree, tunables_strdup was a source of headache due its allocation
requirement and, now, for parsing tunables.