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

[H.J. Lu]

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.

-- 
H.J.