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

[H.J. Lu]

On Thu, Nov 26, 2020 at 9:00 AM Richard Earnshaw
<Richard.Earnshaw@foss.arm.com> wrote:
>
> 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.
>

What is your ultimate goal? What is your initial goal?

-- 
H.J.