From: Catalin Marinas <catalin.marinas@arm.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
x86@kernel.org, Andrey Ryabinin <aryabinin@virtuozzo.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>, Will Deacon <will@kernel.org>,
"H . J . Lu" <hjl.tools@gmail.com>,
Andi Kleen <ak@linux.intel.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 1/9] mm, arm64: Update PR_SET/GET_TAGGED_ADDR_CTRL interface
Date: Thu, 11 Feb 2021 16:57:49 +0000 [thread overview]
Message-ID: <20210211165748.GA5238@arm.com> (raw)
In-Reply-To: <20210205151631.43511-2-kirill.shutemov@linux.intel.com>
Hi Kirill,
On Fri, Feb 05, 2021 at 06:16:21PM +0300, Kirill A. Shutemov wrote:
> The interface for enabling tagged addresses is very inflexible. It
> implies tag size and tag shift implemented by ARM TBI.
>
> Rework the interface to accommodate different shifts and tag sizes.
>
> PR_SET_TAGGED_ADDR_CTRL now accepts two new arguments:
>
> - nr_bits is pointer to int. The caller specifies the tag size it
> wants. Kernel updates the value of actual tag size that can be
> larger.
>
> - offset is pointer to int. Kernel returns there a shift of tag in the
> address.
OK, so the expectation is that it's not always the top nr_bits (with
offset 64 - nr_bits). We can, for example, have a 4-bit tag with a 56
offset (arm64 MTE is kind like this in terms of meaningful bits but bits
60-63 are also ignored, so it doesn't make a difference from the tagged
address ABI perspective).
Does the offset also need to be validated?
> The change doesn't break existing users of the interface: if any of
> these pointers are NULL (as we had before the change), the user expects
> ARM TBI implementation: nr_bits == 8 && offset == 56 as it was implied
> before.
>
> The initial implementation checked that these argument are NULL and the
> change wouldn't not break any legacy users.
>
> If tagging is enabled, GET_TAGGED_ADDR_CTRL would return size of tags
> and offset in the additional arguments.
>
> If tagging is disable, GET_TAGGED_ADDR_CTRL would return the maximum tag
> size in nr_bits.
Why not the offset as well? I guess I should read a bit on the x86
feature.
> The selftest is updated accordingly and moved out of arm64-specific
> directory as we going to enable the interface on x86.
>
> As alternative to this approach we could introduce a totally new API and
> leave the legacy one as is. But it would slow down adoption: new
> prctl(2) flag wound need to propogate to the userspace headers.
Sharing the same prctl() is fine by me. We helped ourselves to lots of
bits in the first argument already for MTE but I don't think it matters
much. If x86 would need any, they can overlap with the arm64 bits as
they are interpreted in the arch code anyway.
The patch looks fine, though with a couple of nits/questions below:
> @@ -646,25 +652,41 @@ long set_tagged_addr_ctrl(struct task_struct *task, unsigned long arg)
> if (system_supports_mte())
> valid_mask |= PR_MTE_TCF_MASK | PR_MTE_TAG_MASK;
>
> - if (arg & ~valid_mask)
> + if (flags & ~valid_mask)
> return -EINVAL;
>
> + if (nr_bits) {
> + if (get_user(val, nr_bits))
> + return -EFAULT;
> + if (val > TBI_TAG_BITS || val < 1)
> + return -EINVAL;
> + }
Do we need to validate the offset as well?
> +
> /*
> * Do not allow the enabling of the tagged address ABI if globally
> * disabled via sysctl abi.tagged_addr_disabled.
> */
> - if (arg & PR_TAGGED_ADDR_ENABLE && tagged_addr_disabled)
> + if (flags & PR_TAGGED_ADDR_ENABLE && tagged_addr_disabled)
> return -EINVAL;
>
> - if (set_mte_ctrl(task, arg) != 0)
> + if (set_mte_ctrl(task, flags) != 0)
> return -EINVAL;
>
> - update_ti_thread_flag(ti, TIF_TAGGED_ADDR, arg & PR_TAGGED_ADDR_ENABLE);
> + if (flags & PR_TAGGED_ADDR_ENABLE) {
> + if (nr_bits && put_user(TBI_TAG_BITS, nr_bits))
> + return -EFAULT;
> + if (offset && put_user(TBI_TAG_SHIFT, offset))
> + return -EFAULT;
> + }
> +
> + update_ti_thread_flag(ti, TIF_TAGGED_ADDR,
> + flags & PR_TAGGED_ADDR_ENABLE);
>
> return 0;
> }
>
> -long get_tagged_addr_ctrl(struct task_struct *task)
> +long get_tagged_addr_ctrl(struct task_struct *task,
> + int __user *nr_bits, int __user *offset)
> {
> long ret = 0;
> struct thread_info *ti = task_thread_info(task);
> @@ -672,8 +694,17 @@ long get_tagged_addr_ctrl(struct task_struct *task)
> if (is_compat_thread(ti))
> return -EINVAL;
>
> - if (test_ti_thread_flag(ti, TIF_TAGGED_ADDR))
> + if (test_ti_thread_flag(ti, TIF_TAGGED_ADDR)) {
> ret = PR_TAGGED_ADDR_ENABLE;
> + if (nr_bits && put_user(TBI_TAG_BITS, nr_bits))
> + return -EFAULT;
> + if (offset && put_user(TBI_TAG_SHIFT, offset))
> + return -EFAULT;
> + } else {
> + /* Report maximum tag size */
> + if (nr_bits && put_user(TBI_TAG_BITS, nr_bits))
> + return -EFAULT;
> + }
Should this also populate the minimum offset allowed?
--
Catalin
next prev parent reply other threads:[~2021-02-11 16:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-05 15:16 [RFC 0/9] Linear Address Masking enabling Kirill A. Shutemov
2021-02-05 15:16 ` [RFC 1/9] mm, arm64: Update PR_SET/GET_TAGGED_ADDR_CTRL interface Kirill A. Shutemov
2021-02-11 16:57 ` Catalin Marinas [this message]
2021-02-11 17:06 ` Dave Hansen
2021-02-11 18:26 ` Catalin Marinas
2021-02-05 15:16 ` [QEMU] x86: Implement Linear Address Masking support Kirill A. Shutemov
2021-02-05 15:16 ` [RFC 2/9] x86/mm: Fix CR3_ADDR_MASK Kirill A. Shutemov
2021-02-05 15:16 ` [RFC 3/9] x86: CPUID and CR3/CR4 flags for Linear Address Masking Kirill A. Shutemov
2021-02-05 15:16 ` [RFC 4/9] x86/mm: Introduce TIF_LAM_U57 and TIF_LAM_U48 Kirill A. Shutemov
2021-02-05 15:16 ` [RFC 5/9] x86/mm: Provide untagged_addr() helper Kirill A. Shutemov
2021-02-05 15:16 ` [RFC 6/9] x86/uaccess: Remove tags from the address before checking Kirill A. Shutemov
2021-02-05 15:16 ` [RFC 7/9] x86/mm: Handle tagged memory accesses from kernel threads Kirill A. Shutemov
2021-02-05 15:16 ` [RFC 8/9] x86/mm: Make LAM_U48 and mappings above 47-bits mutually exclusive Kirill A. Shutemov
2021-02-05 15:16 ` [RFC 9/9] x86/mm: Implement PR_SET/GET_TAGGED_ADDR_CTRL with LAM Kirill A. Shutemov
2021-02-05 15:42 ` H.J. Lu
2021-02-07 8:07 ` Dmitry Vyukov
2021-02-07 14:09 ` Kirill A. Shutemov
2021-02-07 14:11 ` Dmitry Vyukov
2021-02-05 15:16 ` [QEMU] x86: Implement Linear Address Masking support Kirill A. Shutemov
2021-02-05 15:49 ` [RFC 0/9] Linear Address Masking enabling Peter Zijlstra
2021-02-05 16:01 ` Kirill A. Shutemov
2021-02-05 16:19 ` Peter Zijlstra
2021-02-07 8:24 ` Dmitry Vyukov
2021-02-07 14:11 ` Kirill A. Shutemov
2021-09-21 16:52 ` Dmitry Vyukov
2021-09-21 17:15 ` H.J. Lu
2021-09-22 1:15 ` Zhang, Xiang1
2021-09-22 12:54 ` Dmitry Vyukov
2021-09-22 20:03 ` Dmitry Vyukov
2021-09-22 21:33 ` Kirill A. Shutemov
2021-09-23 0:15 ` H.J. Lu
2021-09-23 5:35 ` Dmitry Vyukov
2021-09-23 0:07 ` H.J. Lu
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=20210211165748.GA5238@arm.com \
--to=catalin.marinas@arm.com \
--cc=ak@linux.intel.com \
--cc=aryabinin@virtuozzo.com \
--cc=dave.hansen@linux.intel.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=hjl.tools@gmail.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
--cc=x86@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).