From: Catalin Marinas <catalin.marinas@arm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: arm64 uaccess series
Date: Tue, 9 Jul 2024 17:52:31 +0100 [thread overview]
Message-ID: <Zo1qz7yzCqCdFlDZ@arm.com> (raw)
In-Reply-To: <20240709161022.1035500-1-torvalds@linux-foundation.org>
On Tue, Jul 09, 2024 at 09:01:58AM -0700, Linus Torvalds wrote:
> This is also available at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git arm64-uaccess
>
> and is three patches, although I expect that I'll only merge the first
> two in the 6.11 merge window because that final one is still a bit
> special.
>
> I've been running variations of this on my Altra machine for the last
> month or more, but admittedly my loads are trivial and uninteresting (ie
> mostly kernel builds). So my test coevrage is not very wide.
I can temporarily pull this branch and 'runtime-constants' into arm64
'for-kernelci'. It's an unstable branch, it doesn't end up in -next.
It's just pointed at by various CI systems to get some wider testing. I
can even pull all four branches if you think it's useful.
> I like the bit 55 checks in that access_ok() rewrite - and they are
> actually simpler than worrying about 64-bit overflow - but they are also
> admittedly quite different from what the code does elsewhere, and
> there's the whole discussion about how the top byte ignore should really
> work.
We are still debating this. I don't think the ABI change is that bad
but, OTOH, user programs with MTE enabled (which would relax the
access_ok()) haven't been tested much. As a kind of precaution, we could
enforce the current behaviour via the sysctl abi.tagged_addr_disabled
and wire it up via a static key. Currently this sysctl only prevents
setting of the TIF_TAGGED_ADDR flag (and implicitly enforces stricter
checks in access_ok()).
--
Catalin
next prev parent reply other threads:[~2024-07-09 16:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-09 16:01 arm64 uaccess series Linus Torvalds
2024-07-09 16:01 ` [PATCH 1/3] arm64: start using 'asm goto' for get_user() when available Linus Torvalds
2024-07-17 16:22 ` GCC asm goto outputs workaround (Was: "Re: [PATCH 1/3] arm64: start using 'asm goto' for get_user() when") available Mark Rutland
2024-07-17 17:54 ` Linus Torvalds
2024-07-17 16:28 ` RESEND: " Mark Rutland
2024-07-17 18:29 ` Linus Torvalds
2024-07-09 16:02 ` [PATCH 2/3] arm64: start using 'asm goto' for put_user() Linus Torvalds
2024-07-09 16:02 ` [PATCH 3/3] arm64: access_ok() optimization Linus Torvalds
2024-07-09 16:52 ` Catalin Marinas [this message]
2024-07-09 17:12 ` arm64 uaccess series Linus Torvalds
2024-07-09 18:30 ` 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=Zo1qz7yzCqCdFlDZ@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=torvalds@linux-foundation.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.