From: Catalin Marinas <catalin.marinas@arm.com> To: Andrey Konovalov <andreyknvl@google.com> Cc: Mark Rutland <mark.rutland@arm.com>, Kate Stewart <kstewart@linuxfoundation.org>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, Will Deacon <will.deacon@arm.com>, Kostya Serebryany <kcc@google.com>, "open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@vger.kernel.org>, Chintan Pandya <cpandya@codeaurora.org>, Shuah Khan <shuah@kernel.org>, Ingo Molnar <mingo@kernel.org>, linux-arch <linux-arch@vger.kernel.org>, Jacob Bramley <Jacob.Bramley@arm.com>, Dmitry Vyukov <dvyukov@google.com>, Evgeniy Stepanov <eugenis@google.com>, Kees Cook <keescook@chromium.org>, Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>, Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>Linux Memory Management List <linux-> Subject: Re: [PATCH v7 7/8] arm64: update Documentation/arm64/tagged-pointers.txt Date: Thu, 18 Oct 2018 18:31:36 +0100 [thread overview] Message-ID: <20181018173135.GF237391@arrakis.emea.arm.com> (raw) In-Reply-To: <CAAeHK+yPCRNAOSi6OpYC_Tdbo9SoXRVRbx8pjXNq96v8csO-Wg@mail.gmail.com> On Wed, Oct 10, 2018 at 04:09:25PM +0200, Andrey Konovalov wrote: > On Wed, Oct 3, 2018 at 7:32 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Tue, Oct 02, 2018 at 03:12:42PM +0200, Andrey Konovalov wrote: [...] > > Also, how is user space supposed to know that it can now pass tagged > > pointers into the kernel? An ABI change (or relaxation), needs to be > > advertised by the kernel, usually via a new HWCAP bit (e.g. HWCAP_TBI). > > Once we have a HWCAP bit in place, we need to be pretty clear about > > which syscalls can and cannot cope with tagged pointers. The "as of now" > > implies potential further relaxation which, again, would need to be > > advertised to user in some (additional) way. > > How exactly should I do that? Something like this [1]? Or is it only > for hardware specific things and for this patchset I need to do > something else? > > [1] https://github.com/torvalds/linux/commit/7206dc93a58fb76421c4411eefa3c003337bcb2d Thinking some more on this, we should probably keep the HWCAP_* bits for actual hardware features. Maybe someone else has a better idea (the linux-abi list?). An option would be to make use of AT_FLAGS auxv (currently 0) in Linux. I've seen some MIPS patches in the past but nothing upstream. Yet another option would be for the user to probe on some innocuous syscall currently returning -EFAULT on tagged pointer arguments but I don't particularly like this. > >> - - pointer arguments to system calls, including pointers in structures > >> - passed to system calls, > >> + - pointer arguments (including pointers in structures), which don't > >> + describe virtual memory ranges, passed to system calls > > > > I think we need to be more precise here... > > In what way? In the way of being explicit about which syscalls support tagged pointers, unless we find a good reason to support tagged pointers on all syscalls and avoid any lists. -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com> To: Andrey Konovalov <andreyknvl@google.com> Cc: Mark Rutland <mark.rutland@arm.com>, Kate Stewart <kstewart@linuxfoundation.org>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>, Will Deacon <will.deacon@arm.com>, Kostya Serebryany <kcc@google.com>, "open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@vger.kernel.org>, Chintan Pandya <cpandya@codeaurora.org>, Shuah Khan <shuah@kernel.org>, Ingo Molnar <mingo@kernel.org>, linux-arch <linux-arch@vger.kernel.org>, Jacob Bramley <Jacob.Bramley@arm.com>, Dmitry Vyukov <dvyukov@google.com>, Evgeniy Stepanov <eugenis@google.com>, Kees Cook <keescook@chromium.org>, Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>, Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux Memory Management List <linux-mm@kvack.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, LKML <linux-kernel@vger.kernel.org>, Luc Van Oostenryck <luc.vanoostenryck@gmail.com>, Lee Smith <Lee.Smith@arm.com>, Andrew Morton <akpm@linux-foundation.org>, Robin Murphy <robin.murphy@arm.com>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Subject: Re: [PATCH v7 7/8] arm64: update Documentation/arm64/tagged-pointers.txt Date: Thu, 18 Oct 2018 18:31:36 +0100 [thread overview] Message-ID: <20181018173135.GF237391@arrakis.emea.arm.com> (raw) Message-ID: <20181018173136.N7omMi6JRBiMNxZ7OtNp1_03n8rj5sRrQraMDkaxUpo@z> (raw) In-Reply-To: <CAAeHK+yPCRNAOSi6OpYC_Tdbo9SoXRVRbx8pjXNq96v8csO-Wg@mail.gmail.com> On Wed, Oct 10, 2018 at 04:09:25PM +0200, Andrey Konovalov wrote: > On Wed, Oct 3, 2018 at 7:32 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On Tue, Oct 02, 2018 at 03:12:42PM +0200, Andrey Konovalov wrote: [...] > > Also, how is user space supposed to know that it can now pass tagged > > pointers into the kernel? An ABI change (or relaxation), needs to be > > advertised by the kernel, usually via a new HWCAP bit (e.g. HWCAP_TBI). > > Once we have a HWCAP bit in place, we need to be pretty clear about > > which syscalls can and cannot cope with tagged pointers. The "as of now" > > implies potential further relaxation which, again, would need to be > > advertised to user in some (additional) way. > > How exactly should I do that? Something like this [1]? Or is it only > for hardware specific things and for this patchset I need to do > something else? > > [1] https://github.com/torvalds/linux/commit/7206dc93a58fb76421c4411eefa3c003337bcb2d Thinking some more on this, we should probably keep the HWCAP_* bits for actual hardware features. Maybe someone else has a better idea (the linux-abi list?). An option would be to make use of AT_FLAGS auxv (currently 0) in Linux. I've seen some MIPS patches in the past but nothing upstream. Yet another option would be for the user to probe on some innocuous syscall currently returning -EFAULT on tagged pointer arguments but I don't particularly like this. > >> - - pointer arguments to system calls, including pointers in structures > >> - passed to system calls, > >> + - pointer arguments (including pointers in structures), which don't > >> + describe virtual memory ranges, passed to system calls > > > > I think we need to be more precise here... > > In what way? In the way of being explicit about which syscalls support tagged pointers, unless we find a good reason to support tagged pointers on all syscalls and avoid any lists. -- Catalin
next prev parent reply other threads:[~2018-10-18 17:31 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-02 13:12 [PATCH v7 0/8] arm64: untag user pointers passed to the kernel Andrey Konovalov 2018-10-02 13:12 ` Andrey Konovalov 2018-10-02 13:12 ` [PATCH v7 1/8] arm64: add type casts to untagged_addr macro Andrey Konovalov 2018-10-02 13:12 ` Andrey Konovalov 2018-10-02 13:12 ` [PATCH v7 2/8] uaccess: add untagged_addr definition for other arches Andrey Konovalov 2018-10-02 13:12 ` Andrey Konovalov 2018-10-02 13:12 ` [PATCH v7 3/8] arm64: untag user addresses in access_ok and __uaccess_mask_ptr Andrey Konovalov 2018-10-02 13:12 ` Andrey Konovalov 2018-10-02 13:12 ` [PATCH v7 4/8] mm, arm64: untag user addresses in mm/gup.c Andrey Konovalov 2018-10-02 13:12 ` Andrey Konovalov 2018-10-02 13:12 ` [PATCH v7 5/8] lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user Andrey Konovalov 2018-10-02 13:12 ` Andrey Konovalov 2018-10-02 13:12 ` [PATCH v7 6/8] fs, arm64: untag user address in copy_mount_options Andrey Konovalov 2018-10-02 13:12 ` Andrey Konovalov 2018-10-02 13:12 ` [PATCH v7 7/8] arm64: update Documentation/arm64/tagged-pointers.txt Andrey Konovalov 2018-10-02 13:12 ` Andrey Konovalov 2018-10-03 17:32 ` Catalin Marinas 2018-10-03 17:32 ` Catalin Marinas 2018-10-10 14:09 ` Andrey Konovalov 2018-10-10 14:09 ` Andrey Konovalov 2018-10-18 17:31 ` Catalin Marinas [this message] 2018-10-18 17:31 ` Catalin Marinas 2018-10-02 13:12 ` [PATCH v7 8/8] selftests, arm64: add a selftest for passing tagged pointers to kernel Andrey Konovalov 2018-10-02 13:12 ` Andrey Konovalov 2018-10-03 13:31 ` [PATCH v7 0/8] arm64: untag user pointers passed to the kernel Luc Van Oostenryck 2018-10-03 13:31 ` Luc Van Oostenryck 2018-10-17 14:06 ` Vincenzo Frascino 2018-10-17 14:06 ` Vincenzo Frascino 2018-10-17 14:20 ` Andrey Konovalov 2018-10-17 14:20 ` Andrey Konovalov 2018-10-17 20:25 ` Evgenii Stepanov 2018-10-17 20:25 ` Evgenii Stepanov 2018-10-18 17:33 ` Catalin Marinas 2018-10-18 17:33 ` Catalin Marinas 2018-10-19 9:04 ` Vincenzo Frascino 2018-10-19 9:04 ` 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=20181018173135.GF237391@arrakis.emea.arm.com \ --to=catalin.marinas@arm.com \ --cc=Jacob.Bramley@arm.com \ --cc=Ramana.Radhakrishnan@arm.com \ --cc=Ruben.Ayrapetyan@arm.com \ --cc=andreyknvl@google.com \ --cc=cpandya@codeaurora.org \ --cc=dvyukov@google.com \ --cc=eugenis@google.com \ --cc=kcc@google.com \ --cc=keescook@chromium.org \ --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-kselftest@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=mingo@kernel.org \ --cc=shuah@kernel.org \ --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: linkBe 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).