From: dave.hansen at intel.com (Dave Hansen)
Subject: [PATCH v10 00/12] arm64: untag user pointers passed to the kernel
Date: Tue, 26 Feb 2019 09:35:26 -0800 [thread overview]
Message-ID: <6abc8c6a-c7aa-72ec-8a4e-7dcfeb9ea09b@intel.com> (raw)
In-Reply-To: <CAAeHK+xCi2MxaykYWCz9mwbOzNpjrFcHex7B-VXektNNWBT+Hw@mail.gmail.com>
On 2/26/19 9:18 AM, Andrey Konovalov wrote:
>> This seems like something
>> where we would ideally add an __tagged annotation (or something) to the
>> source tree and then have sparse rules that can look for missed untags.
> This has been suggested before, search for __untagged here [1].
> However there are many places in the kernel where a __user pointer is
> casted into unsigned long and passed further. I'm not sure if it's
> possible apply a __tagged/__untagged kind of attribute to non-pointer
> types, is it?
>
> [1] https://patchwork.kernel.org/patch/10581535/
I believe we have sparse checking __GFP_* flags. We also have a gfp_t
for them and I'm unsure whether the sparse support is tied to _that_ or
whether it's just by tagging the type itself as being part of a discrete
address space.
WARNING: multiple messages have this Message-ID (diff)
From: dave.hansen@intel.com (Dave Hansen)
Subject: [PATCH v10 00/12] arm64: untag user pointers passed to the kernel
Date: Tue, 26 Feb 2019 09:35:26 -0800 [thread overview]
Message-ID: <6abc8c6a-c7aa-72ec-8a4e-7dcfeb9ea09b@intel.com> (raw)
Message-ID: <20190226173526.WWv4Hlbeqp-uLFjHEOxdi2UOQcYRH-tHoA-1IoKY-SU@z> (raw)
In-Reply-To: <CAAeHK+xCi2MxaykYWCz9mwbOzNpjrFcHex7B-VXektNNWBT+Hw@mail.gmail.com>
On 2/26/19 9:18 AM, Andrey Konovalov wrote:
>> This seems like something
>> where we would ideally add an __tagged annotation (or something) to the
>> source tree and then have sparse rules that can look for missed untags.
> This has been suggested before, search for __untagged here [1].
> However there are many places in the kernel where a __user pointer is
> casted into unsigned long and passed further. I'm not sure if it's
> possible apply a __tagged/__untagged kind of attribute to non-pointer
> types, is it?
>
> [1] https://patchwork.kernel.org/patch/10581535/
I believe we have sparse checking __GFP_* flags. We also have a gfp_t
for them and I'm unsure whether the sparse support is tied to _that_ or
whether it's just by tagging the type itself as being part of a discrete
address space.
next prev parent reply other threads:[~2019-02-26 17:35 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-22 12:53 [PATCH v10 00/12] arm64: untag user pointers passed to the kernel andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 01/12] uaccess: add untagged_addr definition for other arches andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 02/12] arm64: untag user pointers in access_ok and __uaccess_mask_ptr andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 03/12] lib, arm64: untag user pointers in strn*_user andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 04/12] mm, arm64: untag user pointers passed to memory syscalls andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 23:07 ` dave.hansen
2019-02-22 23:07 ` Dave Hansen
2019-02-26 14:41 ` andreyknvl
2019-02-26 14:41 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 05/12] mm, arm64: untag user pointers in mm/gup.c andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 06/12] fs, arm64: untag user pointers in copy_mount_options andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 23:03 ` dave.hansen
2019-02-22 23:03 ` Dave Hansen
2019-02-26 14:35 ` andreyknvl
2019-02-26 14:35 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 07/12] fs, arm64: untag user pointers in fs/userfaultfd.c andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 23:05 ` dave.hansen
2019-02-22 23:05 ` Dave Hansen
2019-02-26 14:39 ` andreyknvl
2019-02-26 14:39 ` Andrey Konovalov
2019-03-01 16:59 ` catalin.marinas
2019-03-01 16:59 ` Catalin Marinas
2019-03-01 18:37 ` dave.hansen
2019-03-01 18:37 ` Dave Hansen
2019-03-05 17:47 ` andreyknvl
2019-03-05 17:47 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 08/12] net, arm64: untag user pointers in tcp_zerocopy_receive andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 09/12] kernel, arm64: untag user pointers in prctl_set_mm* andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 10/12] tracing, arm64: untag user pointers in seq_print_user_ip andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 11/12] arm64: update Documentation/arm64/tagged-pointers.txt andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 12:53 ` [PATCH v10 12/12] selftests, arm64: add a selftest for passing tagged pointers to kernel andreyknvl
2019-02-22 12:53 ` Andrey Konovalov
2019-02-22 15:35 ` [PATCH v10 00/12] arm64: untag user pointers passed to the kernel Szabolcs.Nagy
2019-02-22 15:35 ` Szabolcs Nagy
2019-02-22 15:40 ` andreyknvl
2019-02-22 15:40 ` Andrey Konovalov
2019-02-22 16:10 ` Szabolcs.Nagy
2019-02-22 16:10 ` Szabolcs Nagy
2019-02-26 17:00 ` andreyknvl
2019-02-26 17:00 ` Andrey Konovalov
2019-02-22 22:54 ` dave.hansen
2019-02-22 22:54 ` Dave Hansen
2019-02-26 17:18 ` andreyknvl
2019-02-26 17:18 ` Andrey Konovalov
2019-02-26 17:35 ` dave.hansen [this message]
2019-02-26 17:35 ` Dave Hansen
2019-02-26 23:17 ` luc.vanoostenryck
2019-02-26 23:17 ` Luc Van Oostenryck
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=6abc8c6a-c7aa-72ec-8a4e-7dcfeb9ea09b@intel.com \
--to=linux-kselftest@vger.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