Re: [PATCH v13 8/8] arm64: expose FAR_EL1 tag bits in siginfo

[Peter Collingbourne <pcc@google.com>]

On Wed, Nov 4, 2020 at 9:45 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> 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@arm.com> 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?

Yes, because in the case that I mentioned with a non-linear buffer
overflow into an unmapped page, the error reporting mechanism would
still need to know the address tag in order to associate the access
with an allocation.

> > > 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.

This isn't the case for every Android application. For example, some
applications, such as Chrome, have their own crash reporting mechanism
(Crashpad in Chrome's case) and install their own signal handlers.
Google also offers Firebase Crashlytics for third-party applications
to use. Although the systems that I've mentioned are open source
and/or owned by Google so we could fix them if necessary, there's
nothing stopping apps from using their own third-party crash reporting
systems.

It's also possible for application-supplied language implementations,
such as Mono and Unity, to install their own signal handler to
implement fast null checks. You could also imagine a userspace page
fault handler being implemented this way as an alternative to using
userfaultfd.

> 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).

Regardless of whether it's Android or not, you might still run into a
situation where one part of the system needs the bits and another gets
confused by them. (This could be something like two libraries sharing
a signal handler with something like Android's libsigchain, or one
process monitoring another's signals via ptrace.) Having this
controlled by a prctl seems like a global solution to a local problem,
which is the sort of thing that should be avoided if possible.

Peter

> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel