linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Peter Collingbourne <pcc@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Helge Deller <deller@gmx.de>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Oleg Nesterov <oleg@redhat.com>,
	linux-api@vger.kernel.org,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Kostya Serebryany <kcc@google.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Andrey Konovalov <andreyknvl@google.com>,
	David Spickett <david.spickett@linaro.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Will Deacon <will@kernel.org>,
	Evgenii Stepanov <eugenis@google.com>
Subject: Re: [PATCH v16 6/6] arm64: expose FAR_EL1 tag bits in siginfo
Date: Mon, 16 Nov 2020 13:36:01 +0000	[thread overview]
Message-ID: <20201116133600.GY6882@arm.com> (raw)
In-Reply-To: <87ft5an257.fsf@x220.int.ebiederm.org>

On Sun, Nov 15, 2020 at 08:08:36AM -0600, Eric W. Biederman wrote:
> Peter Collingbourne <pcc@google.com> writes:
> 
> > The kernel currently clears the tag bits (i.e. bits 56-63) in the fault
> > address exposed via siginfo.si_addr and sigcontext.fault_address. However,
> > the tag bits may be needed by tools in order to accurately diagnose
> > memory errors, such as HWASan [1] or future tools based on the Memory
> > Tagging Extension (MTE).
> >
> > We should not stop clearing these bits in the existing fault address
> > fields, because there may be existing userspace applications that are
> > expecting the tag bits to be cleared. Instead, introduce a flag in
> > sigaction.sa_flags, SA_EXPOSE_TAGBITS, and only expose the tag bits
> > there if the signal handler has this flag set.
> 
> For future architectures that implement something similar does it make
> sense that to hide tag bits by default?

I think on arm64 this comes from the fact that the tag bits information
is not available in all scenarios.  To keep things clean, the decision
was taken early on to just zero them all the time in si_addr to avoid
software getting confused.  Possibly other arches do something similar,
but that would need digging into.

There seems to be debate on whether these bits are part of the address
or not.  For si_addr I think they probably _should_ be regarded as part
of the address in general, and arches that can always report all these
bits in si_addr should probably do so IMHO.

> I am wondering if SA_EXPOSE_TABGITS might make sense as an architecture
> specific sa bit.

Perhaps.  Peter, do you see other arches masking out bits in si_addr?

[...]

Cheers
---Dave

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

  reply	other threads:[~2020-11-16 13:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13  2:53 [PATCH v16 0/6] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-11-13  2:53 ` [PATCH v16 1/6] parisc: Drop parisc special case for __sighandler_t Peter Collingbourne
2020-11-13  2:53 ` [PATCH v16 2/6] parisc: start using signal-defs.h Peter Collingbourne
2020-11-13  2:53 ` [PATCH v16 3/6] arch: move SA_* definitions to generic headers Peter Collingbourne
2020-11-13  2:53 ` [PATCH v16 4/6] signal: clear non-uapi flag bits when passing/returning sa_flags Peter Collingbourne
2020-11-13  2:53 ` [PATCH v16 5/6] signal: define the SA_UNSUPPORTED bit in sa_flags Peter Collingbourne
2020-11-14 13:53   ` Eric W. Biederman
2020-11-14 22:12     ` Peter Collingbourne
2020-11-16 23:48       ` Eric W. Biederman
2020-11-13  2:53 ` [PATCH v16 6/6] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-11-15 14:08   ` Eric W. Biederman
2020-11-16 13:36     ` Dave Martin [this message]
2020-11-16 18:32       ` Peter Collingbourne
2020-11-16 19:01   ` Catalin Marinas
2020-11-16 21:55     ` Eric W. Biederman
2020-11-16 22:08       ` Catalin Marinas
2020-11-16 23:28       ` Peter Collingbourne
2020-11-16 23:59         ` Eric W. Biederman
2020-11-17  3:24           ` Peter Collingbourne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201116133600.GY6882@arm.com \
    --to=dave.martin@arm.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=andreyknvl@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=david.spickett@linaro.org \
    --cc=deller@gmx.de \
    --cc=ebiederm@xmission.com \
    --cc=eugenis@google.com \
    --cc=kcc@google.com \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oleg@redhat.com \
    --cc=pcc@google.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).