All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Peter Collingbourne <pcc@google.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Kostya Serebryany <kcc@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Dave Martin <Dave.Martin@arm.com>, Will Deacon <will@kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Richard Henderson <rth@twiddle.net>,
	linux-api@vger.kernel.org, Helge Deller <deller@gmx.de>,
	David Spickett <david.spickett@linaro.org>
Subject: Re: [PATCH v14 8/8] arm64: expose FAR_EL1 tag bits in siginfo
Date: Thu, 12 Nov 2020 18:53:25 +0000	[thread overview]
Message-ID: <20201112185324.GP29613@gaia> (raw)
In-Reply-To: <87eel2ypy3.fsf@x220.int.ebiederm.org>

On Mon, Nov 09, 2020 at 07:13:08PM -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, create a new pair of
> > fields in siginfo._sigfault, and store the tag bits of FAR_EL1 there,
> > together with a mask specifying which bits are valid.
> >
> > A flag is added to si_faultflags to allow userspace to determine whether
> > the values in the fields are valid.
[...]
> What prevents adding a sigaction sa_flag SA_EXPOSE_TABITS that when set
> causes the high bits to be set, and when clear (the default) will have
> the signal delivery code clear those bits.

Thanks for the review so far Eric.

If the SA_EXPOSE_TAGBITS idea works, I'd much rather have that than the
ultra generic xflags approach.

Given that Peter is going to rework this part, could you please pick the
first clean-up patches via your tree? If there are dependencies with the
reworked arm64 patches, I'm also happy for them to go via your tree.

Thanks.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Peter Collingbourne <pcc@google.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>, Dave Martin <Dave.Martin@arm.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v14 8/8] arm64: expose FAR_EL1 tag bits in siginfo
Date: Thu, 12 Nov 2020 18:53:25 +0000	[thread overview]
Message-ID: <20201112185324.GP29613@gaia> (raw)
In-Reply-To: <87eel2ypy3.fsf@x220.int.ebiederm.org>

On Mon, Nov 09, 2020 at 07:13:08PM -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, create a new pair of
> > fields in siginfo._sigfault, and store the tag bits of FAR_EL1 there,
> > together with a mask specifying which bits are valid.
> >
> > A flag is added to si_faultflags to allow userspace to determine whether
> > the values in the fields are valid.
[...]
> What prevents adding a sigaction sa_flag SA_EXPOSE_TABITS that when set
> causes the high bits to be set, and when clear (the default) will have
> the signal delivery code clear those bits.

Thanks for the review so far Eric.

If the SA_EXPOSE_TAGBITS idea works, I'd much rather have that than the
ultra generic xflags approach.

Given that Peter is going to rework this part, could you please pick the
first clean-up patches via your tree? If there are dependencies with the
reworked arm64 patches, I'm also happy for them to go via your tree.

Thanks.

-- 
Catalin

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

  parent reply	other threads:[~2020-11-12 18:53 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-04 21:18 [PATCH v14 0/8] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-11-04 21:18 ` Peter Collingbourne
2020-11-04 21:18 ` [PATCH v14 1/8] parisc: Drop parisc special case for __sighandler_t Peter Collingbourne
2020-11-04 21:18   ` Peter Collingbourne
2020-11-04 21:18 ` [PATCH v14 2/8] parisc: start using signal-defs.h Peter Collingbourne
2020-11-04 21:18   ` Peter Collingbourne
2020-11-04 21:18 ` [PATCH v14 3/8] arch: move SA_* definitions to generic headers Peter Collingbourne
2020-11-04 21:18   ` Peter Collingbourne
2020-11-04 21:18 ` [PATCH v14 4/8] signal: deduplicate code dealing with common _sigfault fields Peter Collingbourne
2020-11-04 21:18   ` Peter Collingbourne
2020-11-10  0:41   ` Eric W. Biederman
2020-11-10  0:41     ` Eric W. Biederman
2020-11-10  2:37     ` Peter Collingbourne
2020-11-10  2:37       ` Peter Collingbourne
2020-11-10 15:38       ` Eric W. Biederman
2020-11-10 15:38         ` Eric W. Biederman
2020-11-04 21:18 ` [PATCH v14 5/8] signal: clear non-uapi flag bits when passing/returning sa_flags Peter Collingbourne
2020-11-04 21:18   ` Peter Collingbourne
2020-11-10  0:35   ` Eric W. Biederman
2020-11-10  0:35     ` Eric W. Biederman
2020-11-10  2:19     ` Peter Collingbourne
2020-11-10  2:19       ` Peter Collingbourne
2020-11-04 21:18 ` [PATCH v14 6/8] signal: define the SA_UNSUPPORTED bit in sa_flags Peter Collingbourne
2020-11-04 21:18   ` Peter Collingbourne
2020-11-04 21:18 ` [PATCH v14 7/8] signal: define the field siginfo.si_faultflags Peter Collingbourne
2020-11-04 21:18   ` Peter Collingbourne
2020-11-10  1:54   ` Eric W. Biederman
2020-11-10  1:54     ` Eric W. Biederman
2020-11-11 11:10     ` Haren Myneni
2020-11-11 11:10       ` Haren Myneni
2020-11-11 20:46       ` Eric W. Biederman
2020-11-11 20:46         ` Eric W. Biederman
2020-11-10  1:57   ` Eric W. Biederman
2020-11-10  1:57     ` Eric W. Biederman
2020-11-11 17:27     ` Dave Martin
2020-11-11 17:27       ` Dave Martin
2020-11-11 20:15       ` Eric W. Biederman
2020-11-11 20:15         ` Eric W. Biederman
2020-11-11 20:28         ` Eric W. Biederman
2020-11-11 20:28           ` Eric W. Biederman
2020-11-12 17:21           ` Dave Martin
2020-11-12 17:21             ` Dave Martin
2020-11-12 17:23         ` Dave Martin
2020-11-12 17:23           ` Dave Martin
2020-11-12 20:01           ` Eric W. Biederman
2020-11-12 20:01             ` Eric W. Biederman
2020-11-04 21:18 ` [PATCH v14 8/8] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-11-04 21:18   ` Peter Collingbourne
2020-11-10  1:13   ` Eric W. Biederman
2020-11-10  1:13     ` Eric W. Biederman
2020-11-10  3:49     ` Peter Collingbourne
2020-11-10  3:49       ` Peter Collingbourne
2020-11-10 15:12       ` Eric W. Biederman
2020-11-10 15:12         ` Eric W. Biederman
2020-11-10 22:06         ` Peter Collingbourne
2020-11-10 22:06           ` Peter Collingbourne
2020-11-11  7:45           ` Eric W. Biederman
2020-11-11  7:45             ` Eric W. Biederman
2020-11-11 17:46           ` Dave Martin
2020-11-11 17:46             ` Dave Martin
2020-11-12 23:20             ` Peter Collingbourne
2020-11-12 23:20               ` Peter Collingbourne
2020-11-12 18:53     ` Catalin Marinas [this message]
2020-11-12 18:53       ` Catalin Marinas

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=20201112185324.GP29613@gaia \
    --to=catalin.marinas@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=andreyknvl@google.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=rth@twiddle.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.