On Mon, Jun 17, 2019 at 10:18 AM Catalin Marinas catalin.marinas@arm.com wrote:
On Mon, Jun 17, 2019 at 09:57:36AM -0700, Evgenii Stepanov wrote:
On Mon, Jun 17, 2019 at 6:56 AM Catalin Marinas catalin.marinas@arm.com wrote:
On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
From: Catalin Marinas catalin.marinas@arm.com
It is not desirable to relax the ABI to allow tagged user addresses into the kernel indiscriminately. This patch introduces a prctl() interface for enabling or disabling the tagged ABI with a global sysctl control for preventing applications from enabling the relaxed ABI (meant for testing user-space prctl() return error checking without reconfiguring the kernel). The ABI properties are inherited by threads of the same application and fork()'ed children but cleared on execve().
The PR_SET_TAGGED_ADDR_CTRL will be expanded in the future to handle MTE-specific settings like imprecise vs precise exceptions.
Signed-off-by: Catalin Marinas catalin.marinas@arm.com
A question for the user-space folk: if an application opts in to this ABI, would you want the sigcontext.fault_address and/or siginfo.si_addr to contain the tag? We currently clear it early in the arm64 entry.S but we could find a way to pass it down if needed.
For HWASan this would not be useful because we instrument memory accesses with explicit checks anyway. For MTE, on the other hand, it would be very convenient to know the fault address tag without disassembling the code.
I could as this differently: does anything break if, once the user opts in to TBI, fault_address and/or si_addr have non-zero top byte?
I think it would be fine.
Alternatively, we could present the original FAR_EL1 register as a separate field as we do with ESR_EL1, independently of whether the user opted in to TBI or not.
-- Catalin