On Tue, Nov 03, 2020 at 11:16:53AM -0800, Peter Collingbourne wrote: > On Tue, Nov 3, 2020 at 10:33 AM Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > That said, I wonder whether we could solve this for MTE without new > > fields by always setting the tag in si_addr when si_code is SEGV_MTE*. > > This wouldn't solve the problem for MTE in the case where there is a > non-linear buffer overflow that extends into an unmapped page, in > which case we would get a SEGV_MAPERR that we would still need the tag > bits for. What I was thinking of is to only present the tags for SEGV_MTE* faults (tag check faults). Is the tag relevant for a SEGV_MAPERR fault? > > Alternatively, we could add a prctl() bit to require tagged si_addr. > > It's an option that we considered but I would be concerned about the > compatibility implications of this. In practice, on Android we would > always have this bit set, so applications would be exposed to the tag > bits in si_addr. If applications have previously relied on the > documented behavior that the tag bits are unset, they may get confused > by them now being set. It also wouldn't provide a way for the kernel > to communicate which tag bits are valid. It depends what you mean by application. If the MTE enabling and signal handling is done from zygote, I suspect the rest of the app won't install its own signal handlers, so they can't get confused. For standard Linux processes and glibc, the feature wouldn't be enabled by default even if MTE was turned on (we'd add a new prctl() bit). Anyway, I'm not saying we should go for this approach, just making sure that we explored all the options (sorry, should have read the previous 12 series ;)). -- Catalin
