From: Kevin Brodsky <kevin.brodsky@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Alexei Starovoitov <ast@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andrey Konovalov <andreyknvl@google.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Branislav Rankov <Branislav.Rankov@arm.com>,
Chintan Pandya <cpandya@codeaurora.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Dave Martin <Dave.Martin@arm.com>,
"David S. Miller" <davem@davemloft.net>,
Dmitry Vyukov <dvyukov@google.com>,
Eric Dumazet <edumazet@google.com>,
Evgeniy Stepanov <eugenis@google.com>,
Graeme Barnes <Graeme.Barnes@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Ingo Molnar <mingo@kernel.org>,
Jacob Bramley <Jacob.Bramley@arm.com>,
Kate Stewart <kstewart@linuxfoundation.org>,
Kees Cook <keescook@chromium.org>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Kostya Serebryany <kcc@google.com>, Lee Smith <Lee.Smith@arm.com>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
Mark Rutland <mark.rutland@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
Robin Murphy <robin.murphy@arm.com>,
Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
Shuah Khan <shuah@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH v2 2/4] arm64: Define Documentation/arm64/elf_at_flags.txt
Date: Fri, 12 Apr 2019 15:16:19 +0100 [thread overview]
Message-ID: <d2292560-54cf-8dc3-da96-4ccdd72d090e@arm.com> (raw)
In-Reply-To: <20190403165031.GE34351@arrakis.emea.arm.com>
On 03/04/2019 17:50, Catalin Marinas wrote:
> On Fri, Mar 22, 2019 at 03:52:49PM +0000, Kevin Brodsky wrote:
>> On 18/03/2019 16:35, Vincenzo Frascino wrote:
>>> +2. Features exposed via AT_FLAGS
>>> +--------------------------------
>>> +
>>> +bit[0]: ARM64_AT_FLAGS_SYSCALL_TBI
>>> +
>>> + On arm64 the TCR_EL1.TBI0 bit has been always enabled on the arm64
>>> + kernel, hence the userspace (EL0) is allowed to set a non-zero value
>>> + in the top byte but the resulting pointers are not allowed at the
>>> + user-kernel syscall ABI boundary.
>>> + When bit[0] is set to 1 the kernel is advertising to the userspace
>>> + that a relaxed ABI is supported hence this type of pointers are now
>>> + allowed to be passed to the syscalls, when these pointers are in
>>> + memory ranges privately owned by a process and obtained by the
>>> + process in accordance with the definition of "valid tagged pointer"
>>> + in paragraph 3.
>>> + In these cases the tag is preserved as the pointer goes through the
>>> + kernel. Only when the kernel needs to check if a pointer is coming
>>> + from userspace an untag operation is required.
>> I would leave this last sentence out, because:
>> 1. It is an implementation detail that doesn't impact this user ABI.
>> 2. It is not entirely accurate: untagging the pointer may be needed for
>> various kinds of address lookup (like finding the corresponding VMA), at
>> which point the kernel usually already knows it is a userspace pointer.
> I fully agree, the above paragraph should not be part of the user ABI
> document.
>
>>> +3. ARM64_AT_FLAGS_SYSCALL_TBI
>>> +-----------------------------
>>> +
>>> +From the kernel syscall interface prospective, we define, for the purposes
>>> +of this document, a "valid tagged pointer" as a pointer that either it has
>>> +a zero value set in the top byte or it has a non-zero value, it is in memory
>>> +ranges privately owned by a userspace process and it is obtained in one of
>>> +the following ways:
>>> + - mmap() done by the process itself, where either:
>>> + * flags = MAP_PRIVATE | MAP_ANONYMOUS
>>> + * flags = MAP_PRIVATE and the file descriptor refers to a regular
>>> + file or "/dev/zero"
>>> + - a mapping below sbrk(0) done by the process itself
>> I don't think that's very clear, this doesn't say how the mapping is
>> obtained. Maybe "a mapping obtained by the process using brk() or sbrk()"?
> I think what we mean here is anything in the "[heap]" section as per
> /proc/*/maps (in the kernel this would be start_brk to brk).
>
>>> + - any memory mapped by the kernel in the process's address space during
>>> + creation and following the restrictions presented above (i.e. data, bss,
>>> + stack).
>> With the rules above, the code section is included as well. Replacing "i.e."
>> with "e.g." would avoid having to list every single section (which is
>> probably not a good idea anyway).
> We could mention [stack] explicitly as that's documented in the
> Documentation/filesystems/proc.txt and it's likely considered ABI
> already.
>
> The code section is MAP_PRIVATE, and can be done by the dynamic loader
> (user process), so it falls under the mmap() rules listed above. I guess
> we could simply drop "done by the process itself" here and allow
> MAP_PRIVATE|MAP_ANONYMOUS or MAP_PRIVATE of regular file. This would
> cover the [heap] and [stack] and we won't have to debate the brk() case
> at all.
That's probably the best option. I initially used this wording because I was worried
that there could be cases where the kernel allocates "magic" memory for userspace
that is MAP_PRIVATE|MAP_ANONYMOUS, but in fact it's probably not the case (presumably
such mapping should always be done via install_special_mapping(), which is definitely
not MAP_PRIVATE).
> We probably mention somewhere (or we should in the tagged pointers doc)
> that we don't support tagged PC.
I think that Documentation/arm64/tagged-pointers.txt already makes it reasonably
clear (anyway, with the architecture not supporting it, you can't expect much from
the kernel).
Kevin
next prev parent reply other threads:[~2019-04-12 14:16 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 19:51 [PATCH v11 00/14] arm64: untag user pointers passed to the kernel Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 01/14] uaccess: add untagged_addr definition for other arches Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 02/14] arm64: untag user pointers in access_ok and __uaccess_mask_ptr Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 03/14] lib, arm64: untag user pointers in strn*_user Andrey Konovalov
2019-03-18 11:33 ` Kevin Brodsky
2019-03-15 19:51 ` [PATCH v11 04/14] mm, arm64: untag user pointers passed to memory syscalls Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 05/14] mm, arm64: untag user pointers in mm/gup.c Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 06/14] fs, arm64: untag user pointers in copy_mount_options Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 07/14] fs, arm64: untag user pointers in fs/userfaultfd.c Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 08/14] net, arm64: untag user pointers in tcp_zerocopy_receive Andrey Konovalov
2019-03-15 20:03 ` Eric Dumazet
2019-03-18 13:14 ` Andrey Konovalov
2019-03-18 13:16 ` Andrey Konovalov
2019-03-18 14:44 ` Eric Dumazet
2019-03-18 16:08 ` Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 09/14] kernel, arm64: untag user pointers in prctl_set_mm* Andrey Konovalov
2019-03-18 11:47 ` Kevin Brodsky
2019-03-18 16:53 ` Andrey Konovalov
[not found] ` <201903170317.IWsOYXBe%lkp@intel.com>
2019-03-18 16:53 ` Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 10/14] tracing, arm64: untag user pointers in seq_print_user_ip Andrey Konovalov
2019-03-15 20:14 ` Steven Rostedt
2019-03-18 13:11 ` Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 11/14] uprobes, arm64: untag user pointers in find_active_uprobe Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 12/14] bpf, arm64: untag user pointers in stack_map_get_build_id_offset Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 13/14] arm64: update Documentation/arm64/tagged-pointers.txt Andrey Konovalov
2019-03-18 13:26 ` Kevin Brodsky
2019-03-18 16:59 ` Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 14/14] selftests, arm64: add a selftest for passing tagged pointers to kernel Andrey Konovalov
2019-03-18 16:35 ` [PATCH v2 0/4] arm64 relaxed ABI Vincenzo Frascino
2019-03-18 16:35 ` [PATCH v2 1/4] elf: Make AT_FLAGS arch configurable Vincenzo Frascino
2019-03-18 16:35 ` [PATCH v2 2/4] arm64: Define Documentation/arm64/elf_at_flags.txt Vincenzo Frascino
2019-03-22 6:22 ` Amit Daniel Kachhap
2019-03-22 10:48 ` Catalin Marinas
2019-03-22 15:52 ` Kevin Brodsky
2019-04-03 16:50 ` Catalin Marinas
2019-04-12 14:16 ` Kevin Brodsky [this message]
2019-03-18 16:35 ` [PATCH v2 3/4] arm64: Relax Documentation/arm64/tagged-pointers.txt Vincenzo Frascino
2019-03-18 16:35 ` [PATCH v2 4/4] arm64: elf: Advertise relaxed ABI Vincenzo Frascino
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=d2292560-54cf-8dc3-da96-4ccdd72d090e@arm.com \
--to=kevin.brodsky@arm.com \
--cc=Branislav.Rankov@arm.com \
--cc=Dave.Martin@arm.com \
--cc=Graeme.Barnes@arm.com \
--cc=Jacob.Bramley@arm.com \
--cc=Lee.Smith@arm.com \
--cc=Ramana.Radhakrishnan@arm.com \
--cc=Ruben.Ayrapetyan@arm.com \
--cc=Szabolcs.Nagy@arm.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@google.com \
--cc=ast@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=cpandya@codeaurora.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=edumazet@google.com \
--cc=eugenis@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kcc@google.com \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=kstewart@linuxfoundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luc.vanoostenryck@gmail.com \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=robin.murphy@arm.com \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=vincenzo.frascino@arm.com \
--cc=viro@zeniv.linux.org.uk \
--cc=will.deacon@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;
as well as URLs for NNTP newsgroup(s).