From: Will Deacon <will@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Branislav Rankov <Branislav.Rankov@arm.com>,
Szabolcs Nagy <szabolcs.nagy@arm.com>,
andreyknvl@google.com,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
pcc@google.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: mte: Document that user PSTATE.TCO is ignored by kernel uaccess
Date: Mon, 26 Oct 2020 13:14:15 +0000 [thread overview]
Message-ID: <20201026131414.GA24349@willie-the-truck> (raw)
In-Reply-To: <20201026121656.26096-1-catalin.marinas@arm.com>
On Mon, Oct 26, 2020 at 12:16:56PM +0000, Catalin Marinas wrote:
> On exception entry, the kernel explicitly resets the PSTATE.TCO (tag
> check override) so that any kernel memory accesses will be checked (the
> bit is restored on exception return). This has the side-effect that the
> uaccess routines will not honour the PSTATE.TCO that may have been set
> by the user prior to a syscall.
>
> There is no issue in practice since PSTATE.TCO is expected to be used
> only for brief periods in specific routines (e.g. garbage collection).
> To control the tag checking mode of the uaccess routines, the user will
> have to invoke a corresponding prctl() call.
>
> Document the kernel behaviour w.r.t. PSTATE.TCO accordingly.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Fixes: df9d7a22dd21 ("arm64: mte: Add Memory Tagging Extension documentation")
> Cc: Will Deacon <will@kernel.org>
> Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>
> ---
> Documentation/arm64/memory-tagging-extension.rst | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst
> index 034d37c605e8..648f8e8d480b 100644
> --- a/Documentation/arm64/memory-tagging-extension.rst
> +++ b/Documentation/arm64/memory-tagging-extension.rst
> @@ -102,7 +102,9 @@ applications.
> system call) are not checked if the user thread tag checking mode is
> ``PR_MTE_TCF_NONE`` or ``PR_MTE_TCF_ASYNC``. If the tag checking mode is
> ``PR_MTE_TCF_SYNC``, the kernel makes a best effort to check its user
> -address accesses, however it cannot always guarantee it.
> +address accesses, however it cannot always guarantee it. The user
> +``PSTATE.TCO`` bit is ignored by the kernel accesses to user addresses,
> +its value assumed 0.
nit, but the wording feels a bit odd to me here. How about:
Kernel accesses to user addresses are always performed with an effective
PSTATE.TCO value of zero, regardless of the user configuration.
?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-26 13:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20201026121656.26096-1-catalin.marinas@arm.com>
2020-10-26 12:26 ` [PATCH] arm64: mte: Document that user PSTATE.TCO is ignored by kernel uaccess Vincenzo Frascino
2020-10-26 13:14 ` Will Deacon [this message]
2020-10-26 14:18 ` Catalin Marinas
2020-10-27 11:33 ` Szabolcs Nagy
2020-10-27 11:44 ` 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=20201026131414.GA24349@willie-the-truck \
--to=will@kernel.org \
--cc=Branislav.Rankov@arm.com \
--cc=andreyknvl@google.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=pcc@google.com \
--cc=szabolcs.nagy@arm.com \
--cc=vincenzo.frascino@arm.com \
/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