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

[Siddhesh Poyarekar]

On 11/26/20 9:18 PM, Richard Earnshaw wrote:
> I think it's exactly the way the patch set was structured, I just wasn't
> explicit in saying that :)

Agreed, it only reinforces the patch structure and I guess it was also 
for me to clear my own understanding of the patch structure.

> 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

Fair enough.

> 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
On 11/26/20 9:20 PM, H.J. Lu wrote:
 > I think we need to address binary marking first before adding MTE to
 > glibc.

Could you elaborate on why binary marking should block glibc support in 
MTE?  Do you see it changing the design considerably?  Other than the 
tunables (that are not guaranteed to be stable across releases) and 
configure flags, I could not spot any irreversible ABI/API impact that 
would cause issues later.

> So perhaps for now, we'd want to inherit it through normal fork() type
> calls, but perhaps not for setxid at this stage, but we may want to
> widen it later.  On the other hand, for a security feature you'd perhaps
> want a more robust (harder to turn off) mechanism than just modifying a
> user-level environment variable.

Agreed.  I had proposed systemwide tunables to address systemwide 
configuration issues some years ago.  Given how long it took me to get 
to writing tunables in the first place, I'd say another year or so for 
systemwide tunables ;)

Siddhesh