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

[H.J. Lu]

On Thu, Nov 26, 2020 at 9:56 AM Richard Earnshaw
<Richard.Earnshaw@foss.arm.com> wrote:
>
> On 26/11/2020 17:31, H.J. Lu via Libc-alpha wrote:
> > On Thu, Nov 26, 2020 at 9:21 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> >>
> >> The 11/26/2020 08:51, H.J. Lu via Libc-alpha 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:
> >>>>> 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.
> >>
> >> out-of-tree malloc implementation cannot reliably
> >> enable mte: it cannot guarantee that it can initialize
> >> mte before the process becomes multi-threaded or that
> >> it can execute code in all threads before allocated
> >> memory is accessed there, so mte checks can be off
> >> for some threads.
> >>
> >> so the mte on/off setting has to be in glibc for now
> >> (out-of-tree implementation is possible, but it won't
> >> be reliable in all cases).
> >
> > I don't disagree with it.   If the new libc will be installed as the
> > system glibc, it needs to support binary marker even if there
> > are currently no binaries with marker.
> >
>
> Trying to define a binary marker before we know exactly how we want the
> binary marker to work is just a good way to define the wrong binary marker.
>
> And for the record, I don't think we know how we'd want that to work at
> this point, nor do I think it's necessary for the code proposed to work
> as intended.

I believe this should be addressed first.

> So I think this is trying to put the cart before the horse.
>
> R.



-- 
H.J.