On Wed, May 22, 2019 at 04:09:31PM -0700, enh wrote:
On Wed, May 22, 2019 at 4:03 PM Evgenii Stepanov eugenis@google.com wrote:
On Wed, May 22, 2019 at 1:47 PM Kees Cook keescook@chromium.org wrote:
On Wed, May 22, 2019 at 05:35:27PM +0100, Catalin Marinas wrote:
I would also expect the C library or dynamic loader to check for the presence of a HWCAP_MTE bit before starting to tag memory allocations, otherwise it would get SIGILL on the first MTE instruction it tries to execute.
I've got the same question as Elliot: aren't MTE instructions just NOP to older CPUs? I.e. if the CPU (or kernel) don't support it, it just gets entirely ignored: checking is only needed to satisfy curiosity or behavioral expectations.
MTE instructions are not NOP. Most of them have side effects (changing register values, zeroing memory).
no, i meant "they're encoded in a space that was previously no-ops, so running on MTE code on old hardware doesn't cause SIGILL".
It does result in SIGILL, there wasn't enough encoding left in the NOP space for old/current CPU implementations (in hindsight, we should have reserved a bigger NOP space).
As Evgenii said, the libc needs to be careful when tagging the heap as it would cause a SIGILL if the HWCAP_MTE is not set. The standard application doesn't need to be recompiled as it would not issue MTE colouring instructions, just standard LDR/STR.
Stack tagging is problematic if you want to colour each frame individually, the function prologue would need the non-NOP MTE instructions. The best we can do here is just having the (thread) stacks of different colours.