On Thu, May 23, 2019 at 08:44:12AM -0700, enh wrote:
On Thu, May 23, 2019 at 7:45 AM Catalin Marinas catalin.marinas@arm.com wrote:
On Wed, May 22, 2019 at 01:47:36PM -0700, Kees Cook wrote:
For userspace, how would a future binary choose TBI over MTE? If it's a library issue, we can't use an ELF bit, since the choice may be "late" after ELF load (this implies the need for a prctl().) If it's binary-only ("built with HWKASan") then an ELF bit seems sufficient. And without the marking, I'd expect the kernel to enforce MTE when there are high bits.
The current plan is that a future binary issues a prctl(), after checking the HWCAP_MTE bit (as I replied to Elliot, the MTE instructions are not in the current NOP space). I'd expect this to be done by the libc or dynamic loader under the assumption that the binaries it loads do _not_ use the top pointer byte for anything else.
yeah, it sounds like to support hwasan and MTE, the dynamic linker will need to not use either itself.
With hwasan compiled objects this gets more confusing (any ELF note to identify them?).
no, at the moment code that wants to know checks for the presence of __hwasan_init. (and bionic doesn't actually look at any ELF notes right now.) but we can always add something if we need to.
It's a userspace decision to make. In the kernel, we are proposing that bionic calls a prctl() to enable MTE explicitly. It could first check for the presence of __hwasan_init.