[PATCH v3 2/8] elf: Add a tunable to control use of tagged memory

[Richard Earnshaw]

On 26/11/2020 16:51, H.J. Lu wrote:
> On Thu, Nov 26, 2020 at 8:28 AM Richard Earnshaw
> <Richard.Earnshaw@foss.arm.com> wrote:
>>
>> On 26/11/2020 15:50, H.J. Lu wrote:
>>> On Thu, Nov 26, 2020 at 7:48 AM Richard Earnshaw
>>> <Richard.Earnshaw@foss.arm.com> wrote:
>>>>
>>>> On 26/11/2020 15:27, Siddhesh Poyarekar wrote:
>>>>> On 11/26/20 7:45 PM, Richard Earnshaw wrote:
>>>>>> Sure, I can do that if you really think it's the right thing (I presume
>>>>>> this has already been done for other tunables on other architectures, so
>>>>>
>>>>> There's sysdeps/aarch64/dl-tunables.list too, so there's no additional
>>>>> plumbing needed...
>>>>>
>>>>>> that there isn't a lot of additional plumbing needed).  But is it?  It
>>>>>> seems odd to me that the generic malloc code would read a tunable that
>>>>>> only existed in a particular sysdep configuration.  There has to exist
>>>>>> some mechanism for the machine independent code to know that the tagging
>>>>>> behaviour is needed.
>>>>>
>>>>> ... but I see your point.  How about if we look at the patchset as
>>>>> follows, which should make it more clearer.  It doesn't really change
>>>>> your patchset in any major way (other than fixing failures and review
>>>>> comments), it's only to make the story behind it and hence the design
>>>>> decisions more deliberate.
>>>>>
>>>>> The first part of the patchset (1-3) enables infrastructure to enable
>>>>> memory tagging in glibc.  At the project level, this involves adding
>>>>> tagging calls (can't call them hooks because that name's taken and also
>>>>> invoke nightmares for some) in malloc to allow tagging malloc'd objects.
>>>>>  The tagging calls are nops in the default case but support could be
>>>>> added either at the architecture level or in the form of a software
>>>>> implementation.
>>>>>
>>>>> The library could add more tag calls in other parts of the library to
>>>>> colour them library-internal (e.g. dynamic linker data, glibc internal
>>>>> data) but that's for later.
>>>>>
>>>>> This basically means that memory tagging becomes a library-wide concept
>>>>> and hence the glibc.mem.tagging tunable and configury should be
>>>>> implemented project-wide, i.e. the way you've done it with your v3
>>>>> patchset with just the tunable naming changed.
>>>>>
>>>>> The second part (6-8, assuming 4 and 5 get subsumed into 3) of the
>>>>> patchset implements aarch64 architecture support for memory tagging.
>>>>> This involves enabling tagging for the entire process using prctl at
>>>>> startup and tagging malloc'd objects.  It is unavoidable that tunables
>>>>> will eventually have processwide impact and not just in the library;
>>>>> there's precedent for that in x86 CET.
>>>>>
>>>>> What do you think?
>>>>
>>>> I think it's exactly the way the patch set was structured, I just wasn't
>>>> explicit in saying that :)
>>>>
>>>>>
>>>>> On a slightly different but related point, you may want to think about
>>>>> inheritance of the glibc.mem.tagging tunable when you work on v4, i.e.:
>>>>>
>>>>> 1. Should child processes inherit them?  If you're modeling it along the
>>>>> lines of MALLOC_CHECK_ (i.e. diagnostics only) then you'd want to keep
>>>>> it as default, i.e. no inheritance.  However if you model it as a
>>>>> hardening feature, you may want to set security_level to IGNORE so that
>>>>> children inherit tagging and forking doesn't become a way to escape
>>>>> tagging protections.
>>>>>
>>>>> 2. Should setxid children inherit enabled memory tagging? Again if
>>>>> you're modeling it as a hardening feature, then maybe you want to set
>>>>> security_level to NONE so that it is inherited by setxid children.  I
>>>>> think it will be the first tunable to cross that boundary if you decide
>>>>> to take that route!
>>>>>
>>>>
>>>> A good question.  I'd say at this point it's a bit more of a debugging
>>>> feature (at least until things have settled down); but longer term it
>>>> may well become a hardening feature as well.  Before we can go down that
>>>> route, though we'll need to sort out how to mark binaries that are
>>>> genuinely incompatible with MTE.  We already know that python's object
>>>> management code violates MTE assumptions, for example; either that will
>>>> need to be fixed, or we'll need a route to automatically disable MTE
>>>> when running programs like that.
>>>
>>> I think we need to address binary marking first before adding MTE to
>>> glibc.
>>
>> Sorry, I disagree.  While this is a debugging tool there's no need for
>> binary marking.
>>
>> Once we have a clearer understanding of what's needed there, we can work
>> out how best to do the marking.
>>
> 
> If the only goal is to have a malloc with memory tag, you should enable
> memory tag in an out-of-tree malloc implementation.  It should be sufficient.
> 

It's not the only goal.  What's more that would require special linking,
rather than just being able to turn on the feature.

Initially, that might be the main usage, but it's not the ultimate goal.

R.