All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2023-05-17 18:39 Parlett23
  0 siblings, 0 replies; 153+ messages in thread
From: Parlett23 @ 2023-05-17 18:39 UTC (permalink / raw)
  To: catalin.marinas
  Cc: Jacob.Bramley, Lee.Smith, Mark.Rutland, Robin.Murphy,
	Ruben.Ayrapetyan, Will.Deacon, akpm, andreyknvl, cpandya,
	dvyukov, eugenis, gregkh, kcc, keescook, kirill.shutemov,
	kstewart, linux-arch, linux-arm-kernel, linux-doc, linux-kernel,
	linux-kselftest, linux-mm, luc.vanoostenryck, mingo, nd,
	ramana.radhakrishnan, shuah, viro

[-- Attachment #1: Type: text/plain, Size: 28 bytes --]

Sent from Proton Mail mobile

[-- Attachment #2: Type: text/html, Size: 52 bytes --]

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-08-03 15:09                   ` Greg Kroah-Hartman
                                       ` (3 preceding siblings ...)
  (?)
@ 2018-08-06 19:12                     ` Luc Van Oostenryck
  -1 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-08-06 19:12 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Andrey Konovalov, Catalin Marinas, Mark Rutland, Kate Stewart,
	linux-doc, Will Deacon, Kostya Serebryany, linux-kselftest,
	Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
	Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov, Kees Cook,
	Ruben Ayrapetyan, Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, LKML, Lee Smith, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov, Matthew Wilcox

On Fri, Aug 3, 2018 at 5:09 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
>> On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> >> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>> >>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> >>> So the checker reports ~100 different places where a __user pointer
>> >>> being casted. I've looked through them and found 3 places where we
>> >>> need to add untagging. Source code lines below come from 4.18-rc2+
>> >>> (6f0d349d).
>> >> [...]
>> >>> I'll add the 3 patches with fixes to v5 of this patchset.
>> >>
>> >> Thanks for investigating. You can fix those three places in your code
>> >
>> > OK, will do.
>> >
>> >> but I was rather looking for a way to check such casting in the future
>> >> for newly added code. While for the khwasan we can assume it's a debug
>> >> option, the tagged user pointers are ABI and we need to keep it stable.
>> >>
>> >> We could we actually add some macros for explicit conversion between
>> >> __user ptr and long and silence the warning there (I guess this would
>> >> work better for sparse). We can then detect new ptr to long casts as
>> >> they appear. I just hope that's not too intrusive.
>> >>
>> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
>> >
>> > Haven't look at that sparse patch yet myself, but sounds doable.
>> > Should these macros go into this patchset or should they go
>> > separately?
>>
>> Started looking at this. When I run sparse with default checks enabled
>> (make C=1) I get countless warnings. Does anybody actually use it?
>
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...
>
> greg k-h
>

Quoting Linus in [1]:

Honestly, I'd like to just encourage people to get the sparse update
from Luc Van Oostenryck instead.

For a while there it looked like Chris Li would just pull from Luc,
and we'd have timely releases, but that really doesn't seem to have
ended up happening after all. So right now it's probably just best to
get Luc's tree instead from

    https://github.com/lucvoo/sparse-dev

which also ends up fixing a lot of other issues.

[1] https://lore.kernel.org/lkml/CA+55aFzYEnZR2GZLR-DwpONjMNYGYoDy+6AWLCVNayWiaZuqoA@mail.gmail.com/T/#u

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-06 19:12                     ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-08-06 19:12 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Andrey Konovalov, Catalin Marinas, Mark Rutland, Kate Stewart,
	linux-doc, Will Deacon, Kostya Serebryany, linux-kselftest,
	Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
	Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov, Kees Cook,
	Ruben Ayrapetyan, Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, LKML, Lee Smith, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov, Matthew Wilcox

On Fri, Aug 3, 2018 at 5:09 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
>> On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> >> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>> >>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> >>> So the checker reports ~100 different places where a __user pointer
>> >>> being casted. I've looked through them and found 3 places where we
>> >>> need to add untagging. Source code lines below come from 4.18-rc2+
>> >>> (6f0d349d).
>> >> [...]
>> >>> I'll add the 3 patches with fixes to v5 of this patchset.
>> >>
>> >> Thanks for investigating. You can fix those three places in your code
>> >
>> > OK, will do.
>> >
>> >> but I was rather looking for a way to check such casting in the future
>> >> for newly added code. While for the khwasan we can assume it's a debug
>> >> option, the tagged user pointers are ABI and we need to keep it stable.
>> >>
>> >> We could we actually add some macros for explicit conversion between
>> >> __user ptr and long and silence the warning there (I guess this would
>> >> work better for sparse). We can then detect new ptr to long casts as
>> >> they appear. I just hope that's not too intrusive.
>> >>
>> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
>> >
>> > Haven't look at that sparse patch yet myself, but sounds doable.
>> > Should these macros go into this patchset or should they go
>> > separately?
>>
>> Started looking at this. When I run sparse with default checks enabled
>> (make C=1) I get countless warnings. Does anybody actually use it?
>
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...
>
> greg k-h
>

Quoting Linus in [1]:

Honestly, I'd like to just encourage people to get the sparse update
from Luc Van Oostenryck instead.

For a while there it looked like Chris Li would just pull from Luc,
and we'd have timely releases, but that really doesn't seem to have
ended up happening after all. So right now it's probably just best to
get Luc's tree instead from

    https://github.com/lucvoo/sparse-dev

which also ends up fixing a lot of other issues.

[1] https://lore.kernel.org/lkml/CA+55aFzYEnZR2GZLR-DwpONjMNYGYoDy+6AWLCVNayWiaZuqoA@mail.gmail.com/T/#u
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-06 19:12                     ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: luc.vanoostenryck @ 2018-08-06 19:12 UTC (permalink / raw)


On Fri, Aug 3, 2018 at 5:09 PM, Greg Kroah-Hartman
<gregkh at linuxfoundation.org> wrote:
> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
>> On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
>> > On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>> >>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
>> >>> So the checker reports ~100 different places where a __user pointer
>> >>> being casted. I've looked through them and found 3 places where we
>> >>> need to add untagging. Source code lines below come from 4.18-rc2+
>> >>> (6f0d349d).
>> >> [...]
>> >>> I'll add the 3 patches with fixes to v5 of this patchset.
>> >>
>> >> Thanks for investigating. You can fix those three places in your code
>> >
>> > OK, will do.
>> >
>> >> but I was rather looking for a way to check such casting in the future
>> >> for newly added code. While for the khwasan we can assume it's a debug
>> >> option, the tagged user pointers are ABI and we need to keep it stable.
>> >>
>> >> We could we actually add some macros for explicit conversion between
>> >> __user ptr and long and silence the warning there (I guess this would
>> >> work better for sparse). We can then detect new ptr to long casts as
>> >> they appear. I just hope that's not too intrusive.
>> >>
>> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
>> >
>> > Haven't look at that sparse patch yet myself, but sounds doable.
>> > Should these macros go into this patchset or should they go
>> > separately?
>>
>> Started looking at this. When I run sparse with default checks enabled
>> (make C=1) I get countless warnings. Does anybody actually use it?
>
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...
>
> greg k-h
>

Quoting Linus in [1]:

Honestly, I'd like to just encourage people to get the sparse update
from Luc Van Oostenryck instead.

For a while there it looked like Chris Li would just pull from Luc,
and we'd have timely releases, but that really doesn't seem to have
ended up happening after all. So right now it's probably just best to
get Luc's tree instead from

    https://github.com/lucvoo/sparse-dev

which also ends up fixing a lot of other issues.

[1] https://lore.kernel.org/lkml/CA+55aFzYEnZR2GZLR-DwpONjMNYGYoDy+6AWLCVNayWiaZuqoA at mail.gmail.com/T/#u
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-06 19:12                     ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-08-06 19:12 UTC (permalink / raw)


On Fri, Aug 3, 2018 at 5:09 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Aug 03, 2018@04:59:18PM +0200, Andrey Konovalov wrote:
>> On Thu, Aug 2, 2018@5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > On Wed, Aug 1, 2018@7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> >> On Mon, Jul 16, 2018@01:25:59PM +0200, Andrey Konovalov wrote:
>> >>> On Thu, Jun 28, 2018@9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> >>> So the checker reports ~100 different places where a __user pointer
>> >>> being casted. I've looked through them and found 3 places where we
>> >>> need to add untagging. Source code lines below come from 4.18-rc2+
>> >>> (6f0d349d).
>> >> [...]
>> >>> I'll add the 3 patches with fixes to v5 of this patchset.
>> >>
>> >> Thanks for investigating. You can fix those three places in your code
>> >
>> > OK, will do.
>> >
>> >> but I was rather looking for a way to check such casting in the future
>> >> for newly added code. While for the khwasan we can assume it's a debug
>> >> option, the tagged user pointers are ABI and we need to keep it stable.
>> >>
>> >> We could we actually add some macros for explicit conversion between
>> >> __user ptr and long and silence the warning there (I guess this would
>> >> work better for sparse). We can then detect new ptr to long casts as
>> >> they appear. I just hope that's not too intrusive.
>> >>
>> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
>> >
>> > Haven't look at that sparse patch yet myself, but sounds doable.
>> > Should these macros go into this patchset or should they go
>> > separately?
>>
>> Started looking at this. When I run sparse with default checks enabled
>> (make C=1) I get countless warnings. Does anybody actually use it?
>
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...
>
> greg k-h
>

Quoting Linus in [1]:

Honestly, I'd like to just encourage people to get the sparse update
from Luc Van Oostenryck instead.

For a while there it looked like Chris Li would just pull from Luc,
and we'd have timely releases, but that really doesn't seem to have
ended up happening after all. So right now it's probably just best to
get Luc's tree instead from

    https://github.com/lucvoo/sparse-dev

which also ends up fixing a lot of other issues.

[1] https://lore.kernel.org/lkml/CA+55aFzYEnZR2GZLR-DwpONjMNYGYoDy+6AWLCVNayWiaZuqoA at mail.gmail.com/T/#u
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-06 19:12                     ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-08-06 19:12 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Andrey Konovalov, Catalin Marinas, Mark Rutland, Kate Stewart,
	linux-doc, Will Deacon, Kostya Serebryany, linux-kselftest,
	Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
	Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov, Kees Cook,
	Ruben Ayrapetyan, Ramana Radhakrishnan, Al Viro, Linux ARM

On Fri, Aug 3, 2018 at 5:09 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
>> On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> >> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>> >>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> >>> So the checker reports ~100 different places where a __user pointer
>> >>> being casted. I've looked through them and found 3 places where we
>> >>> need to add untagging. Source code lines below come from 4.18-rc2+
>> >>> (6f0d349d).
>> >> [...]
>> >>> I'll add the 3 patches with fixes to v5 of this patchset.
>> >>
>> >> Thanks for investigating. You can fix those three places in your code
>> >
>> > OK, will do.
>> >
>> >> but I was rather looking for a way to check such casting in the future
>> >> for newly added code. While for the khwasan we can assume it's a debug
>> >> option, the tagged user pointers are ABI and we need to keep it stable.
>> >>
>> >> We could we actually add some macros for explicit conversion between
>> >> __user ptr and long and silence the warning there (I guess this would
>> >> work better for sparse). We can then detect new ptr to long casts as
>> >> they appear. I just hope that's not too intrusive.
>> >>
>> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
>> >
>> > Haven't look at that sparse patch yet myself, but sounds doable.
>> > Should these macros go into this patchset or should they go
>> > separately?
>>
>> Started looking at this. When I run sparse with default checks enabled
>> (make C=1) I get countless warnings. Does anybody actually use it?
>
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...
>
> greg k-h
>

Quoting Linus in [1]:

Honestly, I'd like to just encourage people to get the sparse update
from Luc Van Oostenryck instead.

For a while there it looked like Chris Li would just pull from Luc,
and we'd have timely releases, but that really doesn't seem to have
ended up happening after all. So right now it's probably just best to
get Luc's tree instead from

    https://github.com/lucvoo/sparse-dev

which also ends up fixing a lot of other issues.

[1] https://lore.kernel.org/lkml/CA+55aFzYEnZR2GZLR-DwpONjMNYGYoDy+6AWLCVNayWiaZuqoA@mail.gmail.com/T/#u

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-06 19:12                     ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-08-06 19:12 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Aug 3, 2018 at 5:09 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
>> On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> >> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>> >>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> >>> So the checker reports ~100 different places where a __user pointer
>> >>> being casted. I've looked through them and found 3 places where we
>> >>> need to add untagging. Source code lines below come from 4.18-rc2+
>> >>> (6f0d349d).
>> >> [...]
>> >>> I'll add the 3 patches with fixes to v5 of this patchset.
>> >>
>> >> Thanks for investigating. You can fix those three places in your code
>> >
>> > OK, will do.
>> >
>> >> but I was rather looking for a way to check such casting in the future
>> >> for newly added code. While for the khwasan we can assume it's a debug
>> >> option, the tagged user pointers are ABI and we need to keep it stable.
>> >>
>> >> We could we actually add some macros for explicit conversion between
>> >> __user ptr and long and silence the warning there (I guess this would
>> >> work better for sparse). We can then detect new ptr to long casts as
>> >> they appear. I just hope that's not too intrusive.
>> >>
>> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
>> >
>> > Haven't look at that sparse patch yet myself, but sounds doable.
>> > Should these macros go into this patchset or should they go
>> > separately?
>>
>> Started looking at this. When I run sparse with default checks enabled
>> (make C=1) I get countless warnings. Does anybody actually use it?
>
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...
>
> greg k-h
>

Quoting Linus in [1]:

Honestly, I'd like to just encourage people to get the sparse update
from Luc Van Oostenryck instead.

For a while there it looked like Chris Li would just pull from Luc,
and we'd have timely releases, but that really doesn't seem to have
ended up happening after all. So right now it's probably just best to
get Luc's tree instead from

    https://github.com/lucvoo/sparse-dev

which also ends up fixing a lot of other issues.

[1] https://lore.kernel.org/lkml/CA+55aFzYEnZR2GZLR-DwpONjMNYGYoDy+6AWLCVNayWiaZuqoA at mail.gmail.com/T/#u

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-08-03 16:43                     ` Matthew Wilcox
                                         ` (3 preceding siblings ...)
  (?)
@ 2018-08-03 16:54                       ` Andrey Konovalov
  -1 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-03 16:54 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Greg Kroah-Hartman, Catalin Marinas, Mark Rutland, Kate Stewart,
	linux-doc, Will Deacon, Kostya Serebryany, linux-kselftest,
	Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
	Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov, Kees Cook,
	Ruben Ayrapetyan, Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, LKML, Lee Smith, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov

On Fri, Aug 3, 2018 at 6:43 PM, Matthew Wilcox <willy@infradead.org> wrote:
> On Fri, Aug 03, 2018 at 05:09:45PM +0200, Greg Kroah-Hartman wrote:
>> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
>> > Started looking at this. When I run sparse with default checks enabled
>> > (make C=1) I get countless warnings. Does anybody actually use it?
>>
>> Try using a more up-to-date version of sparse.  Odds are you are using
>> an old one, there is a newer version in a different branch on kernel.org
>> somewhere...
>
> That's not true.  Building the current version of sparse from
> git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
> thousand errors just building the mm/ directory.  A sample:

I'm running the one from https://github.com/lucvoo/sparse-dev which
seems to be even more up to date. Defconfig on x86 gives me ~3000
warnings:

https://gist.github.com/xairy/8adace989f64462e18ffb5cb7d096b73

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 16:54                       ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-03 16:54 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Greg Kroah-Hartman, Catalin Marinas, Mark Rutland, Kate Stewart,
	linux-doc, Will Deacon, Kostya Serebryany, linux-kselftest,
	Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
	Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov, Kees Cook,
	Ruben Ayrapetyan, Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, LKML, Lee Smith, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov

On Fri, Aug 3, 2018 at 6:43 PM, Matthew Wilcox <willy@infradead.org> wrote:
> On Fri, Aug 03, 2018 at 05:09:45PM +0200, Greg Kroah-Hartman wrote:
>> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
>> > Started looking at this. When I run sparse with default checks enabled
>> > (make C=1) I get countless warnings. Does anybody actually use it?
>>
>> Try using a more up-to-date version of sparse.  Odds are you are using
>> an old one, there is a newer version in a different branch on kernel.org
>> somewhere...
>
> That's not true.  Building the current version of sparse from
> git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
> thousand errors just building the mm/ directory.  A sample:

I'm running the one from https://github.com/lucvoo/sparse-dev which
seems to be even more up to date. Defconfig on x86 gives me ~3000
warnings:

https://gist.github.com/xairy/8adace989f64462e18ffb5cb7d096b73
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 16:54                       ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: andreyknvl @ 2018-08-03 16:54 UTC (permalink / raw)


On Fri, Aug 3, 2018 at 6:43 PM, Matthew Wilcox <willy at infradead.org> wrote:
> On Fri, Aug 03, 2018 at 05:09:45PM +0200, Greg Kroah-Hartman wrote:
>> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
>> > Started looking at this. When I run sparse with default checks enabled
>> > (make C=1) I get countless warnings. Does anybody actually use it?
>>
>> Try using a more up-to-date version of sparse.  Odds are you are using
>> an old one, there is a newer version in a different branch on kernel.org
>> somewhere...
>
> That's not true.  Building the current version of sparse from
> git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
> thousand errors just building the mm/ directory.  A sample:

I'm running the one from https://github.com/lucvoo/sparse-dev which
seems to be even more up to date. Defconfig on x86 gives me ~3000
warnings:

https://gist.github.com/xairy/8adace989f64462e18ffb5cb7d096b73
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 16:54                       ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-03 16:54 UTC (permalink / raw)


On Fri, Aug 3, 2018@6:43 PM, Matthew Wilcox <willy@infradead.org> wrote:
> On Fri, Aug 03, 2018@05:09:45PM +0200, Greg Kroah-Hartman wrote:
>> On Fri, Aug 03, 2018@04:59:18PM +0200, Andrey Konovalov wrote:
>> > Started looking at this. When I run sparse with default checks enabled
>> > (make C=1) I get countless warnings. Does anybody actually use it?
>>
>> Try using a more up-to-date version of sparse.  Odds are you are using
>> an old one, there is a newer version in a different branch on kernel.org
>> somewhere...
>
> That's not true.  Building the current version of sparse from
> git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
> thousand errors just building the mm/ directory.  A sample:

I'm running the one from https://github.com/lucvoo/sparse-dev which
seems to be even more up to date. Defconfig on x86 gives me ~3000
warnings:

https://gist.github.com/xairy/8adace989f64462e18ffb5cb7d096b73
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 16:54                       ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-03 16:54 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Greg Kroah-Hartman, Catalin Marinas, Mark Rutland, Kate Stewart,
	linux-doc, Will Deacon, Kostya Serebryany, linux-kselftest,
	Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
	Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov, Kees Cook,
	Ruben Ayrapetyan, Ramana Radhakrishnan, Al Viro, Linux ARM

On Fri, Aug 3, 2018 at 6:43 PM, Matthew Wilcox <willy@infradead.org> wrote:
> On Fri, Aug 03, 2018 at 05:09:45PM +0200, Greg Kroah-Hartman wrote:
>> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
>> > Started looking at this. When I run sparse with default checks enabled
>> > (make C=1) I get countless warnings. Does anybody actually use it?
>>
>> Try using a more up-to-date version of sparse.  Odds are you are using
>> an old one, there is a newer version in a different branch on kernel.org
>> somewhere...
>
> That's not true.  Building the current version of sparse from
> git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
> thousand errors just building the mm/ directory.  A sample:

I'm running the one from https://github.com/lucvoo/sparse-dev which
seems to be even more up to date. Defconfig on x86 gives me ~3000
warnings:

https://gist.github.com/xairy/8adace989f64462e18ffb5cb7d096b73

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 16:54                       ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-03 16:54 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Aug 3, 2018 at 6:43 PM, Matthew Wilcox <willy@infradead.org> wrote:
> On Fri, Aug 03, 2018 at 05:09:45PM +0200, Greg Kroah-Hartman wrote:
>> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
>> > Started looking at this. When I run sparse with default checks enabled
>> > (make C=1) I get countless warnings. Does anybody actually use it?
>>
>> Try using a more up-to-date version of sparse.  Odds are you are using
>> an old one, there is a newer version in a different branch on kernel.org
>> somewhere...
>
> That's not true.  Building the current version of sparse from
> git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
> thousand errors just building the mm/ directory.  A sample:

I'm running the one from https://github.com/lucvoo/sparse-dev which
seems to be even more up to date. Defconfig on x86 gives me ~3000
warnings:

https://gist.github.com/xairy/8adace989f64462e18ffb5cb7d096b73

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-08-03 15:09                   ` Greg Kroah-Hartman
                                       ` (3 preceding siblings ...)
  (?)
@ 2018-08-03 16:43                     ` Matthew Wilcox
  -1 siblings, 0 replies; 153+ messages in thread
From: Matthew Wilcox @ 2018-08-03 16:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Andrey Konovalov, Catalin Marinas, Mark Rutland, Kate Stewart,
	linux-doc, Will Deacon, Kostya Serebryany, linux-kselftest,
	Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
	Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov, Kees Cook,
	Ruben Ayrapetyan, Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, LKML, Lee Smith, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov

On Fri, Aug 03, 2018 at 05:09:45PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
> > Started looking at this. When I run sparse with default checks enabled
> > (make C=1) I get countless warnings. Does anybody actually use it?
> 
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...

That's not true.  Building the current version of sparse from
git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
thousand errors just building the mm/ directory.  A sample:

../mm/filemap.c:2353:21: warning: expression using sizeof(void)
../mm/filemap.c:2618:35: warning: symbol 'generic_file_vm_ops' was not declared. Should it be static?
../include/linux/slab.h:666:13: error: undefined identifier '__builtin_mul_overflow'
../include/linux/slab.h:666:13: warning: call with no type!
../include/linux/rcupdate.h:683:9: warning: context imbalance in 'find_lock_task_mm' - wrong count at exit
../include/linux/sched/mm.h:141:37: warning: dereference of noderef expression
../mm/page_alloc.c:886:1: error: directive in argument list
../include/trace/events/vmscan.h:79:1: warning: cast from restricted gfp_t
../include/trace/events/vmscan.h:196:1: warning: too many warnings (ahem!)
../mm/mmap.c:137:9: warning: cast to non-scalar
../mm/mmap.c:137:9: warning: cast from non-scalar
../mm/page_vma_mapped.c:134:29: warning: Using plain integer as NULL pointer
../include/linux/slab.h:631:13: warning: call with no type!

Basically, nobody is fixing their shit.  The only way that sparse output
is useful is to log the warnings before your changes, log them afterwards
and run diff.  The worst offender (as in: fixing it would remove most of
the warnings) is the new min()/max() macro:

        ra->start = max_t(long, 0, offset - ra->ra_pages / 2);

produces that first warning at line 2353 of filemap.c.  I have no idea if
this is a sparse mistake or something it's genuinely warning us about,
but the sparse warnings are pretty ineffectual because nobody's paying
attention to them.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 16:43                     ` Matthew Wilcox
  0 siblings, 0 replies; 153+ messages in thread
From: Matthew Wilcox @ 2018-08-03 16:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Andrey Konovalov, Catalin Marinas, Mark Rutland, Kate Stewart,
	linux-doc, Will Deacon, Kostya Serebryany, linux-kselftest,
	Chintan Pandya, Shuah Khan, Ingo Molnar, linux-arch,
	Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov, Kees Cook,
	Ruben Ayrapetyan, Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, LKML, Lee Smith, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov

On Fri, Aug 03, 2018 at 05:09:45PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
> > Started looking at this. When I run sparse with default checks enabled
> > (make C=1) I get countless warnings. Does anybody actually use it?
> 
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...

That's not true.  Building the current version of sparse from
git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
thousand errors just building the mm/ directory.  A sample:

../mm/filemap.c:2353:21: warning: expression using sizeof(void)
../mm/filemap.c:2618:35: warning: symbol 'generic_file_vm_ops' was not declared. Should it be static?
../include/linux/slab.h:666:13: error: undefined identifier '__builtin_mul_overflow'
../include/linux/slab.h:666:13: warning: call with no type!
../include/linux/rcupdate.h:683:9: warning: context imbalance in 'find_lock_task_mm' - wrong count at exit
../include/linux/sched/mm.h:141:37: warning: dereference of noderef expression
../mm/page_alloc.c:886:1: error: directive in argument list
../include/trace/events/vmscan.h:79:1: warning: cast from restricted gfp_t
../include/trace/events/vmscan.h:196:1: warning: too many warnings (ahem!)
../mm/mmap.c:137:9: warning: cast to non-scalar
../mm/mmap.c:137:9: warning: cast from non-scalar
../mm/page_vma_mapped.c:134:29: warning: Using plain integer as NULL pointer
../include/linux/slab.h:631:13: warning: call with no type!

Basically, nobody is fixing their shit.  The only way that sparse output
is useful is to log the warnings before your changes, log them afterwards
and run diff.  The worst offender (as in: fixing it would remove most of
the warnings) is the new min()/max() macro:

        ra->start = max_t(long, 0, offset - ra->ra_pages / 2);

produces that first warning at line 2353 of filemap.c.  I have no idea if
this is a sparse mistake or something it's genuinely warning us about,
but the sparse warnings are pretty ineffectual because nobody's paying
attention to them.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 16:43                     ` Matthew Wilcox
  0 siblings, 0 replies; 153+ messages in thread
From: willy @ 2018-08-03 16:43 UTC (permalink / raw)


On Fri, Aug 03, 2018 at 05:09:45PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
> > Started looking at this. When I run sparse with default checks enabled
> > (make C=1) I get countless warnings. Does anybody actually use it?
> 
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...

That's not true.  Building the current version of sparse from
git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
thousand errors just building the mm/ directory.  A sample:

../mm/filemap.c:2353:21: warning: expression using sizeof(void)
../mm/filemap.c:2618:35: warning: symbol 'generic_file_vm_ops' was not declared. Should it be static?
../include/linux/slab.h:666:13: error: undefined identifier '__builtin_mul_overflow'
../include/linux/slab.h:666:13: warning: call with no type!
../include/linux/rcupdate.h:683:9: warning: context imbalance in 'find_lock_task_mm' - wrong count at exit
../include/linux/sched/mm.h:141:37: warning: dereference of noderef expression
../mm/page_alloc.c:886:1: error: directive in argument list
../include/trace/events/vmscan.h:79:1: warning: cast from restricted gfp_t
../include/trace/events/vmscan.h:196:1: warning: too many warnings (ahem!)
../mm/mmap.c:137:9: warning: cast to non-scalar
../mm/mmap.c:137:9: warning: cast from non-scalar
../mm/page_vma_mapped.c:134:29: warning: Using plain integer as NULL pointer
../include/linux/slab.h:631:13: warning: call with no type!

Basically, nobody is fixing their shit.  The only way that sparse output
is useful is to log the warnings before your changes, log them afterwards
and run diff.  The worst offender (as in: fixing it would remove most of
the warnings) is the new min()/max() macro:

        ra->start = max_t(long, 0, offset - ra->ra_pages / 2);

produces that first warning at line 2353 of filemap.c.  I have no idea if
this is a sparse mistake or something it's genuinely warning us about,
but the sparse warnings are pretty ineffectual because nobody's paying
attention to them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 16:43                     ` Matthew Wilcox
  0 siblings, 0 replies; 153+ messages in thread
From: Matthew Wilcox @ 2018-08-03 16:43 UTC (permalink / raw)


On Fri, Aug 03, 2018@05:09:45PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 03, 2018@04:59:18PM +0200, Andrey Konovalov wrote:
> > Started looking at this. When I run sparse with default checks enabled
> > (make C=1) I get countless warnings. Does anybody actually use it?
> 
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...

That's not true.  Building the current version of sparse from
git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
thousand errors just building the mm/ directory.  A sample:

../mm/filemap.c:2353:21: warning: expression using sizeof(void)
../mm/filemap.c:2618:35: warning: symbol 'generic_file_vm_ops' was not declared. Should it be static?
../include/linux/slab.h:666:13: error: undefined identifier '__builtin_mul_overflow'
../include/linux/slab.h:666:13: warning: call with no type!
../include/linux/rcupdate.h:683:9: warning: context imbalance in 'find_lock_task_mm' - wrong count at exit
../include/linux/sched/mm.h:141:37: warning: dereference of noderef expression
../mm/page_alloc.c:886:1: error: directive in argument list
../include/trace/events/vmscan.h:79:1: warning: cast from restricted gfp_t
../include/trace/events/vmscan.h:196:1: warning: too many warnings (ahem!)
../mm/mmap.c:137:9: warning: cast to non-scalar
../mm/mmap.c:137:9: warning: cast from non-scalar
../mm/page_vma_mapped.c:134:29: warning: Using plain integer as NULL pointer
../include/linux/slab.h:631:13: warning: call with no type!

Basically, nobody is fixing their shit.  The only way that sparse output
is useful is to log the warnings before your changes, log them afterwards
and run diff.  The worst offender (as in: fixing it would remove most of
the warnings) is the new min()/max() macro:

        ra->start = max_t(long, 0, offset - ra->ra_pages / 2);

produces that first warning at line 2353 of filemap.c.  I have no idea if
this is a sparse mistake or something it's genuinely warning us about,
but the sparse warnings are pretty ineffectual because nobody's paying
attention to them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 16:43                     ` Matthew Wilcox
  0 siblings, 0 replies; 153+ messages in thread
From: Matthew Wilcox @ 2018-08-03 16:43 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Mark Rutland, Kate Stewart, linux-doc, Catalin Marinas,
	Will Deacon, Kostya Serebryany, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Lee Smith, Al Viro, Linux ARM,
	Linux Memory Management List, LKML, Ramana Radhakrishnan

On Fri, Aug 03, 2018 at 05:09:45PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
> > Started looking at this. When I run sparse with default checks enabled
> > (make C=1) I get countless warnings. Does anybody actually use it?
> 
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...

That's not true.  Building the current version of sparse from
git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
thousand errors just building the mm/ directory.  A sample:

../mm/filemap.c:2353:21: warning: expression using sizeof(void)
../mm/filemap.c:2618:35: warning: symbol 'generic_file_vm_ops' was not declared. Should it be static?
../include/linux/slab.h:666:13: error: undefined identifier '__builtin_mul_overflow'
../include/linux/slab.h:666:13: warning: call with no type!
../include/linux/rcupdate.h:683:9: warning: context imbalance in 'find_lock_task_mm' - wrong count at exit
../include/linux/sched/mm.h:141:37: warning: dereference of noderef expression
../mm/page_alloc.c:886:1: error: directive in argument list
../include/trace/events/vmscan.h:79:1: warning: cast from restricted gfp_t
../include/trace/events/vmscan.h:196:1: warning: too many warnings (ahem!)
../mm/mmap.c:137:9: warning: cast to non-scalar
../mm/mmap.c:137:9: warning: cast from non-scalar
../mm/page_vma_mapped.c:134:29: warning: Using plain integer as NULL pointer
../include/linux/slab.h:631:13: warning: call with no type!

Basically, nobody is fixing their shit.  The only way that sparse output
is useful is to log the warnings before your changes, log them afterwards
and run diff.  The worst offender (as in: fixing it would remove most of
the warnings) is the new min()/max() macro:

        ra->start = max_t(long, 0, offset - ra->ra_pages / 2);

produces that first warning at line 2353 of filemap.c.  I have no idea if
this is a sparse mistake or something it's genuinely warning us about,
but the sparse warnings are pretty ineffectual because nobody's paying
attention to them.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 16:43                     ` Matthew Wilcox
  0 siblings, 0 replies; 153+ messages in thread
From: Matthew Wilcox @ 2018-08-03 16:43 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Aug 03, 2018 at 05:09:45PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
> > Started looking at this. When I run sparse with default checks enabled
> > (make C=1) I get countless warnings. Does anybody actually use it?
> 
> Try using a more up-to-date version of sparse.  Odds are you are using
> an old one, there is a newer version in a different branch on kernel.org
> somewhere...

That's not true.  Building the current version of sparse from
git://git.kernel.org/pub/scm/devel/sparse/sparse.git leaves me with a
thousand errors just building the mm/ directory.  A sample:

../mm/filemap.c:2353:21: warning: expression using sizeof(void)
../mm/filemap.c:2618:35: warning: symbol 'generic_file_vm_ops' was not declared. Should it be static?
../include/linux/slab.h:666:13: error: undefined identifier '__builtin_mul_overflow'
../include/linux/slab.h:666:13: warning: call with no type!
../include/linux/rcupdate.h:683:9: warning: context imbalance in 'find_lock_task_mm' - wrong count at exit
../include/linux/sched/mm.h:141:37: warning: dereference of noderef expression
../mm/page_alloc.c:886:1: error: directive in argument list
../include/trace/events/vmscan.h:79:1: warning: cast from restricted gfp_t
../include/trace/events/vmscan.h:196:1: warning: too many warnings (ahem!)
../mm/mmap.c:137:9: warning: cast to non-scalar
../mm/mmap.c:137:9: warning: cast from non-scalar
../mm/page_vma_mapped.c:134:29: warning: Using plain integer as NULL pointer
../include/linux/slab.h:631:13: warning: call with no type!

Basically, nobody is fixing their shit.  The only way that sparse output
is useful is to log the warnings before your changes, log them afterwards
and run diff.  The worst offender (as in: fixing it would remove most of
the warnings) is the new min()/max() macro:

        ra->start = max_t(long, 0, offset - ra->ra_pages / 2);

produces that first warning at line 2353 of filemap.c.  I have no idea if
this is a sparse mistake or something it's genuinely warning us about,
but the sparse warnings are pretty ineffectual because nobody's paying
attention to them.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-08-03 14:59                 ` Andrey Konovalov
                                     ` (3 preceding siblings ...)
  (?)
@ 2018-08-03 15:09                   ` Greg Kroah-Hartman
  -1 siblings, 0 replies; 153+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-03 15:09 UTC (permalink / raw)
  To: Andrey Konovalov
  Cc: Catalin Marinas, Mark Rutland, Kate Stewart, linux-doc,
	Will Deacon, Kostya Serebryany, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, LKML, Lee Smith, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov

On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
> On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> >> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
> >>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >>> So the checker reports ~100 different places where a __user pointer
> >>> being casted. I've looked through them and found 3 places where we
> >>> need to add untagging. Source code lines below come from 4.18-rc2+
> >>> (6f0d349d).
> >> [...]
> >>> I'll add the 3 patches with fixes to v5 of this patchset.
> >>
> >> Thanks for investigating. You can fix those three places in your code
> >
> > OK, will do.
> >
> >> but I was rather looking for a way to check such casting in the future
> >> for newly added code. While for the khwasan we can assume it's a debug
> >> option, the tagged user pointers are ABI and we need to keep it stable.
> >>
> >> We could we actually add some macros for explicit conversion between
> >> __user ptr and long and silence the warning there (I guess this would
> >> work better for sparse). We can then detect new ptr to long casts as
> >> they appear. I just hope that's not too intrusive.
> >>
> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
> >
> > Haven't look at that sparse patch yet myself, but sounds doable.
> > Should these macros go into this patchset or should they go
> > separately?
> 
> Started looking at this. When I run sparse with default checks enabled
> (make C=1) I get countless warnings. Does anybody actually use it?

Try using a more up-to-date version of sparse.  Odds are you are using
an old one, there is a newer version in a different branch on kernel.org
somewhere...

greg k-h

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 15:09                   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 153+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-03 15:09 UTC (permalink / raw)
  To: Andrey Konovalov
  Cc: Catalin Marinas, Mark Rutland, Kate Stewart, linux-doc,
	Will Deacon, Kostya Serebryany, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, LKML, Lee Smith, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov

On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
> On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> >> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
> >>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >>> So the checker reports ~100 different places where a __user pointer
> >>> being casted. I've looked through them and found 3 places where we
> >>> need to add untagging. Source code lines below come from 4.18-rc2+
> >>> (6f0d349d).
> >> [...]
> >>> I'll add the 3 patches with fixes to v5 of this patchset.
> >>
> >> Thanks for investigating. You can fix those three places in your code
> >
> > OK, will do.
> >
> >> but I was rather looking for a way to check such casting in the future
> >> for newly added code. While for the khwasan we can assume it's a debug
> >> option, the tagged user pointers are ABI and we need to keep it stable.
> >>
> >> We could we actually add some macros for explicit conversion between
> >> __user ptr and long and silence the warning there (I guess this would
> >> work better for sparse). We can then detect new ptr to long casts as
> >> they appear. I just hope that's not too intrusive.
> >>
> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
> >
> > Haven't look at that sparse patch yet myself, but sounds doable.
> > Should these macros go into this patchset or should they go
> > separately?
> 
> Started looking at this. When I run sparse with default checks enabled
> (make C=1) I get countless warnings. Does anybody actually use it?

Try using a more up-to-date version of sparse.  Odds are you are using
an old one, there is a newer version in a different branch on kernel.org
somewhere...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 15:09                   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 153+ messages in thread
From: gregkh @ 2018-08-03 15:09 UTC (permalink / raw)


On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
> On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> > On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
> >>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> >>> So the checker reports ~100 different places where a __user pointer
> >>> being casted. I've looked through them and found 3 places where we
> >>> need to add untagging. Source code lines below come from 4.18-rc2+
> >>> (6f0d349d).
> >> [...]
> >>> I'll add the 3 patches with fixes to v5 of this patchset.
> >>
> >> Thanks for investigating. You can fix those three places in your code
> >
> > OK, will do.
> >
> >> but I was rather looking for a way to check such casting in the future
> >> for newly added code. While for the khwasan we can assume it's a debug
> >> option, the tagged user pointers are ABI and we need to keep it stable.
> >>
> >> We could we actually add some macros for explicit conversion between
> >> __user ptr and long and silence the warning there (I guess this would
> >> work better for sparse). We can then detect new ptr to long casts as
> >> they appear. I just hope that's not too intrusive.
> >>
> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
> >
> > Haven't look at that sparse patch yet myself, but sounds doable.
> > Should these macros go into this patchset or should they go
> > separately?
> 
> Started looking at this. When I run sparse with default checks enabled
> (make C=1) I get countless warnings. Does anybody actually use it?

Try using a more up-to-date version of sparse.  Odds are you are using
an old one, there is a newer version in a different branch on kernel.org
somewhere...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 15:09                   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 153+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-03 15:09 UTC (permalink / raw)


On Fri, Aug 03, 2018@04:59:18PM +0200, Andrey Konovalov wrote:
> On Thu, Aug 2, 2018@5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, Aug 1, 2018@7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> >> On Mon, Jul 16, 2018@01:25:59PM +0200, Andrey Konovalov wrote:
> >>> On Thu, Jun 28, 2018@9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >>> So the checker reports ~100 different places where a __user pointer
> >>> being casted. I've looked through them and found 3 places where we
> >>> need to add untagging. Source code lines below come from 4.18-rc2+
> >>> (6f0d349d).
> >> [...]
> >>> I'll add the 3 patches with fixes to v5 of this patchset.
> >>
> >> Thanks for investigating. You can fix those three places in your code
> >
> > OK, will do.
> >
> >> but I was rather looking for a way to check such casting in the future
> >> for newly added code. While for the khwasan we can assume it's a debug
> >> option, the tagged user pointers are ABI and we need to keep it stable.
> >>
> >> We could we actually add some macros for explicit conversion between
> >> __user ptr and long and silence the warning there (I guess this would
> >> work better for sparse). We can then detect new ptr to long casts as
> >> they appear. I just hope that's not too intrusive.
> >>
> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
> >
> > Haven't look at that sparse patch yet myself, but sounds doable.
> > Should these macros go into this patchset or should they go
> > separately?
> 
> Started looking at this. When I run sparse with default checks enabled
> (make C=1) I get countless warnings. Does anybody actually use it?

Try using a more up-to-date version of sparse.  Odds are you are using
an old one, there is a newer version in a different branch on kernel.org
somewhere...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 15:09                   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 153+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-03 15:09 UTC (permalink / raw)
  To: Andrey Konovalov
  Cc: Catalin Marinas, Mark Rutland, Kate Stewart, linux-doc,
	Will Deacon, Kostya Serebryany, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List

On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
> On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> >> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
> >>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >>> So the checker reports ~100 different places where a __user pointer
> >>> being casted. I've looked through them and found 3 places where we
> >>> need to add untagging. Source code lines below come from 4.18-rc2+
> >>> (6f0d349d).
> >> [...]
> >>> I'll add the 3 patches with fixes to v5 of this patchset.
> >>
> >> Thanks for investigating. You can fix those three places in your code
> >
> > OK, will do.
> >
> >> but I was rather looking for a way to check such casting in the future
> >> for newly added code. While for the khwasan we can assume it's a debug
> >> option, the tagged user pointers are ABI and we need to keep it stable.
> >>
> >> We could we actually add some macros for explicit conversion between
> >> __user ptr and long and silence the warning there (I guess this would
> >> work better for sparse). We can then detect new ptr to long casts as
> >> they appear. I just hope that's not too intrusive.
> >>
> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
> >
> > Haven't look at that sparse patch yet myself, but sounds doable.
> > Should these macros go into this patchset or should they go
> > separately?
> 
> Started looking at this. When I run sparse with default checks enabled
> (make C=1) I get countless warnings. Does anybody actually use it?

Try using a more up-to-date version of sparse.  Odds are you are using
an old one, there is a newer version in a different branch on kernel.org
somewhere...

greg k-h

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 15:09                   ` Greg Kroah-Hartman
  0 siblings, 0 replies; 153+ messages in thread
From: Greg Kroah-Hartman @ 2018-08-03 15:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Aug 03, 2018 at 04:59:18PM +0200, Andrey Konovalov wrote:
> On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> >> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
> >>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >>> So the checker reports ~100 different places where a __user pointer
> >>> being casted. I've looked through them and found 3 places where we
> >>> need to add untagging. Source code lines below come from 4.18-rc2+
> >>> (6f0d349d).
> >> [...]
> >>> I'll add the 3 patches with fixes to v5 of this patchset.
> >>
> >> Thanks for investigating. You can fix those three places in your code
> >
> > OK, will do.
> >
> >> but I was rather looking for a way to check such casting in the future
> >> for newly added code. While for the khwasan we can assume it's a debug
> >> option, the tagged user pointers are ABI and we need to keep it stable.
> >>
> >> We could we actually add some macros for explicit conversion between
> >> __user ptr and long and silence the warning there (I guess this would
> >> work better for sparse). We can then detect new ptr to long casts as
> >> they appear. I just hope that's not too intrusive.
> >>
> >> (I haven't tried the sparse patch yet, hopefully sometime this week)
> >
> > Haven't look at that sparse patch yet myself, but sounds doable.
> > Should these macros go into this patchset or should they go
> > separately?
> 
> Started looking at this. When I run sparse with default checks enabled
> (make C=1) I get countless warnings. Does anybody actually use it?

Try using a more up-to-date version of sparse.  Odds are you are using
an old one, there is a newer version in a different branch on kernel.org
somewhere...

greg k-h

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-08-02 15:00               ` Andrey Konovalov
                                   ` (3 preceding siblings ...)
  (?)
@ 2018-08-03 14:59                 ` Andrey Konovalov
  -1 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-03 14:59 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, Greg Kroah-Hartman, LKML,
	Lee Smith, Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>> So the checker reports ~100 different places where a __user pointer
>>> being casted. I've looked through them and found 3 places where we
>>> need to add untagging. Source code lines below come from 4.18-rc2+
>>> (6f0d349d).
>> [...]
>>> I'll add the 3 patches with fixes to v5 of this patchset.
>>
>> Thanks for investigating. You can fix those three places in your code
>
> OK, will do.
>
>> but I was rather looking for a way to check such casting in the future
>> for newly added code. While for the khwasan we can assume it's a debug
>> option, the tagged user pointers are ABI and we need to keep it stable.
>>
>> We could we actually add some macros for explicit conversion between
>> __user ptr and long and silence the warning there (I guess this would
>> work better for sparse). We can then detect new ptr to long casts as
>> they appear. I just hope that's not too intrusive.
>>
>> (I haven't tried the sparse patch yet, hopefully sometime this week)
>
> Haven't look at that sparse patch yet myself, but sounds doable.
> Should these macros go into this patchset or should they go
> separately?

Started looking at this. When I run sparse with default checks enabled
(make C=1) I get countless warnings. Does anybody actually use it?

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 14:59                 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-03 14:59 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, Greg Kroah-Hartman, LKML,
	Lee Smith, Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>> So the checker reports ~100 different places where a __user pointer
>>> being casted. I've looked through them and found 3 places where we
>>> need to add untagging. Source code lines below come from 4.18-rc2+
>>> (6f0d349d).
>> [...]
>>> I'll add the 3 patches with fixes to v5 of this patchset.
>>
>> Thanks for investigating. You can fix those three places in your code
>
> OK, will do.
>
>> but I was rather looking for a way to check such casting in the future
>> for newly added code. While for the khwasan we can assume it's a debug
>> option, the tagged user pointers are ABI and we need to keep it stable.
>>
>> We could we actually add some macros for explicit conversion between
>> __user ptr and long and silence the warning there (I guess this would
>> work better for sparse). We can then detect new ptr to long casts as
>> they appear. I just hope that's not too intrusive.
>>
>> (I haven't tried the sparse patch yet, hopefully sometime this week)
>
> Haven't look at that sparse patch yet myself, but sounds doable.
> Should these macros go into this patchset or should they go
> separately?

Started looking at this. When I run sparse with default checks enabled
(make C=1) I get countless warnings. Does anybody actually use it?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 14:59                 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: andreyknvl @ 2018-08-03 14:59 UTC (permalink / raw)


On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
>>> So the checker reports ~100 different places where a __user pointer
>>> being casted. I've looked through them and found 3 places where we
>>> need to add untagging. Source code lines below come from 4.18-rc2+
>>> (6f0d349d).
>> [...]
>>> I'll add the 3 patches with fixes to v5 of this patchset.
>>
>> Thanks for investigating. You can fix those three places in your code
>
> OK, will do.
>
>> but I was rather looking for a way to check such casting in the future
>> for newly added code. While for the khwasan we can assume it's a debug
>> option, the tagged user pointers are ABI and we need to keep it stable.
>>
>> We could we actually add some macros for explicit conversion between
>> __user ptr and long and silence the warning there (I guess this would
>> work better for sparse). We can then detect new ptr to long casts as
>> they appear. I just hope that's not too intrusive.
>>
>> (I haven't tried the sparse patch yet, hopefully sometime this week)
>
> Haven't look at that sparse patch yet myself, but sounds doable.
> Should these macros go into this patchset or should they go
> separately?

Started looking at this. When I run sparse with default checks enabled
(make C=1) I get countless warnings. Does anybody actually use it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 14:59                 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-03 14:59 UTC (permalink / raw)


On Thu, Aug 2, 2018@5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Aug 1, 2018@7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> On Mon, Jul 16, 2018@01:25:59PM +0200, Andrey Konovalov wrote:
>>> On Thu, Jun 28, 2018@9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>> So the checker reports ~100 different places where a __user pointer
>>> being casted. I've looked through them and found 3 places where we
>>> need to add untagging. Source code lines below come from 4.18-rc2+
>>> (6f0d349d).
>> [...]
>>> I'll add the 3 patches with fixes to v5 of this patchset.
>>
>> Thanks for investigating. You can fix those three places in your code
>
> OK, will do.
>
>> but I was rather looking for a way to check such casting in the future
>> for newly added code. While for the khwasan we can assume it's a debug
>> option, the tagged user pointers are ABI and we need to keep it stable.
>>
>> We could we actually add some macros for explicit conversion between
>> __user ptr and long and silence the warning there (I guess this would
>> work better for sparse). We can then detect new ptr to long casts as
>> they appear. I just hope that's not too intrusive.
>>
>> (I haven't tried the sparse patch yet, hopefully sometime this week)
>
> Haven't look at that sparse patch yet myself, but sounds doable.
> Should these macros go into this patchset or should they go
> separately?

Started looking at this. When I run sparse with default checks enabled
(make C=1) I get countless warnings. Does anybody actually use it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 14:59                 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-03 14:59 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, Greg Kroah-Hartman

On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>> So the checker reports ~100 different places where a __user pointer
>>> being casted. I've looked through them and found 3 places where we
>>> need to add untagging. Source code lines below come from 4.18-rc2+
>>> (6f0d349d).
>> [...]
>>> I'll add the 3 patches with fixes to v5 of this patchset.
>>
>> Thanks for investigating. You can fix those three places in your code
>
> OK, will do.
>
>> but I was rather looking for a way to check such casting in the future
>> for newly added code. While for the khwasan we can assume it's a debug
>> option, the tagged user pointers are ABI and we need to keep it stable.
>>
>> We could we actually add some macros for explicit conversion between
>> __user ptr and long and silence the warning there (I guess this would
>> work better for sparse). We can then detect new ptr to long casts as
>> they appear. I just hope that's not too intrusive.
>>
>> (I haven't tried the sparse patch yet, hopefully sometime this week)
>
> Haven't look at that sparse patch yet myself, but sounds doable.
> Should these macros go into this patchset or should they go
> separately?

Started looking at this. When I run sparse with default checks enabled
(make C=1) I get countless warnings. Does anybody actually use it?

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-03 14:59                 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-03 14:59 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Aug 2, 2018 at 5:00 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>> So the checker reports ~100 different places where a __user pointer
>>> being casted. I've looked through them and found 3 places where we
>>> need to add untagging. Source code lines below come from 4.18-rc2+
>>> (6f0d349d).
>> [...]
>>> I'll add the 3 patches with fixes to v5 of this patchset.
>>
>> Thanks for investigating. You can fix those three places in your code
>
> OK, will do.
>
>> but I was rather looking for a way to check such casting in the future
>> for newly added code. While for the khwasan we can assume it's a debug
>> option, the tagged user pointers are ABI and we need to keep it stable.
>>
>> We could we actually add some macros for explicit conversion between
>> __user ptr and long and silence the warning there (I guess this would
>> work better for sparse). We can then detect new ptr to long casts as
>> they appear. I just hope that's not too intrusive.
>>
>> (I haven't tried the sparse patch yet, hopefully sometime this week)
>
> Haven't look at that sparse patch yet myself, but sounds doable.
> Should these macros go into this patchset or should they go
> separately?

Started looking at this. When I run sparse with default checks enabled
(make C=1) I get countless warnings. Does anybody actually use it?

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-08-01 17:42             ` Catalin Marinas
                                 ` (3 preceding siblings ...)
  (?)
@ 2018-08-02 15:00               ` Andrey Konovalov
  -1 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-02 15:00 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, Greg Kroah-Hartman, LKML,
	Lee Smith, Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> So the checker reports ~100 different places where a __user pointer
>> being casted. I've looked through them and found 3 places where we
>> need to add untagging. Source code lines below come from 4.18-rc2+
>> (6f0d349d).
> [...]
>> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Thanks for investigating. You can fix those three places in your code

OK, will do.

> but I was rather looking for a way to check such casting in the future
> for newly added code. While for the khwasan we can assume it's a debug
> option, the tagged user pointers are ABI and we need to keep it stable.
>
> We could we actually add some macros for explicit conversion between
> __user ptr and long and silence the warning there (I guess this would
> work better for sparse). We can then detect new ptr to long casts as
> they appear. I just hope that's not too intrusive.
>
> (I haven't tried the sparse patch yet, hopefully sometime this week)

Haven't look at that sparse patch yet myself, but sounds doable.
Should these macros go into this patchset or should they go
separately?

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-02 15:00               ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-02 15:00 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, Greg Kroah-Hartman, LKML,
	Lee Smith, Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> So the checker reports ~100 different places where a __user pointer
>> being casted. I've looked through them and found 3 places where we
>> need to add untagging. Source code lines below come from 4.18-rc2+
>> (6f0d349d).
> [...]
>> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Thanks for investigating. You can fix those three places in your code

OK, will do.

> but I was rather looking for a way to check such casting in the future
> for newly added code. While for the khwasan we can assume it's a debug
> option, the tagged user pointers are ABI and we need to keep it stable.
>
> We could we actually add some macros for explicit conversion between
> __user ptr and long and silence the warning there (I guess this would
> work better for sparse). We can then detect new ptr to long casts as
> they appear. I just hope that's not too intrusive.
>
> (I haven't tried the sparse patch yet, hopefully sometime this week)

Haven't look at that sparse patch yet myself, but sounds doable.
Should these macros go into this patchset or should they go
separately?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-02 15:00               ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: andreyknvl @ 2018-08-02 15:00 UTC (permalink / raw)


On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
>> So the checker reports ~100 different places where a __user pointer
>> being casted. I've looked through them and found 3 places where we
>> need to add untagging. Source code lines below come from 4.18-rc2+
>> (6f0d349d).
> [...]
>> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Thanks for investigating. You can fix those three places in your code

OK, will do.

> but I was rather looking for a way to check such casting in the future
> for newly added code. While for the khwasan we can assume it's a debug
> option, the tagged user pointers are ABI and we need to keep it stable.
>
> We could we actually add some macros for explicit conversion between
> __user ptr and long and silence the warning there (I guess this would
> work better for sparse). We can then detect new ptr to long casts as
> they appear. I just hope that's not too intrusive.
>
> (I haven't tried the sparse patch yet, hopefully sometime this week)

Haven't look at that sparse patch yet myself, but sounds doable.
Should these macros go into this patchset or should they go
separately?
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-02 15:00               ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-02 15:00 UTC (permalink / raw)


On Wed, Aug 1, 2018@7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Mon, Jul 16, 2018@01:25:59PM +0200, Andrey Konovalov wrote:
>> On Thu, Jun 28, 2018@9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> So the checker reports ~100 different places where a __user pointer
>> being casted. I've looked through them and found 3 places where we
>> need to add untagging. Source code lines below come from 4.18-rc2+
>> (6f0d349d).
> [...]
>> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Thanks for investigating. You can fix those three places in your code

OK, will do.

> but I was rather looking for a way to check such casting in the future
> for newly added code. While for the khwasan we can assume it's a debug
> option, the tagged user pointers are ABI and we need to keep it stable.
>
> We could we actually add some macros for explicit conversion between
> __user ptr and long and silence the warning there (I guess this would
> work better for sparse). We can then detect new ptr to long casts as
> they appear. I just hope that's not too intrusive.
>
> (I haven't tried the sparse patch yet, hopefully sometime this week)

Haven't look at that sparse patch yet myself, but sounds doable.
Should these macros go into this patchset or should they go
separately?
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-02 15:00               ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-02 15:00 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, Greg Kroah-Hartman

On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> So the checker reports ~100 different places where a __user pointer
>> being casted. I've looked through them and found 3 places where we
>> need to add untagging. Source code lines below come from 4.18-rc2+
>> (6f0d349d).
> [...]
>> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Thanks for investigating. You can fix those three places in your code

OK, will do.

> but I was rather looking for a way to check such casting in the future
> for newly added code. While for the khwasan we can assume it's a debug
> option, the tagged user pointers are ABI and we need to keep it stable.
>
> We could we actually add some macros for explicit conversion between
> __user ptr and long and silence the warning there (I guess this would
> work better for sparse). We can then detect new ptr to long casts as
> they appear. I just hope that's not too intrusive.
>
> (I haven't tried the sparse patch yet, hopefully sometime this week)

Haven't look at that sparse patch yet myself, but sounds doable.
Should these macros go into this patchset or should they go
separately?

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-02 15:00               ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-08-02 15:00 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Aug 1, 2018 at 7:42 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
>> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> So the checker reports ~100 different places where a __user pointer
>> being casted. I've looked through them and found 3 places where we
>> need to add untagging. Source code lines below come from 4.18-rc2+
>> (6f0d349d).
> [...]
>> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Thanks for investigating. You can fix those three places in your code

OK, will do.

> but I was rather looking for a way to check such casting in the future
> for newly added code. While for the khwasan we can assume it's a debug
> option, the tagged user pointers are ABI and we need to keep it stable.
>
> We could we actually add some macros for explicit conversion between
> __user ptr and long and silence the warning there (I guess this would
> work better for sparse). We can then detect new ptr to long casts as
> they appear. I just hope that's not too intrusive.
>
> (I haven't tried the sparse patch yet, hopefully sometime this week)

Haven't look at that sparse patch yet myself, but sounds doable.
Should these macros go into this patchset or should they go
separately?

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-07-16 11:25           ` Andrey Konovalov
                               ` (3 preceding siblings ...)
  (?)
@ 2018-08-01 17:42             ` Catalin Marinas
  -1 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-08-01 17:42 UTC (permalink / raw)
  To: Andrey Konovalov
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, Greg Kroah-Hartman, LKML,
	Lee Smith, Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> >> <catalin.marinas@arm.com> wrote:
> >>> While I support this work, as a maintainer I'd like to understand
> >>> whether we'd be in a continuous chase of ABI breaks with every kernel
> >>> release or we have a better way to identify potential issues. Is there
> >>> any way to statically analyse conversions from __user ptr to long for
> >>> example? Or, could we get the compiler to do this for us?
> >>
> >> OK, got it, I'll try to figure out a way to find these conversions.
> >
> > I've prototyped a checker on top of clang static analyzer (initially
> > looked at sparse, but couldn't find any documentation or examples).
> > The results are here [1], search for "warning: user pointer cast".
> > Sharing in case anybody wants to take a look, will look at them myself
> > tomorrow.
> >
> > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
> 
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
[...]
> I'll add the 3 patches with fixes to v5 of this patchset.

Thanks for investigating. You can fix those three places in your code
but I was rather looking for a way to check such casting in the future
for newly added code. While for the khwasan we can assume it's a debug
option, the tagged user pointers are ABI and we need to keep it stable.

We could we actually add some macros for explicit conversion between
__user ptr and long and silence the warning there (I guess this would
work better for sparse). We can then detect new ptr to long casts as
they appear. I just hope that's not too intrusive.

(I haven't tried the sparse patch yet, hopefully sometime this week)

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-01 17:42             ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-08-01 17:42 UTC (permalink / raw)
  To: Andrey Konovalov
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, Greg Kroah-Hartman, LKML,
	Lee Smith, Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> >> <catalin.marinas@arm.com> wrote:
> >>> While I support this work, as a maintainer I'd like to understand
> >>> whether we'd be in a continuous chase of ABI breaks with every kernel
> >>> release or we have a better way to identify potential issues. Is there
> >>> any way to statically analyse conversions from __user ptr to long for
> >>> example? Or, could we get the compiler to do this for us?
> >>
> >> OK, got it, I'll try to figure out a way to find these conversions.
> >
> > I've prototyped a checker on top of clang static analyzer (initially
> > looked at sparse, but couldn't find any documentation or examples).
> > The results are here [1], search for "warning: user pointer cast".
> > Sharing in case anybody wants to take a look, will look at them myself
> > tomorrow.
> >
> > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
> 
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
[...]
> I'll add the 3 patches with fixes to v5 of this patchset.

Thanks for investigating. You can fix those three places in your code
but I was rather looking for a way to check such casting in the future
for newly added code. While for the khwasan we can assume it's a debug
option, the tagged user pointers are ABI and we need to keep it stable.

We could we actually add some macros for explicit conversion between
__user ptr and long and silence the warning there (I guess this would
work better for sparse). We can then detect new ptr to long casts as
they appear. I just hope that's not too intrusive.

(I haven't tried the sparse patch yet, hopefully sometime this week)

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-01 17:42             ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: catalin.marinas @ 2018-08-01 17:42 UTC (permalink / raw)


On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> > On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> >> <catalin.marinas at arm.com> wrote:
> >>> While I support this work, as a maintainer I'd like to understand
> >>> whether we'd be in a continuous chase of ABI breaks with every kernel
> >>> release or we have a better way to identify potential issues. Is there
> >>> any way to statically analyse conversions from __user ptr to long for
> >>> example? Or, could we get the compiler to do this for us?
> >>
> >> OK, got it, I'll try to figure out a way to find these conversions.
> >
> > I've prototyped a checker on top of clang static analyzer (initially
> > looked at sparse, but couldn't find any documentation or examples).
> > The results are here [1], search for "warning: user pointer cast".
> > Sharing in case anybody wants to take a look, will look at them myself
> > tomorrow.
> >
> > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
> 
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
[...]
> I'll add the 3 patches with fixes to v5 of this patchset.

Thanks for investigating. You can fix those three places in your code
but I was rather looking for a way to check such casting in the future
for newly added code. While for the khwasan we can assume it's a debug
option, the tagged user pointers are ABI and we need to keep it stable.

We could we actually add some macros for explicit conversion between
__user ptr and long and silence the warning there (I guess this would
work better for sparse). We can then detect new ptr to long casts as
they appear. I just hope that's not too intrusive.

(I haven't tried the sparse patch yet, hopefully sometime this week)

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-01 17:42             ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-08-01 17:42 UTC (permalink / raw)


On Mon, Jul 16, 2018@01:25:59PM +0200, Andrey Konovalov wrote:
> On Thu, Jun 28, 2018@9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, Jun 27, 2018@5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> >> <catalin.marinas@arm.com> wrote:
> >>> While I support this work, as a maintainer I'd like to understand
> >>> whether we'd be in a continuous chase of ABI breaks with every kernel
> >>> release or we have a better way to identify potential issues. Is there
> >>> any way to statically analyse conversions from __user ptr to long for
> >>> example? Or, could we get the compiler to do this for us?
> >>
> >> OK, got it, I'll try to figure out a way to find these conversions.
> >
> > I've prototyped a checker on top of clang static analyzer (initially
> > looked at sparse, but couldn't find any documentation or examples).
> > The results are here [1], search for "warning: user pointer cast".
> > Sharing in case anybody wants to take a look, will look at them myself
> > tomorrow.
> >
> > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
> 
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
[...]
> I'll add the 3 patches with fixes to v5 of this patchset.

Thanks for investigating. You can fix those three places in your code
but I was rather looking for a way to check such casting in the future
for newly added code. While for the khwasan we can assume it's a debug
option, the tagged user pointers are ABI and we need to keep it stable.

We could we actually add some macros for explicit conversion between
__user ptr and long and silence the warning there (I guess this would
work better for sparse). We can then detect new ptr to long casts as
they appear. I just hope that's not too intrusive.

(I haven't tried the sparse patch yet, hopefully sometime this week)

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-01 17:42             ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-08-01 17:42 UTC (permalink / raw)
  To: Andrey Konovalov
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Ramana Radhakrishnan, Al Viro, Linux ARM,
	Linux Memory Management List, Greg Kroah-Hartman

On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> >> <catalin.marinas@arm.com> wrote:
> >>> While I support this work, as a maintainer I'd like to understand
> >>> whether we'd be in a continuous chase of ABI breaks with every kernel
> >>> release or we have a better way to identify potential issues. Is there
> >>> any way to statically analyse conversions from __user ptr to long for
> >>> example? Or, could we get the compiler to do this for us?
> >>
> >> OK, got it, I'll try to figure out a way to find these conversions.
> >
> > I've prototyped a checker on top of clang static analyzer (initially
> > looked at sparse, but couldn't find any documentation or examples).
> > The results are here [1], search for "warning: user pointer cast".
> > Sharing in case anybody wants to take a look, will look at them myself
> > tomorrow.
> >
> > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
> 
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
[...]
> I'll add the 3 patches with fixes to v5 of this patchset.

Thanks for investigating. You can fix those three places in your code
but I was rather looking for a way to check such casting in the future
for newly added code. While for the khwasan we can assume it's a debug
option, the tagged user pointers are ABI and we need to keep it stable.

We could we actually add some macros for explicit conversion between
__user ptr and long and silence the warning there (I guess this would
work better for sparse). We can then detect new ptr to long casts as
they appear. I just hope that's not too intrusive.

(I haven't tried the sparse patch yet, hopefully sometime this week)

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-08-01 17:42             ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-08-01 17:42 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jul 16, 2018 at 01:25:59PM +0200, Andrey Konovalov wrote:
> On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> >> <catalin.marinas@arm.com> wrote:
> >>> While I support this work, as a maintainer I'd like to understand
> >>> whether we'd be in a continuous chase of ABI breaks with every kernel
> >>> release or we have a better way to identify potential issues. Is there
> >>> any way to statically analyse conversions from __user ptr to long for
> >>> example? Or, could we get the compiler to do this for us?
> >>
> >> OK, got it, I'll try to figure out a way to find these conversions.
> >
> > I've prototyped a checker on top of clang static analyzer (initially
> > looked at sparse, but couldn't find any documentation or examples).
> > The results are here [1], search for "warning: user pointer cast".
> > Sharing in case anybody wants to take a look, will look at them myself
> > tomorrow.
> >
> > [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
> 
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
[...]
> I'll add the 3 patches with fixes to v5 of this patchset.

Thanks for investigating. You can fix those three places in your code
but I was rather looking for a way to check such casting in the future
for newly added code. While for the khwasan we can assume it's a debug
option, the tagged user pointers are ABI and we need to keep it stable.

We could we actually add some macros for explicit conversion between
__user ptr and long and silence the warning there (I guess this would
work better for sparse). We can then detect new ptr to long casts as
they appear. I just hope that's not too intrusive.

(I haven't tried the sparse patch yet, hopefully sometime this week)

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-07-16 11:25           ` Andrey Konovalov
                               ` (3 preceding siblings ...)
  (?)
@ 2018-07-31 13:23             ` Andrey Konovalov
  -1 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-07-31 13:23 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

On Mon, Jul 16, 2018 at 1:25 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
>
> Place 1:
>
> arch/arm64/mm/fault.c:302:34: warning: user pointer cast
> current->thread.fault_address = (unsigned long)info->si_addr;
>
> Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
> the kernel or in user space. Need to untag the address before
> performing a comparison.
>
> Place 2:
>
> fs/namespace.c:2736:21: warning: user pointer cast
> size = TASK_SIZE - (unsigned long)data;
>
> A similar check performed by subtracting a pointer from TASK_SIZE.
> Need to untag before subtracting.
>
> Place 3:
>
> drivers/usb/core/devio.c:1407:29: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1636:31: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1715:30: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
>
> The device keeps list of mmapped areas and searches them for provided
> __user pointer. Need to untag before searching.
>
> There are also a few cases of memory syscalls operating on __user
> pointers instead of unsigned longs like mmap:
>
> ipc/shm.c:1355:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> ipc/shm.c:1566:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> mm/migrate.c:1586:10: warning: user pointer cast
> addr = (unsigned long)p;
> mm/migrate.c:1660:24: warning: user pointer cast
> unsigned long addr = (unsigned long)(*pages);
>
> If we don't add untagging to mmap, we probably don't need it here.
>
> The rest of reported places look fine as is. Full annotated results of
> running the checker are here [2].
>
> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Catalin, WDYT?

ping

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-07-31 13:23             ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-07-31 13:23 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

On Mon, Jul 16, 2018 at 1:25 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
>
> Place 1:
>
> arch/arm64/mm/fault.c:302:34: warning: user pointer cast
> current->thread.fault_address = (unsigned long)info->si_addr;
>
> Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
> the kernel or in user space. Need to untag the address before
> performing a comparison.
>
> Place 2:
>
> fs/namespace.c:2736:21: warning: user pointer cast
> size = TASK_SIZE - (unsigned long)data;
>
> A similar check performed by subtracting a pointer from TASK_SIZE.
> Need to untag before subtracting.
>
> Place 3:
>
> drivers/usb/core/devio.c:1407:29: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1636:31: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1715:30: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
>
> The device keeps list of mmapped areas and searches them for provided
> __user pointer. Need to untag before searching.
>
> There are also a few cases of memory syscalls operating on __user
> pointers instead of unsigned longs like mmap:
>
> ipc/shm.c:1355:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> ipc/shm.c:1566:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> mm/migrate.c:1586:10: warning: user pointer cast
> addr = (unsigned long)p;
> mm/migrate.c:1660:24: warning: user pointer cast
> unsigned long addr = (unsigned long)(*pages);
>
> If we don't add untagging to mmap, we probably don't need it here.
>
> The rest of reported places look fine as is. Full annotated results of
> running the checker are here [2].
>
> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Catalin, WDYT?

ping
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-07-31 13:23             ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: andreyknvl @ 2018-07-31 13:23 UTC (permalink / raw)


On Mon, Jul 16, 2018 at 1:25 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
>
> Place 1:
>
> arch/arm64/mm/fault.c:302:34: warning: user pointer cast
> current->thread.fault_address = (unsigned long)info->si_addr;
>
> Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
> the kernel or in user space. Need to untag the address before
> performing a comparison.
>
> Place 2:
>
> fs/namespace.c:2736:21: warning: user pointer cast
> size = TASK_SIZE - (unsigned long)data;
>
> A similar check performed by subtracting a pointer from TASK_SIZE.
> Need to untag before subtracting.
>
> Place 3:
>
> drivers/usb/core/devio.c:1407:29: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1636:31: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1715:30: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
>
> The device keeps list of mmapped areas and searches them for provided
> __user pointer. Need to untag before searching.
>
> There are also a few cases of memory syscalls operating on __user
> pointers instead of unsigned longs like mmap:
>
> ipc/shm.c:1355:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> ipc/shm.c:1566:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> mm/migrate.c:1586:10: warning: user pointer cast
> addr = (unsigned long)p;
> mm/migrate.c:1660:24: warning: user pointer cast
> unsigned long addr = (unsigned long)(*pages);
>
> If we don't add untagging to mmap, we probably don't need it here.
>
> The rest of reported places look fine as is. Full annotated results of
> running the checker are here [2].
>
> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Catalin, WDYT?

ping
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-07-31 13:23             ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-07-31 13:23 UTC (permalink / raw)


On Mon, Jul 16, 2018@1:25 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
>
> Place 1:
>
> arch/arm64/mm/fault.c:302:34: warning: user pointer cast
> current->thread.fault_address = (unsigned long)info->si_addr;
>
> Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
> the kernel or in user space. Need to untag the address before
> performing a comparison.
>
> Place 2:
>
> fs/namespace.c:2736:21: warning: user pointer cast
> size = TASK_SIZE - (unsigned long)data;
>
> A similar check performed by subtracting a pointer from TASK_SIZE.
> Need to untag before subtracting.
>
> Place 3:
>
> drivers/usb/core/devio.c:1407:29: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1636:31: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1715:30: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
>
> The device keeps list of mmapped areas and searches them for provided
> __user pointer. Need to untag before searching.
>
> There are also a few cases of memory syscalls operating on __user
> pointers instead of unsigned longs like mmap:
>
> ipc/shm.c:1355:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> ipc/shm.c:1566:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> mm/migrate.c:1586:10: warning: user pointer cast
> addr = (unsigned long)p;
> mm/migrate.c:1660:24: warning: user pointer cast
> unsigned long addr = (unsigned long)(*pages);
>
> If we don't add untagging to mmap, we probably don't need it here.
>
> The rest of reported places look fine as is. Full annotated results of
> running the checker are here [2].
>
> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Catalin, WDYT?

ping
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-07-31 13:23             ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-07-31 13:23 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben

On Mon, Jul 16, 2018 at 1:25 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
>
> Place 1:
>
> arch/arm64/mm/fault.c:302:34: warning: user pointer cast
> current->thread.fault_address = (unsigned long)info->si_addr;
>
> Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
> the kernel or in user space. Need to untag the address before
> performing a comparison.
>
> Place 2:
>
> fs/namespace.c:2736:21: warning: user pointer cast
> size = TASK_SIZE - (unsigned long)data;
>
> A similar check performed by subtracting a pointer from TASK_SIZE.
> Need to untag before subtracting.
>
> Place 3:
>
> drivers/usb/core/devio.c:1407:29: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1636:31: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1715:30: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
>
> The device keeps list of mmapped areas and searches them for provided
> __user pointer. Need to untag before searching.
>
> There are also a few cases of memory syscalls operating on __user
> pointers instead of unsigned longs like mmap:
>
> ipc/shm.c:1355:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> ipc/shm.c:1566:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> mm/migrate.c:1586:10: warning: user pointer cast
> addr = (unsigned long)p;
> mm/migrate.c:1660:24: warning: user pointer cast
> unsigned long addr = (unsigned long)(*pages);
>
> If we don't add untagging to mmap, we probably don't need it here.
>
> The rest of reported places look fine as is. Full annotated results of
> running the checker are here [2].
>
> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Catalin, WDYT?

ping

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-07-31 13:23             ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-07-31 13:23 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jul 16, 2018 at 1:25 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> So the checker reports ~100 different places where a __user pointer
> being casted. I've looked through them and found 3 places where we
> need to add untagging. Source code lines below come from 4.18-rc2+
> (6f0d349d).
>
> Place 1:
>
> arch/arm64/mm/fault.c:302:34: warning: user pointer cast
> current->thread.fault_address = (unsigned long)info->si_addr;
>
> Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
> the kernel or in user space. Need to untag the address before
> performing a comparison.
>
> Place 2:
>
> fs/namespace.c:2736:21: warning: user pointer cast
> size = TASK_SIZE - (unsigned long)data;
>
> A similar check performed by subtracting a pointer from TASK_SIZE.
> Need to untag before subtracting.
>
> Place 3:
>
> drivers/usb/core/devio.c:1407:29: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1636:31: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
> drivers/usb/core/devio.c:1715:30: warning: user pointer cast
> unsigned long uurb_start = (unsigned long)uurb->buffer;
>
> The device keeps list of mmapped areas and searches them for provided
> __user pointer. Need to untag before searching.
>
> There are also a few cases of memory syscalls operating on __user
> pointers instead of unsigned longs like mmap:
>
> ipc/shm.c:1355:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> ipc/shm.c:1566:23: warning: user pointer cast
> unsigned long addr = (unsigned long)shmaddr;
> mm/migrate.c:1586:10: warning: user pointer cast
> addr = (unsigned long)p;
> mm/migrate.c:1660:24: warning: user pointer cast
> unsigned long addr = (unsigned long)(*pages);
>
> If we don't add untagging to mmap, we probably don't need it here.
>
> The rest of reported places look fine as is. Full annotated results of
> running the checker are here [2].
>
> I'll add the 3 patches with fixes to v5 of this patchset.
>
> Catalin, WDYT?

ping

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-28 19:30         ` Andrey Konovalov
                             ` (3 preceding siblings ...)
  (?)
@ 2018-07-16 11:25           ` Andrey Konovalov
  -1 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-07-16 11:25 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

So the checker reports ~100 different places where a __user pointer
being casted. I've looked through them and found 3 places where we
need to add untagging. Source code lines below come from 4.18-rc2+
(6f0d349d).

Place 1:

arch/arm64/mm/fault.c:302:34: warning: user pointer cast
current->thread.fault_address = (unsigned long)info->si_addr;

Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
the kernel or in user space. Need to untag the address before
performing a comparison.

Place 2:

fs/namespace.c:2736:21: warning: user pointer cast
size = TASK_SIZE - (unsigned long)data;

A similar check performed by subtracting a pointer from TASK_SIZE.
Need to untag before subtracting.

Place 3:

drivers/usb/core/devio.c:1407:29: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1636:31: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1715:30: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;

The device keeps list of mmapped areas and searches them for provided
__user pointer. Need to untag before searching.

There are also a few cases of memory syscalls operating on __user
pointers instead of unsigned longs like mmap:

ipc/shm.c:1355:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
ipc/shm.c:1566:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
mm/migrate.c:1586:10: warning: user pointer cast
addr = (unsigned long)p;
mm/migrate.c:1660:24: warning: user pointer cast
unsigned long addr = (unsigned long)(*pages);

If we don't add untagging to mmap, we probably don't need it here.

The rest of reported places look fine as is. Full annotated results of
running the checker are here [2].

I'll add the 3 patches with fixes to v5 of this patchset.

Catalin, WDYT?

[2] https://gist.github.com/xairy/aabda57741919df67d79895356ba9b58

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-07-16 11:25           ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-07-16 11:25 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

So the checker reports ~100 different places where a __user pointer
being casted. I've looked through them and found 3 places where we
need to add untagging. Source code lines below come from 4.18-rc2+
(6f0d349d).

Place 1:

arch/arm64/mm/fault.c:302:34: warning: user pointer cast
current->thread.fault_address = (unsigned long)info->si_addr;

Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
the kernel or in user space. Need to untag the address before
performing a comparison.

Place 2:

fs/namespace.c:2736:21: warning: user pointer cast
size = TASK_SIZE - (unsigned long)data;

A similar check performed by subtracting a pointer from TASK_SIZE.
Need to untag before subtracting.

Place 3:

drivers/usb/core/devio.c:1407:29: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1636:31: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1715:30: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;

The device keeps list of mmapped areas and searches them for provided
__user pointer. Need to untag before searching.

There are also a few cases of memory syscalls operating on __user
pointers instead of unsigned longs like mmap:

ipc/shm.c:1355:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
ipc/shm.c:1566:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
mm/migrate.c:1586:10: warning: user pointer cast
addr = (unsigned long)p;
mm/migrate.c:1660:24: warning: user pointer cast
unsigned long addr = (unsigned long)(*pages);

If we don't add untagging to mmap, we probably don't need it here.

The rest of reported places look fine as is. Full annotated results of
running the checker are here [2].

I'll add the 3 patches with fixes to v5 of this patchset.

Catalin, WDYT?

[2] https://gist.github.com/xairy/aabda57741919df67d79895356ba9b58
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-07-16 11:25           ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: andreyknvl @ 2018-07-16 11:25 UTC (permalink / raw)


On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas at arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

So the checker reports ~100 different places where a __user pointer
being casted. I've looked through them and found 3 places where we
need to add untagging. Source code lines below come from 4.18-rc2+
(6f0d349d).

Place 1:

arch/arm64/mm/fault.c:302:34: warning: user pointer cast
current->thread.fault_address = (unsigned long)info->si_addr;

Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
the kernel or in user space. Need to untag the address before
performing a comparison.

Place 2:

fs/namespace.c:2736:21: warning: user pointer cast
size = TASK_SIZE - (unsigned long)data;

A similar check performed by subtracting a pointer from TASK_SIZE.
Need to untag before subtracting.

Place 3:

drivers/usb/core/devio.c:1407:29: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1636:31: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1715:30: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;

The device keeps list of mmapped areas and searches them for provided
__user pointer. Need to untag before searching.

There are also a few cases of memory syscalls operating on __user
pointers instead of unsigned longs like mmap:

ipc/shm.c:1355:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
ipc/shm.c:1566:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
mm/migrate.c:1586:10: warning: user pointer cast
addr = (unsigned long)p;
mm/migrate.c:1660:24: warning: user pointer cast
unsigned long addr = (unsigned long)(*pages);

If we don't add untagging to mmap, we probably don't need it here.

The rest of reported places look fine as is. Full annotated results of
running the checker are here [2].

I'll add the 3 patches with fixes to v5 of this patchset.

Catalin, WDYT?

[2] https://gist.github.com/xairy/aabda57741919df67d79895356ba9b58
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-07-16 11:25           ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-07-16 11:25 UTC (permalink / raw)


On Thu, Jun 28, 2018@9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Jun 27, 2018@5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

So the checker reports ~100 different places where a __user pointer
being casted. I've looked through them and found 3 places where we
need to add untagging. Source code lines below come from 4.18-rc2+
(6f0d349d).

Place 1:

arch/arm64/mm/fault.c:302:34: warning: user pointer cast
current->thread.fault_address = (unsigned long)info->si_addr;

Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
the kernel or in user space. Need to untag the address before
performing a comparison.

Place 2:

fs/namespace.c:2736:21: warning: user pointer cast
size = TASK_SIZE - (unsigned long)data;

A similar check performed by subtracting a pointer from TASK_SIZE.
Need to untag before subtracting.

Place 3:

drivers/usb/core/devio.c:1407:29: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1636:31: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1715:30: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;

The device keeps list of mmapped areas and searches them for provided
__user pointer. Need to untag before searching.

There are also a few cases of memory syscalls operating on __user
pointers instead of unsigned longs like mmap:

ipc/shm.c:1355:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
ipc/shm.c:1566:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
mm/migrate.c:1586:10: warning: user pointer cast
addr = (unsigned long)p;
mm/migrate.c:1660:24: warning: user pointer cast
unsigned long addr = (unsigned long)(*pages);

If we don't add untagging to mmap, we probably don't need it here.

The rest of reported places look fine as is. Full annotated results of
running the checker are here [2].

I'll add the 3 patches with fixes to v5 of this patchset.

Catalin, WDYT?

[2] https://gist.github.com/xairy/aabda57741919df67d79895356ba9b58
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-07-16 11:25           ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-07-16 11:25 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben

On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

So the checker reports ~100 different places where a __user pointer
being casted. I've looked through them and found 3 places where we
need to add untagging. Source code lines below come from 4.18-rc2+
(6f0d349d).

Place 1:

arch/arm64/mm/fault.c:302:34: warning: user pointer cast
current->thread.fault_address = (unsigned long)info->si_addr;

Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
the kernel or in user space. Need to untag the address before
performing a comparison.

Place 2:

fs/namespace.c:2736:21: warning: user pointer cast
size = TASK_SIZE - (unsigned long)data;

A similar check performed by subtracting a pointer from TASK_SIZE.
Need to untag before subtracting.

Place 3:

drivers/usb/core/devio.c:1407:29: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1636:31: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1715:30: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;

The device keeps list of mmapped areas and searches them for provided
__user pointer. Need to untag before searching.

There are also a few cases of memory syscalls operating on __user
pointers instead of unsigned longs like mmap:

ipc/shm.c:1355:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
ipc/shm.c:1566:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
mm/migrate.c:1586:10: warning: user pointer cast
addr = (unsigned long)p;
mm/migrate.c:1660:24: warning: user pointer cast
unsigned long addr = (unsigned long)(*pages);

If we don't add untagging to mmap, we probably don't need it here.

The rest of reported places look fine as is. Full annotated results of
running the checker are here [2].

I'll add the 3 patches with fixes to v5 of this patchset.

Catalin, WDYT?

[2] https://gist.github.com/xairy/aabda57741919df67d79895356ba9b58

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-07-16 11:25           ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-07-16 11:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

So the checker reports ~100 different places where a __user pointer
being casted. I've looked through them and found 3 places where we
need to add untagging. Source code lines below come from 4.18-rc2+
(6f0d349d).

Place 1:

arch/arm64/mm/fault.c:302:34: warning: user pointer cast
current->thread.fault_address = (unsigned long)info->si_addr;

Compare a pointer with TASK_SIZE (1 << 48) to check whether it lies in
the kernel or in user space. Need to untag the address before
performing a comparison.

Place 2:

fs/namespace.c:2736:21: warning: user pointer cast
size = TASK_SIZE - (unsigned long)data;

A similar check performed by subtracting a pointer from TASK_SIZE.
Need to untag before subtracting.

Place 3:

drivers/usb/core/devio.c:1407:29: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1636:31: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;
drivers/usb/core/devio.c:1715:30: warning: user pointer cast
unsigned long uurb_start = (unsigned long)uurb->buffer;

The device keeps list of mmapped areas and searches them for provided
__user pointer. Need to untag before searching.

There are also a few cases of memory syscalls operating on __user
pointers instead of unsigned longs like mmap:

ipc/shm.c:1355:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
ipc/shm.c:1566:23: warning: user pointer cast
unsigned long addr = (unsigned long)shmaddr;
mm/migrate.c:1586:10: warning: user pointer cast
addr = (unsigned long)p;
mm/migrate.c:1660:24: warning: user pointer cast
unsigned long addr = (unsigned long)(*pages);

If we don't add untagging to mmap, we probably don't need it here.

The rest of reported places look fine as is. Full annotated results of
running the checker are here [2].

I'll add the 3 patches with fixes to v5 of this patchset.

Catalin, WDYT?

[2] https://gist.github.com/xairy/aabda57741919df67d79895356ba9b58

^ permalink raw reply	[flat|nested] 153+ messages in thread

* RE: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-28 14:48                   ` Catalin Marinas
                                       ` (4 preceding siblings ...)
  (?)
@ 2018-06-29 15:27                     ` David Laight
  -1 siblings, 0 replies; 153+ messages in thread
From: David Laight @ 2018-06-29 15:27 UTC (permalink / raw)
  To: 'Catalin Marinas', Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro, nd, Linux ARM,
	Kostya Serebryany, Greg Kroah-Hartman, LKML, Lee Smith,
	Andrew Morton, Robin Murphy, Kirill A . Shutemov

From: Catalin Marinas
> Sent: 28 June 2018 15:49
...
> >
> > Mmmm yes.
> > I tend to favor a sort of opposite approach. When we have an address
> > that must not be dereferenced as-such (and sometimes when the address
> > can be from both __user & __kernel space) I prefer to use a ulong
> > which will force the use of the required operation before being
> > able to do any sort of dereferencing and this won't need horrible
> > casts with __force (it, of course, all depends on the full context).
> 
> I agree. That's what the kernel uses in functions like get_user_pages()
> which take ulong as an argument. Similarly mmap() and friends don't
> expect the pointer to be dereferenced, hence the ulong argument. The
> interesting part that the man page (and the C library header
> declaration) shows such address argument as void *. We could add a
> syscall wrapper in the arch code, only that it doesn't feel consistent
> with the "rule" that ulong addresses are not actually tagged pointers.

For most modern calling conventions it would make sense to put 'user'
addresses (and physical ones from that matter) into a structure.
That way you get much stronger typing from C itself.

The patch would, of course, be huge!

	David


^ permalink raw reply	[flat|nested] 153+ messages in thread

* RE: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:27                     ` David Laight
  0 siblings, 0 replies; 153+ messages in thread
From: David Laight @ 2018-06-29 15:27 UTC (permalink / raw)
  To: 'Catalin Marinas', Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro, nd, Linux ARM,
	Kostya Serebryany, Greg Kroah-Hartman, LKML, Lee Smith,
	Andrew Morton, Robin Murphy, Kirill A . Shutemov

From: Catalin Marinas
> Sent: 28 June 2018 15:49
...
> >
> > Mmmm yes.
> > I tend to favor a sort of opposite approach. When we have an address
> > that must not be dereferenced as-such (and sometimes when the address
> > can be from both __user & __kernel space) I prefer to use a ulong
> > which will force the use of the required operation before being
> > able to do any sort of dereferencing and this won't need horrible
> > casts with __force (it, of course, all depends on the full context).
> 
> I agree. That's what the kernel uses in functions like get_user_pages()
> which take ulong as an argument. Similarly mmap() and friends don't
> expect the pointer to be dereferenced, hence the ulong argument. The
> interesting part that the man page (and the C library header
> declaration) shows such address argument as void *. We could add a
> syscall wrapper in the arch code, only that it doesn't feel consistent
> with the "rule" that ulong addresses are not actually tagged pointers.

For most modern calling conventions it would make sense to put 'user'
addresses (and physical ones from that matter) into a structure.
That way you get much stronger typing from C itself.

The patch would, of course, be huge!

	David

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:27                     ` David Laight
  0 siblings, 0 replies; 153+ messages in thread
From: David.Laight @ 2018-06-29 15:27 UTC (permalink / raw)


From: Catalin Marinas
> Sent: 28 June 2018 15:49
...
> >
> > Mmmm yes.
> > I tend to favor a sort of opposite approach. When we have an address
> > that must not be dereferenced as-such (and sometimes when the address
> > can be from both __user & __kernel space) I prefer to use a ulong
> > which will force the use of the required operation before being
> > able to do any sort of dereferencing and this won't need horrible
> > casts with __force (it, of course, all depends on the full context).
> 
> I agree. That's what the kernel uses in functions like get_user_pages()
> which take ulong as an argument. Similarly mmap() and friends don't
> expect the pointer to be dereferenced, hence the ulong argument. The
> interesting part that the man page (and the C library header
> declaration) shows such address argument as void *. We could add a
> syscall wrapper in the arch code, only that it doesn't feel consistent
> with the "rule" that ulong addresses are not actually tagged pointers.

For most modern calling conventions it would make sense to put 'user'
addresses (and physical ones from that matter) into a structure.
That way you get much stronger typing from C itself.

The patch would, of course, be huge!

	David

--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:27                     ` David Laight
  0 siblings, 0 replies; 153+ messages in thread
From: David Laight @ 2018-06-29 15:27 UTC (permalink / raw)


From: Catalin Marinas
> Sent: 28 June 2018 15:49
...
> >
> > Mmmm yes.
> > I tend to favor a sort of opposite approach. When we have an address
> > that must not be dereferenced as-such (and sometimes when the address
> > can be from both __user & __kernel space) I prefer to use a ulong
> > which will force the use of the required operation before being
> > able to do any sort of dereferencing and this won't need horrible
> > casts with __force (it, of course, all depends on the full context).
> 
> I agree. That's what the kernel uses in functions like get_user_pages()
> which take ulong as an argument. Similarly mmap() and friends don't
> expect the pointer to be dereferenced, hence the ulong argument. The
> interesting part that the man page (and the C library header
> declaration) shows such address argument as void *. We could add a
> syscall wrapper in the arch code, only that it doesn't feel consistent
> with the "rule" that ulong addresses are not actually tagged pointers.

For most modern calling conventions it would make sense to put 'user'
addresses (and physical ones from that matter) into a structure.
That way you get much stronger typing from C itself.

The patch would, of course, be huge!

	David

--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* RE: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:27                     ` David Laight
  0 siblings, 0 replies; 153+ messages in thread
From: David Laight @ 2018-06-29 15:27 UTC (permalink / raw)
  To: 'Catalin Marinas', Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro

From: Catalin Marinas
> Sent: 28 June 2018 15:49
...
> >
> > Mmmm yes.
> > I tend to favor a sort of opposite approach. When we have an address
> > that must not be dereferenced as-such (and sometimes when the address
> > can be from both __user & __kernel space) I prefer to use a ulong
> > which will force the use of the required operation before being
> > able to do any sort of dereferencing and this won't need horrible
> > casts with __force (it, of course, all depends on the full context).
> 
> I agree. That's what the kernel uses in functions like get_user_pages()
> which take ulong as an argument. Similarly mmap() and friends don't
> expect the pointer to be dereferenced, hence the ulong argument. The
> interesting part that the man page (and the C library header
> declaration) shows such address argument as void *. We could add a
> syscall wrapper in the arch code, only that it doesn't feel consistent
> with the "rule" that ulong addresses are not actually tagged pointers.

For most modern calling conventions it would make sense to put 'user'
addresses (and physical ones from that matter) into a structure.
That way you get much stronger typing from C itself.

The patch would, of course, be huge!

	David

^ permalink raw reply	[flat|nested] 153+ messages in thread

* RE: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:27                     ` David Laight
  0 siblings, 0 replies; 153+ messages in thread
From: David Laight @ 2018-06-29 15:27 UTC (permalink / raw)
  To: 'Catalin Marinas', Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro

From: Catalin Marinas
> Sent: 28 June 2018 15:49
...
> >
> > Mmmm yes.
> > I tend to favor a sort of opposite approach. When we have an address
> > that must not be dereferenced as-such (and sometimes when the address
> > can be from both __user & __kernel space) I prefer to use a ulong
> > which will force the use of the required operation before being
> > able to do any sort of dereferencing and this won't need horrible
> > casts with __force (it, of course, all depends on the full context).
> 
> I agree. That's what the kernel uses in functions like get_user_pages()
> which take ulong as an argument. Similarly mmap() and friends don't
> expect the pointer to be dereferenced, hence the ulong argument. The
> interesting part that the man page (and the C library header
> declaration) shows such address argument as void *. We could add a
> syscall wrapper in the arch code, only that it doesn't feel consistent
> with the "rule" that ulong addresses are not actually tagged pointers.

For most modern calling conventions it would make sense to put 'user'
addresses (and physical ones from that matter) into a structure.
That way you get much stronger typing from C itself.

The patch would, of course, be huge!

	David

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:27                     ` David Laight
  0 siblings, 0 replies; 153+ messages in thread
From: David Laight @ 2018-06-29 15:27 UTC (permalink / raw)
  To: linux-arm-kernel

From: Catalin Marinas
> Sent: 28 June 2018 15:49
...
> >
> > Mmmm yes.
> > I tend to favor a sort of opposite approach. When we have an address
> > that must not be dereferenced as-such (and sometimes when the address
> > can be from both __user & __kernel space) I prefer to use a ulong
> > which will force the use of the required operation before being
> > able to do any sort of dereferencing and this won't need horrible
> > casts with __force (it, of course, all depends on the full context).
> 
> I agree. That's what the kernel uses in functions like get_user_pages()
> which take ulong as an argument. Similarly mmap() and friends don't
> expect the pointer to be dereferenced, hence the ulong argument. The
> interesting part that the man page (and the C library header
> declaration) shows such address argument as void *. We could add a
> syscall wrapper in the arch code, only that it doesn't feel consistent
> with the "rule" that ulong addresses are not actually tagged pointers.

For most modern calling conventions it would make sense to put 'user'
addresses (and physical ones from that matter) into a structure.
That way you get much stronger typing from C itself.

The patch would, of course, be huge!

	David

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-29 15:19           ` Andrey Konovalov
                               ` (3 preceding siblings ...)
  (?)
@ 2018-06-29 15:20             ` Andrey Konovalov
  -1 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-29 15:20 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

On Fri, Jun 29, 2018 at 5:19 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> a bunch of compat
> a bunch of ioctl that use ptr to stored ints
>
> ipc/shm.c:1355
> ipc/shm.c:1566
>
> mm/process_vm_access.c:178:20
> mm/process_vm_access.c:180:19
> substraction => harmless
>
> mm/process_vm_access.c:221:4
> ?
>
> mm/memory.c:4679:14
> should be __user pointer
>
> fs/fuse/file.c:1256:9
> ?
>
> kernel/kthread.c:73:9
> ?
>
> mm/migrate.c:1586:10
> mm/migrate.c:1660:24
>
> lib/iov_iter.c
> ???
>
> kernel/futex.c:502
> uses user addr as key
>
> kernel/futex.c:730
> gup, fixed
>
> lib/strncpy_from_user.c:110:13
> fixed?
>
> lib/strnlen_user.c:112
> fixed?
>
> fs/readdir.c:369
> ???

Started looking at the results and accidentally posted my notes.
Ignore this for now, will post when done.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:20             ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-29 15:20 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

On Fri, Jun 29, 2018 at 5:19 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> a bunch of compat
> a bunch of ioctl that use ptr to stored ints
>
> ipc/shm.c:1355
> ipc/shm.c:1566
>
> mm/process_vm_access.c:178:20
> mm/process_vm_access.c:180:19
> substraction => harmless
>
> mm/process_vm_access.c:221:4
> ?
>
> mm/memory.c:4679:14
> should be __user pointer
>
> fs/fuse/file.c:1256:9
> ?
>
> kernel/kthread.c:73:9
> ?
>
> mm/migrate.c:1586:10
> mm/migrate.c:1660:24
>
> lib/iov_iter.c
> ???
>
> kernel/futex.c:502
> uses user addr as key
>
> kernel/futex.c:730
> gup, fixed
>
> lib/strncpy_from_user.c:110:13
> fixed?
>
> lib/strnlen_user.c:112
> fixed?
>
> fs/readdir.c:369
> ???

Started looking at the results and accidentally posted my notes.
Ignore this for now, will post when done.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:20             ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: andreyknvl @ 2018-06-29 15:20 UTC (permalink / raw)


On Fri, Jun 29, 2018 at 5:19 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> a bunch of compat
> a bunch of ioctl that use ptr to stored ints
>
> ipc/shm.c:1355
> ipc/shm.c:1566
>
> mm/process_vm_access.c:178:20
> mm/process_vm_access.c:180:19
> substraction => harmless
>
> mm/process_vm_access.c:221:4
> ?
>
> mm/memory.c:4679:14
> should be __user pointer
>
> fs/fuse/file.c:1256:9
> ?
>
> kernel/kthread.c:73:9
> ?
>
> mm/migrate.c:1586:10
> mm/migrate.c:1660:24
>
> lib/iov_iter.c
> ???
>
> kernel/futex.c:502
> uses user addr as key
>
> kernel/futex.c:730
> gup, fixed
>
> lib/strncpy_from_user.c:110:13
> fixed?
>
> lib/strnlen_user.c:112
> fixed?
>
> fs/readdir.c:369
> ???

Started looking at the results and accidentally posted my notes.
Ignore this for now, will post when done.
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:20             ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-29 15:20 UTC (permalink / raw)


On Fri, Jun 29, 2018@5:19 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> a bunch of compat
> a bunch of ioctl that use ptr to stored ints
>
> ipc/shm.c:1355
> ipc/shm.c:1566
>
> mm/process_vm_access.c:178:20
> mm/process_vm_access.c:180:19
> substraction => harmless
>
> mm/process_vm_access.c:221:4
> ?
>
> mm/memory.c:4679:14
> should be __user pointer
>
> fs/fuse/file.c:1256:9
> ?
>
> kernel/kthread.c:73:9
> ?
>
> mm/migrate.c:1586:10
> mm/migrate.c:1660:24
>
> lib/iov_iter.c
> ???
>
> kernel/futex.c:502
> uses user addr as key
>
> kernel/futex.c:730
> gup, fixed
>
> lib/strncpy_from_user.c:110:13
> fixed?
>
> lib/strnlen_user.c:112
> fixed?
>
> fs/readdir.c:369
> ???

Started looking at the results and accidentally posted my notes.
Ignore this for now, will post when done.
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:20             ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-29 15:20 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben

On Fri, Jun 29, 2018 at 5:19 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> a bunch of compat
> a bunch of ioctl that use ptr to stored ints
>
> ipc/shm.c:1355
> ipc/shm.c:1566
>
> mm/process_vm_access.c:178:20
> mm/process_vm_access.c:180:19
> substraction => harmless
>
> mm/process_vm_access.c:221:4
> ?
>
> mm/memory.c:4679:14
> should be __user pointer
>
> fs/fuse/file.c:1256:9
> ?
>
> kernel/kthread.c:73:9
> ?
>
> mm/migrate.c:1586:10
> mm/migrate.c:1660:24
>
> lib/iov_iter.c
> ???
>
> kernel/futex.c:502
> uses user addr as key
>
> kernel/futex.c:730
> gup, fixed
>
> lib/strncpy_from_user.c:110:13
> fixed?
>
> lib/strnlen_user.c:112
> fixed?
>
> fs/readdir.c:369
> ???

Started looking at the results and accidentally posted my notes.
Ignore this for now, will post when done.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:20             ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-29 15:20 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Jun 29, 2018 at 5:19 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> a bunch of compat
> a bunch of ioctl that use ptr to stored ints
>
> ipc/shm.c:1355
> ipc/shm.c:1566
>
> mm/process_vm_access.c:178:20
> mm/process_vm_access.c:180:19
> substraction => harmless
>
> mm/process_vm_access.c:221:4
> ?
>
> mm/memory.c:4679:14
> should be __user pointer
>
> fs/fuse/file.c:1256:9
> ?
>
> kernel/kthread.c:73:9
> ?
>
> mm/migrate.c:1586:10
> mm/migrate.c:1660:24
>
> lib/iov_iter.c
> ???
>
> kernel/futex.c:502
> uses user addr as key
>
> kernel/futex.c:730
> gup, fixed
>
> lib/strncpy_from_user.c:110:13
> fixed?
>
> lib/strnlen_user.c:112
> fixed?
>
> fs/readdir.c:369
> ???

Started looking at the results and accidentally posted my notes.
Ignore this for now, will post when done.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-28 19:30         ` Andrey Konovalov
                             ` (3 preceding siblings ...)
  (?)
@ 2018-06-29 15:19           ` Andrey Konovalov
  -1 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-29 15:19 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

a bunch of compat
a bunch of ioctl that use ptr to stored ints

ipc/shm.c:1355
ipc/shm.c:1566

mm/process_vm_access.c:178:20
mm/process_vm_access.c:180:19
substraction => harmless

mm/process_vm_access.c:221:4
?

mm/memory.c:4679:14
should be __user pointer

fs/fuse/file.c:1256:9
?

kernel/kthread.c:73:9
?

mm/migrate.c:1586:10
mm/migrate.c:1660:24

lib/iov_iter.c
???

kernel/futex.c:502
uses user addr as key

kernel/futex.c:730
gup, fixed

lib/strncpy_from_user.c:110:13
fixed?

lib/strnlen_user.c:112
fixed?

fs/readdir.c:369
???



On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:19           ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-29 15:19 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

a bunch of compat
a bunch of ioctl that use ptr to stored ints

ipc/shm.c:1355
ipc/shm.c:1566

mm/process_vm_access.c:178:20
mm/process_vm_access.c:180:19
substraction => harmless

mm/process_vm_access.c:221:4
?

mm/memory.c:4679:14
should be __user pointer

fs/fuse/file.c:1256:9
?

kernel/kthread.c:73:9
?

mm/migrate.c:1586:10
mm/migrate.c:1660:24

lib/iov_iter.c
???

kernel/futex.c:502
uses user addr as key

kernel/futex.c:730
gup, fixed

lib/strncpy_from_user.c:110:13
fixed?

lib/strnlen_user.c:112
fixed?

fs/readdir.c:369
???



On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:19           ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: andreyknvl @ 2018-06-29 15:19 UTC (permalink / raw)


a bunch of compat
a bunch of ioctl that use ptr to stored ints

ipc/shm.c:1355
ipc/shm.c:1566

mm/process_vm_access.c:178:20
mm/process_vm_access.c:180:19
substraction => harmless

mm/process_vm_access.c:221:4
?

mm/memory.c:4679:14
should be __user pointer

fs/fuse/file.c:1256:9
?

kernel/kthread.c:73:9
?

mm/migrate.c:1586:10
mm/migrate.c:1660:24

lib/iov_iter.c
???

kernel/futex.c:502
uses user addr as key

kernel/futex.c:730
gup, fixed

lib/strncpy_from_user.c:110:13
fixed?

lib/strnlen_user.c:112
fixed?

fs/readdir.c:369
???



On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas at arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:19           ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-29 15:19 UTC (permalink / raw)


a bunch of compat
a bunch of ioctl that use ptr to stored ints

ipc/shm.c:1355
ipc/shm.c:1566

mm/process_vm_access.c:178:20
mm/process_vm_access.c:180:19
substraction => harmless

mm/process_vm_access.c:221:4
?

mm/memory.c:4679:14
should be __user pointer

fs/fuse/file.c:1256:9
?

kernel/kthread.c:73:9
?

mm/migrate.c:1586:10
mm/migrate.c:1660:24

lib/iov_iter.c
???

kernel/futex.c:502
uses user addr as key

kernel/futex.c:730
gup, fixed

lib/strncpy_from_user.c:110:13
fixed?

lib/strnlen_user.c:112
fixed?

fs/readdir.c:369
???



On Thu, Jun 28, 2018@9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Jun 27, 2018@5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:19           ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-29 15:19 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben

a bunch of compat
a bunch of ioctl that use ptr to stored ints

ipc/shm.c:1355
ipc/shm.c:1566

mm/process_vm_access.c:178:20
mm/process_vm_access.c:180:19
substraction => harmless

mm/process_vm_access.c:221:4
?

mm/memory.c:4679:14
should be __user pointer

fs/fuse/file.c:1256:9
?

kernel/kthread.c:73:9
?

mm/migrate.c:1586:10
mm/migrate.c:1660:24

lib/iov_iter.c
???

kernel/futex.c:502
uses user addr as key

kernel/futex.c:730
gup, fixed

lib/strncpy_from_user.c:110:13
fixed?

lib/strnlen_user.c:112
fixed?

fs/readdir.c:369
???



On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-29 15:19           ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-29 15:19 UTC (permalink / raw)
  To: linux-arm-kernel

a bunch of compat
a bunch of ioctl that use ptr to stored ints

ipc/shm.c:1355
ipc/shm.c:1566

mm/process_vm_access.c:178:20
mm/process_vm_access.c:180:19
substraction => harmless

mm/process_vm_access.c:221:4
?

mm/memory.c:4679:14
should be __user pointer

fs/fuse/file.c:1256:9
?

kernel/kthread.c:73:9
?

mm/migrate.c:1586:10
mm/migrate.c:1660:24

lib/iov_iter.c
???

kernel/futex.c:502
uses user addr as key

kernel/futex.c:730
gup, fixed

lib/strncpy_from_user.c:110:13
fixed?

lib/strnlen_user.c:112
fixed?

fs/readdir.c:369
???



On Thu, Jun 28, 2018 at 9:30 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> While I support this work, as a maintainer I'd like to understand
>>> whether we'd be in a continuous chase of ABI breaks with every kernel
>>> release or we have a better way to identify potential issues. Is there
>>> any way to statically analyse conversions from __user ptr to long for
>>> example? Or, could we get the compiler to do this for us?
>>
>>
>> OK, got it, I'll try to figure out a way to find these conversions.
>
> I've prototyped a checker on top of clang static analyzer (initially
> looked at sparse, but couldn't find any documentation or examples).
> The results are here [1], search for "warning: user pointer cast".
> Sharing in case anybody wants to take a look, will look at them myself
> tomorrow.
>
> [1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-27 15:05       ` Andrey Konovalov
                           ` (3 preceding siblings ...)
  (?)
@ 2018-06-28 19:30         ` Andrey Konovalov
  -1 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-28 19:30 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
>
>
> OK, got it, I'll try to figure out a way to find these conversions.

I've prototyped a checker on top of clang static analyzer (initially
looked at sparse, but couldn't find any documentation or examples).
The results are here [1], search for "warning: user pointer cast".
Sharing in case anybody wants to take a look, will look at them myself
tomorrow.

[1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 19:30         ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-28 19:30 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
>
>
> OK, got it, I'll try to figure out a way to find these conversions.

I've prototyped a checker on top of clang static analyzer (initially
looked at sparse, but couldn't find any documentation or examples).
The results are here [1], search for "warning: user pointer cast".
Sharing in case anybody wants to take a look, will look at them myself
tomorrow.

[1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 19:30         ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: andreyknvl @ 2018-06-28 19:30 UTC (permalink / raw)


On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
>
>
> OK, got it, I'll try to figure out a way to find these conversions.

I've prototyped a checker on top of clang static analyzer (initially
looked at sparse, but couldn't find any documentation or examples).
The results are here [1], search for "warning: user pointer cast".
Sharing in case anybody wants to take a look, will look at them myself
tomorrow.

[1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 19:30         ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-28 19:30 UTC (permalink / raw)


On Wed, Jun 27, 2018@5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
>
>
> OK, got it, I'll try to figure out a way to find these conversions.

I've prototyped a checker on top of clang static analyzer (initially
looked at sparse, but couldn't find any documentation or examples).
The results are here [1], search for "warning: user pointer cast".
Sharing in case anybody wants to take a look, will look at them myself
tomorrow.

[1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 19:30         ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-28 19:30 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben

On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
>
>
> OK, got it, I'll try to figure out a way to find these conversions.

I've prototyped a checker on top of clang static analyzer (initially
looked at sparse, but couldn't find any documentation or examples).
The results are here [1], search for "warning: user pointer cast".
Sharing in case anybody wants to take a look, will look at them myself
tomorrow.

[1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 19:30         ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-28 19:30 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 27, 2018 at 5:05 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
>
>
> OK, got it, I'll try to figure out a way to find these conversions.

I've prototyped a checker on top of clang static analyzer (initially
looked at sparse, but couldn't find any documentation or examples).
The results are here [1], search for "warning: user pointer cast".
Sharing in case anybody wants to take a look, will look at them myself
tomorrow.

[1] https://gist.github.com/xairy/433edd5c86456a64026247cb2fef2115

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-28 14:48                   ` Catalin Marinas
                                       ` (4 preceding siblings ...)
  (?)
@ 2018-06-28 15:28                     ` Luc Van Oostenryck
  -1 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 15:28 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro, nd, Linux ARM,
	Kostya Serebryany, Greg Kroah-Hartman, LKML, Lee Smith,
	Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Thu, Jun 28, 2018 at 03:48:59PM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> > On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > > __attribute__ that could be used to warn of such conversion.
> > > > 
> > > > sparse doesn't have such attribute but would an new option that would warn
> > > > on such cast be a solution for your case?
> > > 
> > > I can't tell for sure whether such sparse option would be the full
> > > solution but detecting explicit __user pointer casts to long is a good
> > > starting point. So far this patchset pretty much relies on detecting
> > > a syscall failure and trying to figure out why, patching the kernel. It
> > > doesn't really scale.
> > 
> > OK, I'll add such an option this evening.
> 
> That's great, thanks. I think this should cover casting pointers to any
> integer types, not just "unsigned long" (e.g. long long).

Yes, of course.
 
> The only downside is that with this patchset the untagging can be done
> after the conversion to ulong (get_user_pages()) as that's where the
> problem was noticed. With a new sparse feature, we'd have to annotate
> the conversion sites (not sure how many until we run the tool though).

I've done a lot of hacking on sparse and as such I run a lot of tests.
What I see with these tests is that a lot of annotations are wrong or
missing so I'm very reluctant to add another attribute. Even more so
one that would be only slightly different than an existing one. OTOH,
if it's something localized or a one-shot and there is a need, ...
why not?

What would you ideally need?

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 15:28                     ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 15:28 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro, nd, Linux ARM,
	Kostya Serebryany, Greg Kroah-Hartman, LKML, Lee Smith,
	Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Thu, Jun 28, 2018 at 03:48:59PM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> > On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > > __attribute__ that could be used to warn of such conversion.
> > > > 
> > > > sparse doesn't have such attribute but would an new option that would warn
> > > > on such cast be a solution for your case?
> > > 
> > > I can't tell for sure whether such sparse option would be the full
> > > solution but detecting explicit __user pointer casts to long is a good
> > > starting point. So far this patchset pretty much relies on detecting
> > > a syscall failure and trying to figure out why, patching the kernel. It
> > > doesn't really scale.
> > 
> > OK, I'll add such an option this evening.
> 
> That's great, thanks. I think this should cover casting pointers to any
> integer types, not just "unsigned long" (e.g. long long).

Yes, of course.
 
> The only downside is that with this patchset the untagging can be done
> after the conversion to ulong (get_user_pages()) as that's where the
> problem was noticed. With a new sparse feature, we'd have to annotate
> the conversion sites (not sure how many until we run the tool though).

I've done a lot of hacking on sparse and as such I run a lot of tests.
What I see with these tests is that a lot of annotations are wrong or
missing so I'm very reluctant to add another attribute. Even more so
one that would be only slightly different than an existing one. OTOH,
if it's something localized or a one-shot and there is a need, ...
why not?

What would you ideally need?

-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 15:28                     ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: luc.vanoostenryck @ 2018-06-28 15:28 UTC (permalink / raw)


On Thu, Jun 28, 2018 at 03:48:59PM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> > On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > > __attribute__ that could be used to warn of such conversion.
> > > > 
> > > > sparse doesn't have such attribute but would an new option that would warn
> > > > on such cast be a solution for your case?
> > > 
> > > I can't tell for sure whether such sparse option would be the full
> > > solution but detecting explicit __user pointer casts to long is a good
> > > starting point. So far this patchset pretty much relies on detecting
> > > a syscall failure and trying to figure out why, patching the kernel. It
> > > doesn't really scale.
> > 
> > OK, I'll add such an option this evening.
> 
> That's great, thanks. I think this should cover casting pointers to any
> integer types, not just "unsigned long" (e.g. long long).

Yes, of course.
 
> The only downside is that with this patchset the untagging can be done
> after the conversion to ulong (get_user_pages()) as that's where the
> problem was noticed. With a new sparse feature, we'd have to annotate
> the conversion sites (not sure how many until we run the tool though).

I've done a lot of hacking on sparse and as such I run a lot of tests.
What I see with these tests is that a lot of annotations are wrong or
missing so I'm very reluctant to add another attribute. Even more so
one that would be only slightly different than an existing one. OTOH,
if it's something localized or a one-shot and there is a need, ...
why not?

What would you ideally need?

-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 15:28                     ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 15:28 UTC (permalink / raw)


On Thu, Jun 28, 2018@03:48:59PM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018@12:46:11PM +0200, Luc Van Oostenryck wrote:
> > On Thu, Jun 28, 2018@11:27:42AM +0100, Catalin Marinas wrote:
> > > On Thu, Jun 28, 2018@08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > > On Wed, Jun 27, 2018@06:17:58PM +0100, Catalin Marinas wrote:
> > > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > > __attribute__ that could be used to warn of such conversion.
> > > > 
> > > > sparse doesn't have such attribute but would an new option that would warn
> > > > on such cast be a solution for your case?
> > > 
> > > I can't tell for sure whether such sparse option would be the full
> > > solution but detecting explicit __user pointer casts to long is a good
> > > starting point. So far this patchset pretty much relies on detecting
> > > a syscall failure and trying to figure out why, patching the kernel. It
> > > doesn't really scale.
> > 
> > OK, I'll add such an option this evening.
> 
> That's great, thanks. I think this should cover casting pointers to any
> integer types, not just "unsigned long" (e.g. long long).

Yes, of course.
 
> The only downside is that with this patchset the untagging can be done
> after the conversion to ulong (get_user_pages()) as that's where the
> problem was noticed. With a new sparse feature, we'd have to annotate
> the conversion sites (not sure how many until we run the tool though).

I've done a lot of hacking on sparse and as such I run a lot of tests.
What I see with these tests is that a lot of annotations are wrong or
missing so I'm very reluctant to add another attribute. Even more so
one that would be only slightly different than an existing one. OTOH,
if it's something localized or a one-shot and there is a need, ...
why not?

What would you ideally need?

-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 15:28                     ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 15:28 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro

On Thu, Jun 28, 2018 at 03:48:59PM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> > On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > > __attribute__ that could be used to warn of such conversion.
> > > > 
> > > > sparse doesn't have such attribute but would an new option that would warn
> > > > on such cast be a solution for your case?
> > > 
> > > I can't tell for sure whether such sparse option would be the full
> > > solution but detecting explicit __user pointer casts to long is a good
> > > starting point. So far this patchset pretty much relies on detecting
> > > a syscall failure and trying to figure out why, patching the kernel. It
> > > doesn't really scale.
> > 
> > OK, I'll add such an option this evening.
> 
> That's great, thanks. I think this should cover casting pointers to any
> integer types, not just "unsigned long" (e.g. long long).

Yes, of course.
 
> The only downside is that with this patchset the untagging can be done
> after the conversion to ulong (get_user_pages()) as that's where the
> problem was noticed. With a new sparse feature, we'd have to annotate
> the conversion sites (not sure how many until we run the tool though).

I've done a lot of hacking on sparse and as such I run a lot of tests.
What I see with these tests is that a lot of annotations are wrong or
missing so I'm very reluctant to add another attribute. Even more so
one that would be only slightly different than an existing one. OTOH,
if it's something localized or a one-shot and there is a need, ...
why not?

What would you ideally need?

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 15:28                     ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 15:28 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro

On Thu, Jun 28, 2018 at 03:48:59PM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> > On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > > __attribute__ that could be used to warn of such conversion.
> > > > 
> > > > sparse doesn't have such attribute but would an new option that would warn
> > > > on such cast be a solution for your case?
> > > 
> > > I can't tell for sure whether such sparse option would be the full
> > > solution but detecting explicit __user pointer casts to long is a good
> > > starting point. So far this patchset pretty much relies on detecting
> > > a syscall failure and trying to figure out why, patching the kernel. It
> > > doesn't really scale.
> > 
> > OK, I'll add such an option this evening.
> 
> That's great, thanks. I think this should cover casting pointers to any
> integer types, not just "unsigned long" (e.g. long long).

Yes, of course.
 
> The only downside is that with this patchset the untagging can be done
> after the conversion to ulong (get_user_pages()) as that's where the
> problem was noticed. With a new sparse feature, we'd have to annotate
> the conversion sites (not sure how many until we run the tool though).

I've done a lot of hacking on sparse and as such I run a lot of tests.
What I see with these tests is that a lot of annotations are wrong or
missing so I'm very reluctant to add another attribute. Even more so
one that would be only slightly different than an existing one. OTOH,
if it's something localized or a one-shot and there is a need, ...
why not?

What would you ideally need?

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 15:28                     ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 15:28 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jun 28, 2018 at 03:48:59PM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> > On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > > __attribute__ that could be used to warn of such conversion.
> > > > 
> > > > sparse doesn't have such attribute but would an new option that would warn
> > > > on such cast be a solution for your case?
> > > 
> > > I can't tell for sure whether such sparse option would be the full
> > > solution but detecting explicit __user pointer casts to long is a good
> > > starting point. So far this patchset pretty much relies on detecting
> > > a syscall failure and trying to figure out why, patching the kernel. It
> > > doesn't really scale.
> > 
> > OK, I'll add such an option this evening.
> 
> That's great, thanks. I think this should cover casting pointers to any
> integer types, not just "unsigned long" (e.g. long long).

Yes, of course.
 
> The only downside is that with this patchset the untagging can be done
> after the conversion to ulong (get_user_pages()) as that's where the
> problem was noticed. With a new sparse feature, we'd have to annotate
> the conversion sites (not sure how many until we run the tool though).

I've done a lot of hacking on sparse and as such I run a lot of tests.
What I see with these tests is that a lot of annotations are wrong or
missing so I'm very reluctant to add another attribute. Even more so
one that would be only slightly different than an existing one. OTOH,
if it's something localized or a one-shot and there is a need, ...
why not?

What would you ideally need?

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-28 10:46                 ` Luc Van Oostenryck
                                     ` (4 preceding siblings ...)
  (?)
@ 2018-06-28 14:48                   ` Catalin Marinas
  -1 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 14:48 UTC (permalink / raw)
  To: Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro, nd, Linux ARM,
	Kostya Serebryany, Greg Kroah-Hartman, LKML, Lee Smith,
	Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > __attribute__ that could be used to warn of such conversion.
> > > 
> > > sparse doesn't have such attribute but would an new option that would warn
> > > on such cast be a solution for your case?
> > 
> > I can't tell for sure whether such sparse option would be the full
> > solution but detecting explicit __user pointer casts to long is a good
> > starting point. So far this patchset pretty much relies on detecting
> > a syscall failure and trying to figure out why, patching the kernel. It
> > doesn't really scale.
> 
> OK, I'll add such an option this evening.

That's great, thanks. I think this should cover casting pointers to any
integer types, not just "unsigned long" (e.g. long long).

The only downside is that with this patchset the untagging can be done
after the conversion to ulong (get_user_pages()) as that's where the
problem was noticed. With a new sparse feature, we'd have to annotate
the conversion sites (not sure how many until we run the tool though).

> > As a side note, we have cases in the user-kernel ABI where the user
> > address type is "unsigned long": mmap() and friends. My feedback on an
> > early version of this patchset was to always require untagged pointers
> > coming from user space on such syscalls, so no need for explicit
> > untagging.
> 
> Mmmm yes.
> I tend to favor a sort of opposite approach. When we have an address
> that must not be dereferenced as-such (and sometimes when the address
> can be from both __user & __kernel space) I prefer to use a ulong
> which will force the use of the required operation before being
> able to do any sort of dereferencing and this won't need horrible
> casts with __force (it, of course, all depends on the full context).

I agree. That's what the kernel uses in functions like get_user_pages()
which take ulong as an argument. Similarly mmap() and friends don't
expect the pointer to be dereferenced, hence the ulong argument. The
interesting part that the man page (and the C library header
declaration) shows such address argument as void *. We could add a
syscall wrapper in the arch code, only that it doesn't feel consistent
with the "rule" that ulong addresses are not actually tagged pointers.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 14:48                   ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 14:48 UTC (permalink / raw)
  To: Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro, nd, Linux ARM,
	Kostya Serebryany, Greg Kroah-Hartman, LKML, Lee Smith,
	Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > __attribute__ that could be used to warn of such conversion.
> > > 
> > > sparse doesn't have such attribute but would an new option that would warn
> > > on such cast be a solution for your case?
> > 
> > I can't tell for sure whether such sparse option would be the full
> > solution but detecting explicit __user pointer casts to long is a good
> > starting point. So far this patchset pretty much relies on detecting
> > a syscall failure and trying to figure out why, patching the kernel. It
> > doesn't really scale.
> 
> OK, I'll add such an option this evening.

That's great, thanks. I think this should cover casting pointers to any
integer types, not just "unsigned long" (e.g. long long).

The only downside is that with this patchset the untagging can be done
after the conversion to ulong (get_user_pages()) as that's where the
problem was noticed. With a new sparse feature, we'd have to annotate
the conversion sites (not sure how many until we run the tool though).

> > As a side note, we have cases in the user-kernel ABI where the user
> > address type is "unsigned long": mmap() and friends. My feedback on an
> > early version of this patchset was to always require untagged pointers
> > coming from user space on such syscalls, so no need for explicit
> > untagging.
> 
> Mmmm yes.
> I tend to favor a sort of opposite approach. When we have an address
> that must not be dereferenced as-such (and sometimes when the address
> can be from both __user & __kernel space) I prefer to use a ulong
> which will force the use of the required operation before being
> able to do any sort of dereferencing and this won't need horrible
> casts with __force (it, of course, all depends on the full context).

I agree. That's what the kernel uses in functions like get_user_pages()
which take ulong as an argument. Similarly mmap() and friends don't
expect the pointer to be dereferenced, hence the ulong argument. The
interesting part that the man page (and the C library header
declaration) shows such address argument as void *. We could add a
syscall wrapper in the arch code, only that it doesn't feel consistent
with the "rule" that ulong addresses are not actually tagged pointers.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 14:48                   ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: catalin.marinas @ 2018-06-28 14:48 UTC (permalink / raw)


On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > __attribute__ that could be used to warn of such conversion.
> > > 
> > > sparse doesn't have such attribute but would an new option that would warn
> > > on such cast be a solution for your case?
> > 
> > I can't tell for sure whether such sparse option would be the full
> > solution but detecting explicit __user pointer casts to long is a good
> > starting point. So far this patchset pretty much relies on detecting
> > a syscall failure and trying to figure out why, patching the kernel. It
> > doesn't really scale.
> 
> OK, I'll add such an option this evening.

That's great, thanks. I think this should cover casting pointers to any
integer types, not just "unsigned long" (e.g. long long).

The only downside is that with this patchset the untagging can be done
after the conversion to ulong (get_user_pages()) as that's where the
problem was noticed. With a new sparse feature, we'd have to annotate
the conversion sites (not sure how many until we run the tool though).

> > As a side note, we have cases in the user-kernel ABI where the user
> > address type is "unsigned long": mmap() and friends. My feedback on an
> > early version of this patchset was to always require untagged pointers
> > coming from user space on such syscalls, so no need for explicit
> > untagging.
> 
> Mmmm yes.
> I tend to favor a sort of opposite approach. When we have an address
> that must not be dereferenced as-such (and sometimes when the address
> can be from both __user & __kernel space) I prefer to use a ulong
> which will force the use of the required operation before being
> able to do any sort of dereferencing and this won't need horrible
> casts with __force (it, of course, all depends on the full context).

I agree. That's what the kernel uses in functions like get_user_pages()
which take ulong as an argument. Similarly mmap() and friends don't
expect the pointer to be dereferenced, hence the ulong argument. The
interesting part that the man page (and the C library header
declaration) shows such address argument as void *. We could add a
syscall wrapper in the arch code, only that it doesn't feel consistent
with the "rule" that ulong addresses are not actually tagged pointers.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 14:48                   ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 14:48 UTC (permalink / raw)


On Thu, Jun 28, 2018@12:46:11PM +0200, Luc Van Oostenryck wrote:
> On Thu, Jun 28, 2018@11:27:42AM +0100, Catalin Marinas wrote:
> > On Thu, Jun 28, 2018@08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > On Wed, Jun 27, 2018@06:17:58PM +0100, Catalin Marinas wrote:
> > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > __attribute__ that could be used to warn of such conversion.
> > > 
> > > sparse doesn't have such attribute but would an new option that would warn
> > > on such cast be a solution for your case?
> > 
> > I can't tell for sure whether such sparse option would be the full
> > solution but detecting explicit __user pointer casts to long is a good
> > starting point. So far this patchset pretty much relies on detecting
> > a syscall failure and trying to figure out why, patching the kernel. It
> > doesn't really scale.
> 
> OK, I'll add such an option this evening.

That's great, thanks. I think this should cover casting pointers to any
integer types, not just "unsigned long" (e.g. long long).

The only downside is that with this patchset the untagging can be done
after the conversion to ulong (get_user_pages()) as that's where the
problem was noticed. With a new sparse feature, we'd have to annotate
the conversion sites (not sure how many until we run the tool though).

> > As a side note, we have cases in the user-kernel ABI where the user
> > address type is "unsigned long": mmap() and friends. My feedback on an
> > early version of this patchset was to always require untagged pointers
> > coming from user space on such syscalls, so no need for explicit
> > untagging.
> 
> Mmmm yes.
> I tend to favor a sort of opposite approach. When we have an address
> that must not be dereferenced as-such (and sometimes when the address
> can be from both __user & __kernel space) I prefer to use a ulong
> which will force the use of the required operation before being
> able to do any sort of dereferencing and this won't need horrible
> casts with __force (it, of course, all depends on the full context).

I agree. That's what the kernel uses in functions like get_user_pages()
which take ulong as an argument. Similarly mmap() and friends don't
expect the pointer to be dereferenced, hence the ulong argument. The
interesting part that the man page (and the C library header
declaration) shows such address argument as void *. We could add a
syscall wrapper in the arch code, only that it doesn't feel consistent
with the "rule" that ulong addresses are not actually tagged pointers.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 14:48                   ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 14:48 UTC (permalink / raw)
  To: Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro

On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > __attribute__ that could be used to warn of such conversion.
> > > 
> > > sparse doesn't have such attribute but would an new option that would warn
> > > on such cast be a solution for your case?
> > 
> > I can't tell for sure whether such sparse option would be the full
> > solution but detecting explicit __user pointer casts to long is a good
> > starting point. So far this patchset pretty much relies on detecting
> > a syscall failure and trying to figure out why, patching the kernel. It
> > doesn't really scale.
> 
> OK, I'll add such an option this evening.

That's great, thanks. I think this should cover casting pointers to any
integer types, not just "unsigned long" (e.g. long long).

The only downside is that with this patchset the untagging can be done
after the conversion to ulong (get_user_pages()) as that's where the
problem was noticed. With a new sparse feature, we'd have to annotate
the conversion sites (not sure how many until we run the tool though).

> > As a side note, we have cases in the user-kernel ABI where the user
> > address type is "unsigned long": mmap() and friends. My feedback on an
> > early version of this patchset was to always require untagged pointers
> > coming from user space on such syscalls, so no need for explicit
> > untagging.
> 
> Mmmm yes.
> I tend to favor a sort of opposite approach. When we have an address
> that must not be dereferenced as-such (and sometimes when the address
> can be from both __user & __kernel space) I prefer to use a ulong
> which will force the use of the required operation before being
> able to do any sort of dereferencing and this won't need horrible
> casts with __force (it, of course, all depends on the full context).

I agree. That's what the kernel uses in functions like get_user_pages()
which take ulong as an argument. Similarly mmap() and friends don't
expect the pointer to be dereferenced, hence the ulong argument. The
interesting part that the man page (and the C library header
declaration) shows such address argument as void *. We could add a
syscall wrapper in the arch code, only that it doesn't feel consistent
with the "rule" that ulong addresses are not actually tagged pointers.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 14:48                   ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 14:48 UTC (permalink / raw)
  To: Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Linux Memory Management List, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Andrey Konovalov, Ramana Radhakrishnan, Al Viro

On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > __attribute__ that could be used to warn of such conversion.
> > > 
> > > sparse doesn't have such attribute but would an new option that would warn
> > > on such cast be a solution for your case?
> > 
> > I can't tell for sure whether such sparse option would be the full
> > solution but detecting explicit __user pointer casts to long is a good
> > starting point. So far this patchset pretty much relies on detecting
> > a syscall failure and trying to figure out why, patching the kernel. It
> > doesn't really scale.
> 
> OK, I'll add such an option this evening.

That's great, thanks. I think this should cover casting pointers to any
integer types, not just "unsigned long" (e.g. long long).

The only downside is that with this patchset the untagging can be done
after the conversion to ulong (get_user_pages()) as that's where the
problem was noticed. With a new sparse feature, we'd have to annotate
the conversion sites (not sure how many until we run the tool though).

> > As a side note, we have cases in the user-kernel ABI where the user
> > address type is "unsigned long": mmap() and friends. My feedback on an
> > early version of this patchset was to always require untagged pointers
> > coming from user space on such syscalls, so no need for explicit
> > untagging.
> 
> Mmmm yes.
> I tend to favor a sort of opposite approach. When we have an address
> that must not be dereferenced as-such (and sometimes when the address
> can be from both __user & __kernel space) I prefer to use a ulong
> which will force the use of the required operation before being
> able to do any sort of dereferencing and this won't need horrible
> casts with __force (it, of course, all depends on the full context).

I agree. That's what the kernel uses in functions like get_user_pages()
which take ulong as an argument. Similarly mmap() and friends don't
expect the pointer to be dereferenced, hence the ulong argument. The
interesting part that the man page (and the C library header
declaration) shows such address argument as void *. We could add a
syscall wrapper in the arch code, only that it doesn't feel consistent
with the "rule" that ulong addresses are not actually tagged pointers.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 14:48                   ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 14:48 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jun 28, 2018 at 12:46:11PM +0200, Luc Van Oostenryck wrote:
> On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> > On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > > sparse is indeed an option. The current implementation doesn't warn on
> > > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > > valid thing in the kernel. I couldn't figure out if there's any other
> > > > __attribute__ that could be used to warn of such conversion.
> > > 
> > > sparse doesn't have such attribute but would an new option that would warn
> > > on such cast be a solution for your case?
> > 
> > I can't tell for sure whether such sparse option would be the full
> > solution but detecting explicit __user pointer casts to long is a good
> > starting point. So far this patchset pretty much relies on detecting
> > a syscall failure and trying to figure out why, patching the kernel. It
> > doesn't really scale.
> 
> OK, I'll add such an option this evening.

That's great, thanks. I think this should cover casting pointers to any
integer types, not just "unsigned long" (e.g. long long).

The only downside is that with this patchset the untagging can be done
after the conversion to ulong (get_user_pages()) as that's where the
problem was noticed. With a new sparse feature, we'd have to annotate
the conversion sites (not sure how many until we run the tool though).

> > As a side note, we have cases in the user-kernel ABI where the user
> > address type is "unsigned long": mmap() and friends. My feedback on an
> > early version of this patchset was to always require untagged pointers
> > coming from user space on such syscalls, so no need for explicit
> > untagging.
> 
> Mmmm yes.
> I tend to favor a sort of opposite approach. When we have an address
> that must not be dereferenced as-such (and sometimes when the address
> can be from both __user & __kernel space) I prefer to use a ulong
> which will force the use of the required operation before being
> able to do any sort of dereferencing and this won't need horrible
> casts with __force (it, of course, all depends on the full context).

I agree. That's what the kernel uses in functions like get_user_pages()
which take ulong as an argument. Similarly mmap() and friends don't
expect the pointer to be dereferenced, hence the ulong argument. The
interesting part that the man page (and the C library header
declaration) shows such address argument as void *. We could add a
syscall wrapper in the arch code, only that it doesn't feel consistent
with the "rule" that ulong addresses are not actually tagged pointers.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-28 10:27               ` Catalin Marinas
                                   ` (4 preceding siblings ...)
  (?)
@ 2018-06-28 10:46                 ` Luc Van Oostenryck
  -1 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 10:46 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan, Andrey Konovalov,
	Lee Smith, Al Viro, nd, Linux ARM, Linux Memory Management List,
	Greg Kroah-Hartman, LKML, Ramana Radhakrishnan, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov

On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > sparse is indeed an option. The current implementation doesn't warn on
> > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > valid thing in the kernel. I couldn't figure out if there's any other
> > > __attribute__ that could be used to warn of such conversion.
> > 
> > sparse doesn't have such attribute but would an new option that would warn
> > on such cast be a solution for your case?
> 
> I can't tell for sure whether such sparse option would be the full
> solution but detecting explicit __user pointer casts to long is a good
> starting point. So far this patchset pretty much relies on detecting
> a syscall failure and trying to figure out why, patching the kernel. It
> doesn't really scale.

OK, I'll add such an option this evening.
 
> As a side note, we have cases in the user-kernel ABI where the user
> address type is "unsigned long": mmap() and friends. My feedback on an
> early version of this patchset was to always require untagged pointers
> coming from user space on such syscalls, so no need for explicit
> untagging.

Mmmm yes.
I tend to favor a sort of opposite approach. When we have an address
that must not be dereferenced as-such (and sometimes when the address
can be from both __user & __kernel space) I prefer to use a ulong
which will force the use of the required operation before being
able to do any sort of dereferencing and this won't need horrible
casts with __force (it, of course, all depends on the full context).

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:46                 ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 10:46 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan, Andrey Konovalov,
	Lee Smith, Al Viro, nd, Linux ARM, Linux Memory Management List,
	Greg Kroah-Hartman, LKML, Ramana Radhakrishnan, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov

On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > sparse is indeed an option. The current implementation doesn't warn on
> > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > valid thing in the kernel. I couldn't figure out if there's any other
> > > __attribute__ that could be used to warn of such conversion.
> > 
> > sparse doesn't have such attribute but would an new option that would warn
> > on such cast be a solution for your case?
> 
> I can't tell for sure whether such sparse option would be the full
> solution but detecting explicit __user pointer casts to long is a good
> starting point. So far this patchset pretty much relies on detecting
> a syscall failure and trying to figure out why, patching the kernel. It
> doesn't really scale.

OK, I'll add such an option this evening.
 
> As a side note, we have cases in the user-kernel ABI where the user
> address type is "unsigned long": mmap() and friends. My feedback on an
> early version of this patchset was to always require untagged pointers
> coming from user space on such syscalls, so no need for explicit
> untagging.

Mmmm yes.
I tend to favor a sort of opposite approach. When we have an address
that must not be dereferenced as-such (and sometimes when the address
can be from both __user & __kernel space) I prefer to use a ulong
which will force the use of the required operation before being
able to do any sort of dereferencing and this won't need horrible
casts with __force (it, of course, all depends on the full context).

-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:46                 ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: luc.vanoostenryck @ 2018-06-28 10:46 UTC (permalink / raw)


On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > sparse is indeed an option. The current implementation doesn't warn on
> > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > valid thing in the kernel. I couldn't figure out if there's any other
> > > __attribute__ that could be used to warn of such conversion.
> > 
> > sparse doesn't have such attribute but would an new option that would warn
> > on such cast be a solution for your case?
> 
> I can't tell for sure whether such sparse option would be the full
> solution but detecting explicit __user pointer casts to long is a good
> starting point. So far this patchset pretty much relies on detecting
> a syscall failure and trying to figure out why, patching the kernel. It
> doesn't really scale.

OK, I'll add such an option this evening.
 
> As a side note, we have cases in the user-kernel ABI where the user
> address type is "unsigned long": mmap() and friends. My feedback on an
> early version of this patchset was to always require untagged pointers
> coming from user space on such syscalls, so no need for explicit
> untagging.

Mmmm yes.
I tend to favor a sort of opposite approach. When we have an address
that must not be dereferenced as-such (and sometimes when the address
can be from both __user & __kernel space) I prefer to use a ulong
which will force the use of the required operation before being
able to do any sort of dereferencing and this won't need horrible
casts with __force (it, of course, all depends on the full context).

-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:46                 ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 10:46 UTC (permalink / raw)


On Thu, Jun 28, 2018@11:27:42AM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018@08:17:59AM +0200, Luc Van Oostenryck wrote:
> > On Wed, Jun 27, 2018@06:17:58PM +0100, Catalin Marinas wrote:
> > > sparse is indeed an option. The current implementation doesn't warn on
> > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > valid thing in the kernel. I couldn't figure out if there's any other
> > > __attribute__ that could be used to warn of such conversion.
> > 
> > sparse doesn't have such attribute but would an new option that would warn
> > on such cast be a solution for your case?
> 
> I can't tell for sure whether such sparse option would be the full
> solution but detecting explicit __user pointer casts to long is a good
> starting point. So far this patchset pretty much relies on detecting
> a syscall failure and trying to figure out why, patching the kernel. It
> doesn't really scale.

OK, I'll add such an option this evening.
 
> As a side note, we have cases in the user-kernel ABI where the user
> address type is "unsigned long": mmap() and friends. My feedback on an
> early version of this patchset was to always require untagged pointers
> coming from user space on such syscalls, so no need for explicit
> untagging.

Mmmm yes.
I tend to favor a sort of opposite approach. When we have an address
that must not be dereferenced as-such (and sometimes when the address
can be from both __user & __kernel space) I prefer to use a ulong
which will force the use of the required operation before being
able to do any sort of dereferencing and this won't need horrible
casts with __force (it, of course, all depends on the full context).

-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:46                 ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 10:46 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan, Andrey Konovalov,
	Lee Smith, Al Viro

On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > sparse is indeed an option. The current implementation doesn't warn on
> > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > valid thing in the kernel. I couldn't figure out if there's any other
> > > __attribute__ that could be used to warn of such conversion.
> > 
> > sparse doesn't have such attribute but would an new option that would warn
> > on such cast be a solution for your case?
> 
> I can't tell for sure whether such sparse option would be the full
> solution but detecting explicit __user pointer casts to long is a good
> starting point. So far this patchset pretty much relies on detecting
> a syscall failure and trying to figure out why, patching the kernel. It
> doesn't really scale.

OK, I'll add such an option this evening.
 
> As a side note, we have cases in the user-kernel ABI where the user
> address type is "unsigned long": mmap() and friends. My feedback on an
> early version of this patchset was to always require untagged pointers
> coming from user space on such syscalls, so no need for explicit
> untagging.

Mmmm yes.
I tend to favor a sort of opposite approach. When we have an address
that must not be dereferenced as-such (and sometimes when the address
can be from both __user & __kernel space) I prefer to use a ulong
which will force the use of the required operation before being
able to do any sort of dereferencing and this won't need horrible
casts with __force (it, of course, all depends on the full context).

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:46                 ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 10:46 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan, Andrey Konovalov,
	Lee Smith, Al Viro

On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > sparse is indeed an option. The current implementation doesn't warn on
> > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > valid thing in the kernel. I couldn't figure out if there's any other
> > > __attribute__ that could be used to warn of such conversion.
> > 
> > sparse doesn't have such attribute but would an new option that would warn
> > on such cast be a solution for your case?
> 
> I can't tell for sure whether such sparse option would be the full
> solution but detecting explicit __user pointer casts to long is a good
> starting point. So far this patchset pretty much relies on detecting
> a syscall failure and trying to figure out why, patching the kernel. It
> doesn't really scale.

OK, I'll add such an option this evening.
 
> As a side note, we have cases in the user-kernel ABI where the user
> address type is "unsigned long": mmap() and friends. My feedback on an
> early version of this patchset was to always require untagged pointers
> coming from user space on such syscalls, so no need for explicit
> untagging.

Mmmm yes.
I tend to favor a sort of opposite approach. When we have an address
that must not be dereferenced as-such (and sometimes when the address
can be from both __user & __kernel space) I prefer to use a ulong
which will force the use of the required operation before being
able to do any sort of dereferencing and this won't need horrible
casts with __force (it, of course, all depends on the full context).

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:46                 ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28 10:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jun 28, 2018 at 11:27:42AM +0100, Catalin Marinas wrote:
> On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> > On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > > sparse is indeed an option. The current implementation doesn't warn on
> > > an explicit cast from (void __user *) to (unsigned long) since that's a
> > > valid thing in the kernel. I couldn't figure out if there's any other
> > > __attribute__ that could be used to warn of such conversion.
> > 
> > sparse doesn't have such attribute but would an new option that would warn
> > on such cast be a solution for your case?
> 
> I can't tell for sure whether such sparse option would be the full
> solution but detecting explicit __user pointer casts to long is a good
> starting point. So far this patchset pretty much relies on detecting
> a syscall failure and trying to figure out why, patching the kernel. It
> doesn't really scale.

OK, I'll add such an option this evening.
 
> As a side note, we have cases in the user-kernel ABI where the user
> address type is "unsigned long": mmap() and friends. My feedback on an
> early version of this patchset was to always require untagged pointers
> coming from user space on such syscalls, so no need for explicit
> untagging.

Mmmm yes.
I tend to favor a sort of opposite approach. When we have an address
that must not be dereferenced as-such (and sometimes when the address
can be from both __user & __kernel space) I prefer to use a ulong
which will force the use of the required operation before being
able to do any sort of dereferencing and this won't need horrible
casts with __force (it, of course, all depends on the full context).

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-28  6:17             ` Luc Van Oostenryck
                                 ` (4 preceding siblings ...)
  (?)
@ 2018-06-28 10:27               ` Catalin Marinas
  -1 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 10:27 UTC (permalink / raw)
  To: Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan, Andrey Konovalov,
	Lee Smith, Al Viro, nd, Linux ARM, Linux Memory Management List,
	Greg Kroah-Hartman, LKML, Ramana Radhakrishnan, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov

On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > sparse is indeed an option. The current implementation doesn't warn on
> > an explicit cast from (void __user *) to (unsigned long) since that's a
> > valid thing in the kernel. I couldn't figure out if there's any other
> > __attribute__ that could be used to warn of such conversion.
> 
> sparse doesn't have such attribute but would an new option that would warn
> on such cast be a solution for your case?

I can't tell for sure whether such sparse option would be the full
solution but detecting explicit __user pointer casts to long is a good
starting point. So far this patchset pretty much relies on detecting
a syscall failure and trying to figure out why, patching the kernel. It
doesn't really scale.

As a side note, we have cases in the user-kernel ABI where the user
address type is "unsigned long": mmap() and friends. My feedback on an
early version of this patchset was to always require untagged pointers
coming from user space on such syscalls, so no need for explicit
untagging.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:27               ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 10:27 UTC (permalink / raw)
  To: Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan, Andrey Konovalov,
	Lee Smith, Al Viro, nd, Linux ARM, Linux Memory Management List,
	Greg Kroah-Hartman, LKML, Ramana Radhakrishnan, Andrew Morton,
	Robin Murphy, Kirill A . Shutemov

On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > sparse is indeed an option. The current implementation doesn't warn on
> > an explicit cast from (void __user *) to (unsigned long) since that's a
> > valid thing in the kernel. I couldn't figure out if there's any other
> > __attribute__ that could be used to warn of such conversion.
> 
> sparse doesn't have such attribute but would an new option that would warn
> on such cast be a solution for your case?

I can't tell for sure whether such sparse option would be the full
solution but detecting explicit __user pointer casts to long is a good
starting point. So far this patchset pretty much relies on detecting
a syscall failure and trying to figure out why, patching the kernel. It
doesn't really scale.

As a side note, we have cases in the user-kernel ABI where the user
address type is "unsigned long": mmap() and friends. My feedback on an
early version of this patchset was to always require untagged pointers
coming from user space on such syscalls, so no need for explicit
untagging.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:27               ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: catalin.marinas @ 2018-06-28 10:27 UTC (permalink / raw)


On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > sparse is indeed an option. The current implementation doesn't warn on
> > an explicit cast from (void __user *) to (unsigned long) since that's a
> > valid thing in the kernel. I couldn't figure out if there's any other
> > __attribute__ that could be used to warn of such conversion.
> 
> sparse doesn't have such attribute but would an new option that would warn
> on such cast be a solution for your case?

I can't tell for sure whether such sparse option would be the full
solution but detecting explicit __user pointer casts to long is a good
starting point. So far this patchset pretty much relies on detecting
a syscall failure and trying to figure out why, patching the kernel. It
doesn't really scale.

As a side note, we have cases in the user-kernel ABI where the user
address type is "unsigned long": mmap() and friends. My feedback on an
early version of this patchset was to always require untagged pointers
coming from user space on such syscalls, so no need for explicit
untagging.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:27               ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 10:27 UTC (permalink / raw)


On Thu, Jun 28, 2018@08:17:59AM +0200, Luc Van Oostenryck wrote:
> On Wed, Jun 27, 2018@06:17:58PM +0100, Catalin Marinas wrote:
> > sparse is indeed an option. The current implementation doesn't warn on
> > an explicit cast from (void __user *) to (unsigned long) since that's a
> > valid thing in the kernel. I couldn't figure out if there's any other
> > __attribute__ that could be used to warn of such conversion.
> 
> sparse doesn't have such attribute but would an new option that would warn
> on such cast be a solution for your case?

I can't tell for sure whether such sparse option would be the full
solution but detecting explicit __user pointer casts to long is a good
starting point. So far this patchset pretty much relies on detecting
a syscall failure and trying to figure out why, patching the kernel. It
doesn't really scale.

As a side note, we have cases in the user-kernel ABI where the user
address type is "unsigned long": mmap() and friends. My feedback on an
early version of this patchset was to always require untagged pointers
coming from user space on such syscalls, so no need for explicit
untagging.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:27               ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 10:27 UTC (permalink / raw)
  To: Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan, Andrey Konovalov,
	Lee Smith, Al Viro

On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > sparse is indeed an option. The current implementation doesn't warn on
> > an explicit cast from (void __user *) to (unsigned long) since that's a
> > valid thing in the kernel. I couldn't figure out if there's any other
> > __attribute__ that could be used to warn of such conversion.
> 
> sparse doesn't have such attribute but would an new option that would warn
> on such cast be a solution for your case?

I can't tell for sure whether such sparse option would be the full
solution but detecting explicit __user pointer casts to long is a good
starting point. So far this patchset pretty much relies on detecting
a syscall failure and trying to figure out why, patching the kernel. It
doesn't really scale.

As a side note, we have cases in the user-kernel ABI where the user
address type is "unsigned long": mmap() and friends. My feedback on an
early version of this patchset was to always require untagged pointers
coming from user space on such syscalls, so no need for explicit
untagging.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:27               ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 10:27 UTC (permalink / raw)
  To: Luc Van Oostenryck
  Cc: Mark Rutland, Kate Stewart, linux-doc, Will Deacon,
	Kostya Serebryany, linux-kselftest, Chintan Pandya, Shuah Khan,
	Ingo Molnar, linux-arch, Jacob Bramley, Dmitry Vyukov,
	Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan, Andrey Konovalov,
	Lee Smith, Al Viro

On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > sparse is indeed an option. The current implementation doesn't warn on
> > an explicit cast from (void __user *) to (unsigned long) since that's a
> > valid thing in the kernel. I couldn't figure out if there's any other
> > __attribute__ that could be used to warn of such conversion.
> 
> sparse doesn't have such attribute but would an new option that would warn
> on such cast be a solution for your case?

I can't tell for sure whether such sparse option would be the full
solution but detecting explicit __user pointer casts to long is a good
starting point. So far this patchset pretty much relies on detecting
a syscall failure and trying to figure out why, patching the kernel. It
doesn't really scale.

As a side note, we have cases in the user-kernel ABI where the user
address type is "unsigned long": mmap() and friends. My feedback on an
early version of this patchset was to always require untagged pointers
coming from user space on such syscalls, so no need for explicit
untagging.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28 10:27               ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-28 10:27 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jun 28, 2018 at 08:17:59AM +0200, Luc Van Oostenryck wrote:
> On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> > sparse is indeed an option. The current implementation doesn't warn on
> > an explicit cast from (void __user *) to (unsigned long) since that's a
> > valid thing in the kernel. I couldn't figure out if there's any other
> > __attribute__ that could be used to warn of such conversion.
> 
> sparse doesn't have such attribute but would an new option that would warn
> on such cast be a solution for your case?

I can't tell for sure whether such sparse option would be the full
solution but detecting explicit __user pointer casts to long is a good
starting point. So far this patchset pretty much relies on detecting
a syscall failure and trying to figure out why, patching the kernel. It
doesn't really scale.

As a side note, we have cases in the user-kernel ABI where the user
address type is "unsigned long": mmap() and friends. My feedback on an
early version of this patchset was to always require untagged pointers
coming from user space on such syscalls, so no need for explicit
untagging.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-27 17:17           ` Catalin Marinas
                               ` (4 preceding siblings ...)
  (?)
@ 2018-06-28  6:17             ` Luc Van Oostenryck
  -1 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28  6:17 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Ramana Radhakrishnan, Andrey Konovalov, Mark Rutland,
	Kate Stewart, linux-doc, Will Deacon, Kostya Serebryany,
	linux-kselftest, Chintan Pandya, Shuah Khan, Ingo Molnar,
	linux-arch, Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov,
	Kees Cook, Ruben Ayrapetyan, Al Viro, nd, Linux ARM,
	Linux Memory Management List, Greg Kroah-Hartman, LKML,
	Lee Smith, Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> 
> sparse is indeed an option. The current implementation doesn't warn on
> an explicit cast from (void __user *) to (unsigned long) since that's a
> valid thing in the kernel. I couldn't figure out if there's any other
> __attribute__ that could be used to warn of such conversion.

Hi,

sparse doesn't have such attribute but would an new option that would warn
on such cast be a solution for your case?

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28  6:17             ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28  6:17 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Ramana Radhakrishnan, Andrey Konovalov, Mark Rutland,
	Kate Stewart, linux-doc, Will Deacon, Kostya Serebryany,
	linux-kselftest, Chintan Pandya, Shuah Khan, Ingo Molnar,
	linux-arch, Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov,
	Kees Cook, Ruben Ayrapetyan, Al Viro, nd, Linux ARM,
	Linux Memory Management List, Greg Kroah-Hartman, LKML,
	Lee Smith, Andrew Morton, Robin Murphy, Kirill A . Shutemov

On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> 
> sparse is indeed an option. The current implementation doesn't warn on
> an explicit cast from (void __user *) to (unsigned long) since that's a
> valid thing in the kernel. I couldn't figure out if there's any other
> __attribute__ that could be used to warn of such conversion.

Hi,

sparse doesn't have such attribute but would an new option that would warn
on such cast be a solution for your case?

-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28  6:17             ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: luc.vanoostenryck @ 2018-06-28  6:17 UTC (permalink / raw)


On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> 
> sparse is indeed an option. The current implementation doesn't warn on
> an explicit cast from (void __user *) to (unsigned long) since that's a
> valid thing in the kernel. I couldn't figure out if there's any other
> __attribute__ that could be used to warn of such conversion.

Hi,

sparse doesn't have such attribute but would an new option that would warn
on such cast be a solution for your case?

-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28  6:17             ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28  6:17 UTC (permalink / raw)


On Wed, Jun 27, 2018@06:17:58PM +0100, Catalin Marinas wrote:
> 
> sparse is indeed an option. The current implementation doesn't warn on
> an explicit cast from (void __user *) to (unsigned long) since that's a
> valid thing in the kernel. I couldn't figure out if there's any other
> __attribute__ that could be used to warn of such conversion.

Hi,

sparse doesn't have such attribute but would an new option that would warn
on such cast be a solution for your case?

-- Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28  6:17             ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28  6:17 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Ramana Radhakrishnan, Andrey Konovalov, Mark Rutland,
	Kate Stewart, linux-doc, Will Deacon, Kostya Serebryany,
	linux-kselftest, Chintan Pandya, Shuah Khan, Ingo Molnar,
	linux-arch, Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov,
	Kees Cook, Ruben Ayrapetyan, Al Viro

On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> 
> sparse is indeed an option. The current implementation doesn't warn on
> an explicit cast from (void __user *) to (unsigned long) since that's a
> valid thing in the kernel. I couldn't figure out if there's any other
> __attribute__ that could be used to warn of such conversion.

Hi,

sparse doesn't have such attribute but would an new option that would warn
on such cast be a solution for your case?

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28  6:17             ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28  6:17 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Ramana Radhakrishnan, Andrey Konovalov, Mark Rutland,
	Kate Stewart, linux-doc, Will Deacon, Kostya Serebryany,
	linux-kselftest, Chintan Pandya, Shuah Khan, Ingo Molnar,
	linux-arch, Jacob Bramley, Dmitry Vyukov, Evgeniy Stepanov,
	Kees Cook, Ruben Ayrapetyan, Al Viro

On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> 
> sparse is indeed an option. The current implementation doesn't warn on
> an explicit cast from (void __user *) to (unsigned long) since that's a
> valid thing in the kernel. I couldn't figure out if there's any other
> __attribute__ that could be used to warn of such conversion.

Hi,

sparse doesn't have such attribute but would an new option that would warn
on such cast be a solution for your case?

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-28  6:17             ` Luc Van Oostenryck
  0 siblings, 0 replies; 153+ messages in thread
From: Luc Van Oostenryck @ 2018-06-28  6:17 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 27, 2018 at 06:17:58PM +0100, Catalin Marinas wrote:
> 
> sparse is indeed an option. The current implementation doesn't warn on
> an explicit cast from (void __user *) to (unsigned long) since that's a
> valid thing in the kernel. I couldn't figure out if there's any other
> __attribute__ that could be used to warn of such conversion.

Hi,

sparse doesn't have such attribute but would an new option that would warn
on such cast be a solution for your case?

-- Luc

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-27 15:08         ` Ramana Radhakrishnan
                             ` (4 preceding siblings ...)
  (?)
@ 2018-06-27 17:17           ` Catalin Marinas
  -1 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-27 17:17 UTC (permalink / raw)
  To: Ramana Radhakrishnan
  Cc: Andrey Konovalov, Mark Rutland, Kate Stewart, linux-doc,
	Will Deacon, Kostya Serebryany, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Al Viro, nd, Linux ARM, Linux Memory Management List,
	Greg Kroah-Hartman, LKML, Lee Smith, Andrew Morton, Robin Murphy,
	Kirill A . Shutemov

On Wed, Jun 27, 2018 at 04:08:09PM +0100, Ramana Radhakrishnan wrote:
> On 27/06/2018 16:05, Andrey Konovalov wrote:
> > On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> > <catalin.marinas@arm.com> wrote:
> >> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
> >>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> >>>> tags into the top byte of each pointer. Userspace programs (such as
> >>>> HWASan, a memory debugging tool [1]) might use this feature and pass
> >>>> tagged user pointers to the kernel through syscalls or other interfaces.
> >>>>
> >>>> This patch makes a few of the kernel interfaces accept tagged user
> >>>> pointers. The kernel is already able to handle user faults with tagged
> >>>> pointers and has the untagged_addr macro, which this patchset reuses.
> >>>>
> >>>> We're not trying to cover all possible ways the kernel accepts user
> >>>> pointers in one patchset, so this one should be considered as a start.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> >>>
> >>> Is there anything I should do to move forward with this?
> >>>
> >>> I've received zero replies to this patch set (v3 and v4) over the last
> >>> month.
> >>
> >> The patches in this series look fine but my concern is that they are not
> >> sufficient and we don't have (yet?) a way to identify where such
> >> annotations are required. You even say in patch 6 that this is "some
> >> initial work for supporting non-zero address tags passed to the kernel".
> >> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> >> not really feasible.
> >>
> >> While I support this work, as a maintainer I'd like to understand
> >> whether we'd be in a continuous chase of ABI breaks with every kernel
> >> release or we have a better way to identify potential issues. Is there
> >> any way to statically analyse conversions from __user ptr to long for
> >> example? Or, could we get the compiler to do this for us?
> > 
> > OK, got it, I'll try to figure out a way to find these conversions.
> 
> This sounds like the kind of thing we should be able to get sparse to do
> already, no ? It's been many years since I last looked at it but I
> thought sparse was the tool of choice in the kernel to do this kind of
> checking.

sparse is indeed an option. The current implementation doesn't warn on
an explicit cast from (void __user *) to (unsigned long) since that's a
valid thing in the kernel. I couldn't figure out if there's any other
__attribute__ that could be used to warn of such conversion.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 17:17           ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-27 17:17 UTC (permalink / raw)
  To: Ramana Radhakrishnan
  Cc: Andrey Konovalov, Mark Rutland, Kate Stewart, linux-doc,
	Will Deacon, Kostya Serebryany, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Al Viro, nd, Linux ARM, Linux Memory Management List,
	Greg Kroah-Hartman, LKML, Lee Smith, Andrew Morton, Robin Murphy,
	Kirill A . Shutemov

On Wed, Jun 27, 2018 at 04:08:09PM +0100, Ramana Radhakrishnan wrote:
> On 27/06/2018 16:05, Andrey Konovalov wrote:
> > On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> > <catalin.marinas@arm.com> wrote:
> >> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
> >>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> >>>> tags into the top byte of each pointer. Userspace programs (such as
> >>>> HWASan, a memory debugging tool [1]) might use this feature and pass
> >>>> tagged user pointers to the kernel through syscalls or other interfaces.
> >>>>
> >>>> This patch makes a few of the kernel interfaces accept tagged user
> >>>> pointers. The kernel is already able to handle user faults with tagged
> >>>> pointers and has the untagged_addr macro, which this patchset reuses.
> >>>>
> >>>> We're not trying to cover all possible ways the kernel accepts user
> >>>> pointers in one patchset, so this one should be considered as a start.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> >>>
> >>> Is there anything I should do to move forward with this?
> >>>
> >>> I've received zero replies to this patch set (v3 and v4) over the last
> >>> month.
> >>
> >> The patches in this series look fine but my concern is that they are not
> >> sufficient and we don't have (yet?) a way to identify where such
> >> annotations are required. You even say in patch 6 that this is "some
> >> initial work for supporting non-zero address tags passed to the kernel".
> >> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> >> not really feasible.
> >>
> >> While I support this work, as a maintainer I'd like to understand
> >> whether we'd be in a continuous chase of ABI breaks with every kernel
> >> release or we have a better way to identify potential issues. Is there
> >> any way to statically analyse conversions from __user ptr to long for
> >> example? Or, could we get the compiler to do this for us?
> > 
> > OK, got it, I'll try to figure out a way to find these conversions.
> 
> This sounds like the kind of thing we should be able to get sparse to do
> already, no ? It's been many years since I last looked at it but I
> thought sparse was the tool of choice in the kernel to do this kind of
> checking.

sparse is indeed an option. The current implementation doesn't warn on
an explicit cast from (void __user *) to (unsigned long) since that's a
valid thing in the kernel. I couldn't figure out if there's any other
__attribute__ that could be used to warn of such conversion.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 17:17           ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: catalin.marinas @ 2018-06-27 17:17 UTC (permalink / raw)


On Wed, Jun 27, 2018 at 04:08:09PM +0100, Ramana Radhakrishnan wrote:
> On 27/06/2018 16:05, Andrey Konovalov wrote:
> > On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> > <catalin.marinas at arm.com> wrote:
> >> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
> >>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> >>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> >>>> tags into the top byte of each pointer. Userspace programs (such as
> >>>> HWASan, a memory debugging tool [1]) might use this feature and pass
> >>>> tagged user pointers to the kernel through syscalls or other interfaces.
> >>>>
> >>>> This patch makes a few of the kernel interfaces accept tagged user
> >>>> pointers. The kernel is already able to handle user faults with tagged
> >>>> pointers and has the untagged_addr macro, which this patchset reuses.
> >>>>
> >>>> We're not trying to cover all possible ways the kernel accepts user
> >>>> pointers in one patchset, so this one should be considered as a start.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> >>>
> >>> Is there anything I should do to move forward with this?
> >>>
> >>> I've received zero replies to this patch set (v3 and v4) over the last
> >>> month.
> >>
> >> The patches in this series look fine but my concern is that they are not
> >> sufficient and we don't have (yet?) a way to identify where such
> >> annotations are required. You even say in patch 6 that this is "some
> >> initial work for supporting non-zero address tags passed to the kernel".
> >> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> >> not really feasible.
> >>
> >> While I support this work, as a maintainer I'd like to understand
> >> whether we'd be in a continuous chase of ABI breaks with every kernel
> >> release or we have a better way to identify potential issues. Is there
> >> any way to statically analyse conversions from __user ptr to long for
> >> example? Or, could we get the compiler to do this for us?
> > 
> > OK, got it, I'll try to figure out a way to find these conversions.
> 
> This sounds like the kind of thing we should be able to get sparse to do
> already, no ? It's been many years since I last looked at it but I
> thought sparse was the tool of choice in the kernel to do this kind of
> checking.

sparse is indeed an option. The current implementation doesn't warn on
an explicit cast from (void __user *) to (unsigned long) since that's a
valid thing in the kernel. I couldn't figure out if there's any other
__attribute__ that could be used to warn of such conversion.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 17:17           ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-27 17:17 UTC (permalink / raw)


On Wed, Jun 27, 2018@04:08:09PM +0100, Ramana Radhakrishnan wrote:
> On 27/06/2018 16:05, Andrey Konovalov wrote:
> > On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> > <catalin.marinas@arm.com> wrote:
> >> On Tue, Jun 26, 2018@02:47:50PM +0200, Andrey Konovalov wrote:
> >>> On Wed, Jun 20, 2018@5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> >>>> tags into the top byte of each pointer. Userspace programs (such as
> >>>> HWASan, a memory debugging tool [1]) might use this feature and pass
> >>>> tagged user pointers to the kernel through syscalls or other interfaces.
> >>>>
> >>>> This patch makes a few of the kernel interfaces accept tagged user
> >>>> pointers. The kernel is already able to handle user faults with tagged
> >>>> pointers and has the untagged_addr macro, which this patchset reuses.
> >>>>
> >>>> We're not trying to cover all possible ways the kernel accepts user
> >>>> pointers in one patchset, so this one should be considered as a start.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> >>>
> >>> Is there anything I should do to move forward with this?
> >>>
> >>> I've received zero replies to this patch set (v3 and v4) over the last
> >>> month.
> >>
> >> The patches in this series look fine but my concern is that they are not
> >> sufficient and we don't have (yet?) a way to identify where such
> >> annotations are required. You even say in patch 6 that this is "some
> >> initial work for supporting non-zero address tags passed to the kernel".
> >> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> >> not really feasible.
> >>
> >> While I support this work, as a maintainer I'd like to understand
> >> whether we'd be in a continuous chase of ABI breaks with every kernel
> >> release or we have a better way to identify potential issues. Is there
> >> any way to statically analyse conversions from __user ptr to long for
> >> example? Or, could we get the compiler to do this for us?
> > 
> > OK, got it, I'll try to figure out a way to find these conversions.
> 
> This sounds like the kind of thing we should be able to get sparse to do
> already, no ? It's been many years since I last looked at it but I
> thought sparse was the tool of choice in the kernel to do this kind of
> checking.

sparse is indeed an option. The current implementation doesn't warn on
an explicit cast from (void __user *) to (unsigned long) since that's a
valid thing in the kernel. I couldn't figure out if there's any other
__attribute__ that could be used to warn of such conversion.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 17:17           ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-27 17:17 UTC (permalink / raw)
  To: Ramana Radhakrishnan
  Cc: Andrey Konovalov, Mark Rutland, Kate Stewart, linux-doc,
	Will Deacon, Kostya Serebryany, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Al Viro

On Wed, Jun 27, 2018 at 04:08:09PM +0100, Ramana Radhakrishnan wrote:
> On 27/06/2018 16:05, Andrey Konovalov wrote:
> > On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> > <catalin.marinas@arm.com> wrote:
> >> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
> >>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> >>>> tags into the top byte of each pointer. Userspace programs (such as
> >>>> HWASan, a memory debugging tool [1]) might use this feature and pass
> >>>> tagged user pointers to the kernel through syscalls or other interfaces.
> >>>>
> >>>> This patch makes a few of the kernel interfaces accept tagged user
> >>>> pointers. The kernel is already able to handle user faults with tagged
> >>>> pointers and has the untagged_addr macro, which this patchset reuses.
> >>>>
> >>>> We're not trying to cover all possible ways the kernel accepts user
> >>>> pointers in one patchset, so this one should be considered as a start.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> >>>
> >>> Is there anything I should do to move forward with this?
> >>>
> >>> I've received zero replies to this patch set (v3 and v4) over the last
> >>> month.
> >>
> >> The patches in this series look fine but my concern is that they are not
> >> sufficient and we don't have (yet?) a way to identify where such
> >> annotations are required. You even say in patch 6 that this is "some
> >> initial work for supporting non-zero address tags passed to the kernel".
> >> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> >> not really feasible.
> >>
> >> While I support this work, as a maintainer I'd like to understand
> >> whether we'd be in a continuous chase of ABI breaks with every kernel
> >> release or we have a better way to identify potential issues. Is there
> >> any way to statically analyse conversions from __user ptr to long for
> >> example? Or, could we get the compiler to do this for us?
> > 
> > OK, got it, I'll try to figure out a way to find these conversions.
> 
> This sounds like the kind of thing we should be able to get sparse to do
> already, no ? It's been many years since I last looked at it but I
> thought sparse was the tool of choice in the kernel to do this kind of
> checking.

sparse is indeed an option. The current implementation doesn't warn on
an explicit cast from (void __user *) to (unsigned long) since that's a
valid thing in the kernel. I couldn't figure out if there's any other
__attribute__ that could be used to warn of such conversion.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 17:17           ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-27 17:17 UTC (permalink / raw)
  To: Ramana Radhakrishnan
  Cc: Andrey Konovalov, Mark Rutland, Kate Stewart, linux-doc,
	Will Deacon, Kostya Serebryany, linux-kselftest, Chintan Pandya,
	Shuah Khan, Ingo Molnar, linux-arch, Jacob Bramley,
	Dmitry Vyukov, Evgeniy Stepanov, Kees Cook, Ruben Ayrapetyan,
	Al Viro

On Wed, Jun 27, 2018 at 04:08:09PM +0100, Ramana Radhakrishnan wrote:
> On 27/06/2018 16:05, Andrey Konovalov wrote:
> > On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> > <catalin.marinas@arm.com> wrote:
> >> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
> >>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> >>>> tags into the top byte of each pointer. Userspace programs (such as
> >>>> HWASan, a memory debugging tool [1]) might use this feature and pass
> >>>> tagged user pointers to the kernel through syscalls or other interfaces.
> >>>>
> >>>> This patch makes a few of the kernel interfaces accept tagged user
> >>>> pointers. The kernel is already able to handle user faults with tagged
> >>>> pointers and has the untagged_addr macro, which this patchset reuses.
> >>>>
> >>>> We're not trying to cover all possible ways the kernel accepts user
> >>>> pointers in one patchset, so this one should be considered as a start.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> >>>
> >>> Is there anything I should do to move forward with this?
> >>>
> >>> I've received zero replies to this patch set (v3 and v4) over the last
> >>> month.
> >>
> >> The patches in this series look fine but my concern is that they are not
> >> sufficient and we don't have (yet?) a way to identify where such
> >> annotations are required. You even say in patch 6 that this is "some
> >> initial work for supporting non-zero address tags passed to the kernel".
> >> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> >> not really feasible.
> >>
> >> While I support this work, as a maintainer I'd like to understand
> >> whether we'd be in a continuous chase of ABI breaks with every kernel
> >> release or we have a better way to identify potential issues. Is there
> >> any way to statically analyse conversions from __user ptr to long for
> >> example? Or, could we get the compiler to do this for us?
> > 
> > OK, got it, I'll try to figure out a way to find these conversions.
> 
> This sounds like the kind of thing we should be able to get sparse to do
> already, no ? It's been many years since I last looked at it but I
> thought sparse was the tool of choice in the kernel to do this kind of
> checking.

sparse is indeed an option. The current implementation doesn't warn on
an explicit cast from (void __user *) to (unsigned long) since that's a
valid thing in the kernel. I couldn't figure out if there's any other
__attribute__ that could be used to warn of such conversion.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 17:17           ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-27 17:17 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 27, 2018 at 04:08:09PM +0100, Ramana Radhakrishnan wrote:
> On 27/06/2018 16:05, Andrey Konovalov wrote:
> > On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> > <catalin.marinas@arm.com> wrote:
> >> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
> >>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> >>>> tags into the top byte of each pointer. Userspace programs (such as
> >>>> HWASan, a memory debugging tool [1]) might use this feature and pass
> >>>> tagged user pointers to the kernel through syscalls or other interfaces.
> >>>>
> >>>> This patch makes a few of the kernel interfaces accept tagged user
> >>>> pointers. The kernel is already able to handle user faults with tagged
> >>>> pointers and has the untagged_addr macro, which this patchset reuses.
> >>>>
> >>>> We're not trying to cover all possible ways the kernel accepts user
> >>>> pointers in one patchset, so this one should be considered as a start.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> >>>
> >>> Is there anything I should do to move forward with this?
> >>>
> >>> I've received zero replies to this patch set (v3 and v4) over the last
> >>> month.
> >>
> >> The patches in this series look fine but my concern is that they are not
> >> sufficient and we don't have (yet?) a way to identify where such
> >> annotations are required. You even say in patch 6 that this is "some
> >> initial work for supporting non-zero address tags passed to the kernel".
> >> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> >> not really feasible.
> >>
> >> While I support this work, as a maintainer I'd like to understand
> >> whether we'd be in a continuous chase of ABI breaks with every kernel
> >> release or we have a better way to identify potential issues. Is there
> >> any way to statically analyse conversions from __user ptr to long for
> >> example? Or, could we get the compiler to do this for us?
> > 
> > OK, got it, I'll try to figure out a way to find these conversions.
> 
> This sounds like the kind of thing we should be able to get sparse to do
> already, no ? It's been many years since I last looked at it but I
> thought sparse was the tool of choice in the kernel to do this kind of
> checking.

sparse is indeed an option. The current implementation doesn't warn on
an explicit cast from (void __user *) to (unsigned long) since that's a
valid thing in the kernel. I couldn't figure out if there's any other
__attribute__ that could be used to warn of such conversion.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-27 15:05       ` Andrey Konovalov
                           ` (4 preceding siblings ...)
  (?)
@ 2018-06-27 15:08         ` Ramana Radhakrishnan
  -1 siblings, 0 replies; 153+ messages in thread
From: Ramana Radhakrishnan @ 2018-06-27 15:08 UTC (permalink / raw)
  To: Andrey Konovalov, Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Evgeniy Stepanov, nd

On 27/06/2018 16:05, Andrey Konovalov wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> Hi Andrey,
>>
>> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
>>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>>>> tags into the top byte of each pointer. Userspace programs (such as
>>>> HWASan, a memory debugging tool [1]) might use this feature and pass
>>>> tagged user pointers to the kernel through syscalls or other interfaces.
>>>>
>>>> This patch makes a few of the kernel interfaces accept tagged user
>>>> pointers. The kernel is already able to handle user faults with tagged
>>>> pointers and has the untagged_addr macro, which this patchset reuses.
>>>>
>>>> We're not trying to cover all possible ways the kernel accepts user
>>>> pointers in one patchset, so this one should be considered as a start.
>>>>
>>>> Thanks!
>>>>
>>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>>
>>> Is there anything I should do to move forward with this?
>>>
>>> I've received zero replies to this patch set (v3 and v4) over the last
>>> month.
>>
>> The patches in this series look fine but my concern is that they are not
>> sufficient and we don't have (yet?) a way to identify where such
>> annotations are required. You even say in patch 6 that this is "some
>> initial work for supporting non-zero address tags passed to the kernel".
>> Unfortunately, merging (or relaxing) an ABI without a clear picture is
>> not really feasible.
>>
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
> 
> 
> OK, got it, I'll try to figure out a way to find these conversions.


This sounds like the kind of thing we should be able to get sparse to do
already, no ? It's been many years since I last looked at it but I
thought sparse was the tool of choice in the kernel to do this kind of
checking.

regards
Ramana



> 
> Thanks!
> 


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 15:08         ` Ramana Radhakrishnan
  0 siblings, 0 replies; 153+ messages in thread
From: Ramana Radhakrishnan @ 2018-06-27 15:08 UTC (permalink / raw)
  To: Andrey Konovalov, Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Evgeniy Stepanov, nd

On 27/06/2018 16:05, Andrey Konovalov wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> Hi Andrey,
>>
>> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
>>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>>>> tags into the top byte of each pointer. Userspace programs (such as
>>>> HWASan, a memory debugging tool [1]) might use this feature and pass
>>>> tagged user pointers to the kernel through syscalls or other interfaces.
>>>>
>>>> This patch makes a few of the kernel interfaces accept tagged user
>>>> pointers. The kernel is already able to handle user faults with tagged
>>>> pointers and has the untagged_addr macro, which this patchset reuses.
>>>>
>>>> We're not trying to cover all possible ways the kernel accepts user
>>>> pointers in one patchset, so this one should be considered as a start.
>>>>
>>>> Thanks!
>>>>
>>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>>
>>> Is there anything I should do to move forward with this?
>>>
>>> I've received zero replies to this patch set (v3 and v4) over the last
>>> month.
>>
>> The patches in this series look fine but my concern is that they are not
>> sufficient and we don't have (yet?) a way to identify where such
>> annotations are required. You even say in patch 6 that this is "some
>> initial work for supporting non-zero address tags passed to the kernel".
>> Unfortunately, merging (or relaxing) an ABI without a clear picture is
>> not really feasible.
>>
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
> 
> 
> OK, got it, I'll try to figure out a way to find these conversions.


This sounds like the kind of thing we should be able to get sparse to do
already, no ? It's been many years since I last looked at it but I
thought sparse was the tool of choice in the kernel to do this kind of
checking.

regards
Ramana



> 
> Thanks!
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 15:08         ` Ramana Radhakrishnan
  0 siblings, 0 replies; 153+ messages in thread
From: ramana.radhakrishnan @ 2018-06-27 15:08 UTC (permalink / raw)


On 27/06/2018 16:05, Andrey Konovalov wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
>> Hi Andrey,
>>
>> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
>>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
>>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>>>> tags into the top byte of each pointer. Userspace programs (such as
>>>> HWASan, a memory debugging tool [1]) might use this feature and pass
>>>> tagged user pointers to the kernel through syscalls or other interfaces.
>>>>
>>>> This patch makes a few of the kernel interfaces accept tagged user
>>>> pointers. The kernel is already able to handle user faults with tagged
>>>> pointers and has the untagged_addr macro, which this patchset reuses.
>>>>
>>>> We're not trying to cover all possible ways the kernel accepts user
>>>> pointers in one patchset, so this one should be considered as a start.
>>>>
>>>> Thanks!
>>>>
>>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>>
>>> Is there anything I should do to move forward with this?
>>>
>>> I've received zero replies to this patch set (v3 and v4) over the last
>>> month.
>>
>> The patches in this series look fine but my concern is that they are not
>> sufficient and we don't have (yet?) a way to identify where such
>> annotations are required. You even say in patch 6 that this is "some
>> initial work for supporting non-zero address tags passed to the kernel".
>> Unfortunately, merging (or relaxing) an ABI without a clear picture is
>> not really feasible.
>>
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
> 
> 
> OK, got it, I'll try to figure out a way to find these conversions.


This sounds like the kind of thing we should be able to get sparse to do
already, no ? It's been many years since I last looked at it but I
thought sparse was the tool of choice in the kernel to do this kind of
checking.

regards
Ramana



> 
> Thanks!
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 15:08         ` Ramana Radhakrishnan
  0 siblings, 0 replies; 153+ messages in thread
From: Ramana Radhakrishnan @ 2018-06-27 15:08 UTC (permalink / raw)


On 27/06/2018 16:05, Andrey Konovalov wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> Hi Andrey,
>>
>> On Tue, Jun 26, 2018@02:47:50PM +0200, Andrey Konovalov wrote:
>>> On Wed, Jun 20, 2018@5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>>>> tags into the top byte of each pointer. Userspace programs (such as
>>>> HWASan, a memory debugging tool [1]) might use this feature and pass
>>>> tagged user pointers to the kernel through syscalls or other interfaces.
>>>>
>>>> This patch makes a few of the kernel interfaces accept tagged user
>>>> pointers. The kernel is already able to handle user faults with tagged
>>>> pointers and has the untagged_addr macro, which this patchset reuses.
>>>>
>>>> We're not trying to cover all possible ways the kernel accepts user
>>>> pointers in one patchset, so this one should be considered as a start.
>>>>
>>>> Thanks!
>>>>
>>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>>
>>> Is there anything I should do to move forward with this?
>>>
>>> I've received zero replies to this patch set (v3 and v4) over the last
>>> month.
>>
>> The patches in this series look fine but my concern is that they are not
>> sufficient and we don't have (yet?) a way to identify where such
>> annotations are required. You even say in patch 6 that this is "some
>> initial work for supporting non-zero address tags passed to the kernel".
>> Unfortunately, merging (or relaxing) an ABI without a clear picture is
>> not really feasible.
>>
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
> 
> 
> OK, got it, I'll try to figure out a way to find these conversions.


This sounds like the kind of thing we should be able to get sparse to do
already, no ? It's been many years since I last looked at it but I
thought sparse was the tool of choice in the kernel to do this kind of
checking.

regards
Ramana



> 
> Thanks!
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 15:08         ` Ramana Radhakrishnan
  0 siblings, 0 replies; 153+ messages in thread
From: Ramana Radhakrishnan @ 2018-06-27 15:08 UTC (permalink / raw)
  To: Andrey Konovalov, Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML

On 27/06/2018 16:05, Andrey Konovalov wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> Hi Andrey,
>>
>> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
>>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>>>> tags into the top byte of each pointer. Userspace programs (such as
>>>> HWASan, a memory debugging tool [1]) might use this feature and pass
>>>> tagged user pointers to the kernel through syscalls or other interfaces.
>>>>
>>>> This patch makes a few of the kernel interfaces accept tagged user
>>>> pointers. The kernel is already able to handle user faults with tagged
>>>> pointers and has the untagged_addr macro, which this patchset reuses.
>>>>
>>>> We're not trying to cover all possible ways the kernel accepts user
>>>> pointers in one patchset, so this one should be considered as a start.
>>>>
>>>> Thanks!
>>>>
>>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>>
>>> Is there anything I should do to move forward with this?
>>>
>>> I've received zero replies to this patch set (v3 and v4) over the last
>>> month.
>>
>> The patches in this series look fine but my concern is that they are not
>> sufficient and we don't have (yet?) a way to identify where such
>> annotations are required. You even say in patch 6 that this is "some
>> initial work for supporting non-zero address tags passed to the kernel".
>> Unfortunately, merging (or relaxing) an ABI without a clear picture is
>> not really feasible.
>>
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
> 
> 
> OK, got it, I'll try to figure out a way to find these conversions.


This sounds like the kind of thing we should be able to get sparse to do
already, no ? It's been many years since I last looked at it but I
thought sparse was the tool of choice in the kernel to do this kind of
checking.

regards
Ramana



> 
> Thanks!
> 

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 15:08         ` Ramana Radhakrishnan
  0 siblings, 0 replies; 153+ messages in thread
From: Ramana Radhakrishnan @ 2018-06-27 15:08 UTC (permalink / raw)
  To: Andrey Konovalov, Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Evgeniy Stepanov

On 27/06/2018 16:05, Andrey Konovalov wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> Hi Andrey,
>>
>> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
>>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>>>> tags into the top byte of each pointer. Userspace programs (such as
>>>> HWASan, a memory debugging tool [1]) might use this feature and pass
>>>> tagged user pointers to the kernel through syscalls or other interfaces.
>>>>
>>>> This patch makes a few of the kernel interfaces accept tagged user
>>>> pointers. The kernel is already able to handle user faults with tagged
>>>> pointers and has the untagged_addr macro, which this patchset reuses.
>>>>
>>>> We're not trying to cover all possible ways the kernel accepts user
>>>> pointers in one patchset, so this one should be considered as a start.
>>>>
>>>> Thanks!
>>>>
>>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>>
>>> Is there anything I should do to move forward with this?
>>>
>>> I've received zero replies to this patch set (v3 and v4) over the last
>>> month.
>>
>> The patches in this series look fine but my concern is that they are not
>> sufficient and we don't have (yet?) a way to identify where such
>> annotations are required. You even say in patch 6 that this is "some
>> initial work for supporting non-zero address tags passed to the kernel".
>> Unfortunately, merging (or relaxing) an ABI without a clear picture is
>> not really feasible.
>>
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
> 
> 
> OK, got it, I'll try to figure out a way to find these conversions.


This sounds like the kind of thing we should be able to get sparse to do
already, no ? It's been many years since I last looked at it but I
thought sparse was the tool of choice in the kernel to do this kind of
checking.

regards
Ramana



> 
> Thanks!
> 

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 15:08         ` Ramana Radhakrishnan
  0 siblings, 0 replies; 153+ messages in thread
From: Ramana Radhakrishnan @ 2018-06-27 15:08 UTC (permalink / raw)
  To: linux-arm-kernel

On 27/06/2018 16:05, Andrey Konovalov wrote:
> On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> Hi Andrey,
>>
>> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
>>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>>>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>>>> tags into the top byte of each pointer. Userspace programs (such as
>>>> HWASan, a memory debugging tool [1]) might use this feature and pass
>>>> tagged user pointers to the kernel through syscalls or other interfaces.
>>>>
>>>> This patch makes a few of the kernel interfaces accept tagged user
>>>> pointers. The kernel is already able to handle user faults with tagged
>>>> pointers and has the untagged_addr macro, which this patchset reuses.
>>>>
>>>> We're not trying to cover all possible ways the kernel accepts user
>>>> pointers in one patchset, so this one should be considered as a start.
>>>>
>>>> Thanks!
>>>>
>>>> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>>
>>> Is there anything I should do to move forward with this?
>>>
>>> I've received zero replies to this patch set (v3 and v4) over the last
>>> month.
>>
>> The patches in this series look fine but my concern is that they are not
>> sufficient and we don't have (yet?) a way to identify where such
>> annotations are required. You even say in patch 6 that this is "some
>> initial work for supporting non-zero address tags passed to the kernel".
>> Unfortunately, merging (or relaxing) an ABI without a clear picture is
>> not really feasible.
>>
>> While I support this work, as a maintainer I'd like to understand
>> whether we'd be in a continuous chase of ABI breaks with every kernel
>> release or we have a better way to identify potential issues. Is there
>> any way to statically analyse conversions from __user ptr to long for
>> example? Or, could we get the compiler to do this for us?
> 
> 
> OK, got it, I'll try to figure out a way to find these conversions.


This sounds like the kind of thing we should be able to get sparse to do
already, no ? It's been many years since I last looked at it but I
thought sparse was the tool of choice in the kernel to do this kind of
checking.

regards
Ramana



> 
> Thanks!
> 

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-26 17:29     ` Catalin Marinas
                         ` (3 preceding siblings ...)
  (?)
@ 2018-06-27 15:05       ` Andrey Konovalov
  -1 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-27 15:05 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> Hi Andrey,
>
> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>> > tags into the top byte of each pointer. Userspace programs (such as
>> > HWASan, a memory debugging tool [1]) might use this feature and pass
>> > tagged user pointers to the kernel through syscalls or other interfaces.
>> >
>> > This patch makes a few of the kernel interfaces accept tagged user
>> > pointers. The kernel is already able to handle user faults with tagged
>> > pointers and has the untagged_addr macro, which this patchset reuses.
>> >
>> > We're not trying to cover all possible ways the kernel accepts user
>> > pointers in one patchset, so this one should be considered as a start.
>> >
>> > Thanks!
>> >
>> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>
>> Is there anything I should do to move forward with this?
>>
>> I've received zero replies to this patch set (v3 and v4) over the last
>> month.
>
> The patches in this series look fine but my concern is that they are not
> sufficient and we don't have (yet?) a way to identify where such
> annotations are required. You even say in patch 6 that this is "some
> initial work for supporting non-zero address tags passed to the kernel".
> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> not really feasible.
>
> While I support this work, as a maintainer I'd like to understand
> whether we'd be in a continuous chase of ABI breaks with every kernel
> release or we have a better way to identify potential issues. Is there
> any way to statically analyse conversions from __user ptr to long for
> example? Or, could we get the compiler to do this for us?


OK, got it, I'll try to figure out a way to find these conversions.

Thanks!

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 15:05       ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-27 15:05 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> Hi Andrey,
>
> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>> > tags into the top byte of each pointer. Userspace programs (such as
>> > HWASan, a memory debugging tool [1]) might use this feature and pass
>> > tagged user pointers to the kernel through syscalls or other interfaces.
>> >
>> > This patch makes a few of the kernel interfaces accept tagged user
>> > pointers. The kernel is already able to handle user faults with tagged
>> > pointers and has the untagged_addr macro, which this patchset reuses.
>> >
>> > We're not trying to cover all possible ways the kernel accepts user
>> > pointers in one patchset, so this one should be considered as a start.
>> >
>> > Thanks!
>> >
>> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>
>> Is there anything I should do to move forward with this?
>>
>> I've received zero replies to this patch set (v3 and v4) over the last
>> month.
>
> The patches in this series look fine but my concern is that they are not
> sufficient and we don't have (yet?) a way to identify where such
> annotations are required. You even say in patch 6 that this is "some
> initial work for supporting non-zero address tags passed to the kernel".
> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> not really feasible.
>
> While I support this work, as a maintainer I'd like to understand
> whether we'd be in a continuous chase of ABI breaks with every kernel
> release or we have a better way to identify potential issues. Is there
> any way to statically analyse conversions from __user ptr to long for
> example? Or, could we get the compiler to do this for us?


OK, got it, I'll try to figure out a way to find these conversions.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 15:05       ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: andreyknvl @ 2018-06-27 15:05 UTC (permalink / raw)


On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
<catalin.marinas at arm.com> wrote:
> Hi Andrey,
>
> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
>> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>> > tags into the top byte of each pointer. Userspace programs (such as
>> > HWASan, a memory debugging tool [1]) might use this feature and pass
>> > tagged user pointers to the kernel through syscalls or other interfaces.
>> >
>> > This patch makes a few of the kernel interfaces accept tagged user
>> > pointers. The kernel is already able to handle user faults with tagged
>> > pointers and has the untagged_addr macro, which this patchset reuses.
>> >
>> > We're not trying to cover all possible ways the kernel accepts user
>> > pointers in one patchset, so this one should be considered as a start.
>> >
>> > Thanks!
>> >
>> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>
>> Is there anything I should do to move forward with this?
>>
>> I've received zero replies to this patch set (v3 and v4) over the last
>> month.
>
> The patches in this series look fine but my concern is that they are not
> sufficient and we don't have (yet?) a way to identify where such
> annotations are required. You even say in patch 6 that this is "some
> initial work for supporting non-zero address tags passed to the kernel".
> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> not really feasible.
>
> While I support this work, as a maintainer I'd like to understand
> whether we'd be in a continuous chase of ABI breaks with every kernel
> release or we have a better way to identify potential issues. Is there
> any way to statically analyse conversions from __user ptr to long for
> example? Or, could we get the compiler to do this for us?


OK, got it, I'll try to figure out a way to find these conversions.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 15:05       ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-27 15:05 UTC (permalink / raw)


On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> Hi Andrey,
>
> On Tue, Jun 26, 2018@02:47:50PM +0200, Andrey Konovalov wrote:
>> On Wed, Jun 20, 2018@5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>> > tags into the top byte of each pointer. Userspace programs (such as
>> > HWASan, a memory debugging tool [1]) might use this feature and pass
>> > tagged user pointers to the kernel through syscalls or other interfaces.
>> >
>> > This patch makes a few of the kernel interfaces accept tagged user
>> > pointers. The kernel is already able to handle user faults with tagged
>> > pointers and has the untagged_addr macro, which this patchset reuses.
>> >
>> > We're not trying to cover all possible ways the kernel accepts user
>> > pointers in one patchset, so this one should be considered as a start.
>> >
>> > Thanks!
>> >
>> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>
>> Is there anything I should do to move forward with this?
>>
>> I've received zero replies to this patch set (v3 and v4) over the last
>> month.
>
> The patches in this series look fine but my concern is that they are not
> sufficient and we don't have (yet?) a way to identify where such
> annotations are required. You even say in patch 6 that this is "some
> initial work for supporting non-zero address tags passed to the kernel".
> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> not really feasible.
>
> While I support this work, as a maintainer I'd like to understand
> whether we'd be in a continuous chase of ABI breaks with every kernel
> release or we have a better way to identify potential issues. Is there
> any way to statically analyse conversions from __user ptr to long for
> example? Or, could we get the compiler to do this for us?


OK, got it, I'll try to figure out a way to find these conversions.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 15:05       ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-27 15:05 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben

On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> Hi Andrey,
>
> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>> > tags into the top byte of each pointer. Userspace programs (such as
>> > HWASan, a memory debugging tool [1]) might use this feature and pass
>> > tagged user pointers to the kernel through syscalls or other interfaces.
>> >
>> > This patch makes a few of the kernel interfaces accept tagged user
>> > pointers. The kernel is already able to handle user faults with tagged
>> > pointers and has the untagged_addr macro, which this patchset reuses.
>> >
>> > We're not trying to cover all possible ways the kernel accepts user
>> > pointers in one patchset, so this one should be considered as a start.
>> >
>> > Thanks!
>> >
>> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>
>> Is there anything I should do to move forward with this?
>>
>> I've received zero replies to this patch set (v3 and v4) over the last
>> month.
>
> The patches in this series look fine but my concern is that they are not
> sufficient and we don't have (yet?) a way to identify where such
> annotations are required. You even say in patch 6 that this is "some
> initial work for supporting non-zero address tags passed to the kernel".
> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> not really feasible.
>
> While I support this work, as a maintainer I'd like to understand
> whether we'd be in a continuous chase of ABI breaks with every kernel
> release or we have a better way to identify potential issues. Is there
> any way to statically analyse conversions from __user ptr to long for
> example? Or, could we get the compiler to do this for us?


OK, got it, I'll try to figure out a way to find these conversions.

Thanks!

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-27 15:05       ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-27 15:05 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jun 26, 2018 at 7:29 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> Hi Andrey,
>
> On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
>> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>> > tags into the top byte of each pointer. Userspace programs (such as
>> > HWASan, a memory debugging tool [1]) might use this feature and pass
>> > tagged user pointers to the kernel through syscalls or other interfaces.
>> >
>> > This patch makes a few of the kernel interfaces accept tagged user
>> > pointers. The kernel is already able to handle user faults with tagged
>> > pointers and has the untagged_addr macro, which this patchset reuses.
>> >
>> > We're not trying to cover all possible ways the kernel accepts user
>> > pointers in one patchset, so this one should be considered as a start.
>> >
>> > Thanks!
>> >
>> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>>
>> Is there anything I should do to move forward with this?
>>
>> I've received zero replies to this patch set (v3 and v4) over the last
>> month.
>
> The patches in this series look fine but my concern is that they are not
> sufficient and we don't have (yet?) a way to identify where such
> annotations are required. You even say in patch 6 that this is "some
> initial work for supporting non-zero address tags passed to the kernel".
> Unfortunately, merging (or relaxing) an ABI without a clear picture is
> not really feasible.
>
> While I support this work, as a maintainer I'd like to understand
> whether we'd be in a continuous chase of ABI breaks with every kernel
> release or we have a better way to identify potential issues. Is there
> any way to statically analyse conversions from __user ptr to long for
> example? Or, could we get the compiler to do this for us?


OK, got it, I'll try to figure out a way to find these conversions.

Thanks!

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-26 12:47   ` Andrey Konovalov
                       ` (3 preceding siblings ...)
  (?)
@ 2018-06-26 17:29     ` Catalin Marinas
  -1 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-26 17:29 UTC (permalink / raw)
  To: Andrey Konovalov
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

Hi Andrey,

On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> > tags into the top byte of each pointer. Userspace programs (such as
> > HWASan, a memory debugging tool [1]) might use this feature and pass
> > tagged user pointers to the kernel through syscalls or other interfaces.
> >
> > This patch makes a few of the kernel interfaces accept tagged user
> > pointers. The kernel is already able to handle user faults with tagged
> > pointers and has the untagged_addr macro, which this patchset reuses.
> >
> > We're not trying to cover all possible ways the kernel accepts user
> > pointers in one patchset, so this one should be considered as a start.
> >
> > Thanks!
> >
> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> 
> Is there anything I should do to move forward with this?
> 
> I've received zero replies to this patch set (v3 and v4) over the last
> month.

The patches in this series look fine but my concern is that they are not
sufficient and we don't have (yet?) a way to identify where such
annotations are required. You even say in patch 6 that this is "some
initial work for supporting non-zero address tags passed to the kernel".
Unfortunately, merging (or relaxing) an ABI without a clear picture is
not really feasible.

While I support this work, as a maintainer I'd like to understand
whether we'd be in a continuous chase of ABI breaks with every kernel
release or we have a better way to identify potential issues. Is there
any way to statically analyse conversions from __user ptr to long for
example? Or, could we get the compiler to do this for us?

Thanks.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-26 17:29     ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-26 17:29 UTC (permalink / raw)
  To: Andrey Konovalov
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

Hi Andrey,

On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> > tags into the top byte of each pointer. Userspace programs (such as
> > HWASan, a memory debugging tool [1]) might use this feature and pass
> > tagged user pointers to the kernel through syscalls or other interfaces.
> >
> > This patch makes a few of the kernel interfaces accept tagged user
> > pointers. The kernel is already able to handle user faults with tagged
> > pointers and has the untagged_addr macro, which this patchset reuses.
> >
> > We're not trying to cover all possible ways the kernel accepts user
> > pointers in one patchset, so this one should be considered as a start.
> >
> > Thanks!
> >
> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> 
> Is there anything I should do to move forward with this?
> 
> I've received zero replies to this patch set (v3 and v4) over the last
> month.

The patches in this series look fine but my concern is that they are not
sufficient and we don't have (yet?) a way to identify where such
annotations are required. You even say in patch 6 that this is "some
initial work for supporting non-zero address tags passed to the kernel".
Unfortunately, merging (or relaxing) an ABI without a clear picture is
not really feasible.

While I support this work, as a maintainer I'd like to understand
whether we'd be in a continuous chase of ABI breaks with every kernel
release or we have a better way to identify potential issues. Is there
any way to statically analyse conversions from __user ptr to long for
example? Or, could we get the compiler to do this for us?

Thanks.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-26 17:29     ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: catalin.marinas @ 2018-06-26 17:29 UTC (permalink / raw)


Hi Andrey,

On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> > tags into the top byte of each pointer. Userspace programs (such as
> > HWASan, a memory debugging tool [1]) might use this feature and pass
> > tagged user pointers to the kernel through syscalls or other interfaces.
> >
> > This patch makes a few of the kernel interfaces accept tagged user
> > pointers. The kernel is already able to handle user faults with tagged
> > pointers and has the untagged_addr macro, which this patchset reuses.
> >
> > We're not trying to cover all possible ways the kernel accepts user
> > pointers in one patchset, so this one should be considered as a start.
> >
> > Thanks!
> >
> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> 
> Is there anything I should do to move forward with this?
> 
> I've received zero replies to this patch set (v3 and v4) over the last
> month.

The patches in this series look fine but my concern is that they are not
sufficient and we don't have (yet?) a way to identify where such
annotations are required. You even say in patch 6 that this is "some
initial work for supporting non-zero address tags passed to the kernel".
Unfortunately, merging (or relaxing) an ABI without a clear picture is
not really feasible.

While I support this work, as a maintainer I'd like to understand
whether we'd be in a continuous chase of ABI breaks with every kernel
release or we have a better way to identify potential issues. Is there
any way to statically analyse conversions from __user ptr to long for
example? Or, could we get the compiler to do this for us?

Thanks.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-26 17:29     ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-26 17:29 UTC (permalink / raw)


Hi Andrey,

On Tue, Jun 26, 2018@02:47:50PM +0200, Andrey Konovalov wrote:
> On Wed, Jun 20, 2018@5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> > tags into the top byte of each pointer. Userspace programs (such as
> > HWASan, a memory debugging tool [1]) might use this feature and pass
> > tagged user pointers to the kernel through syscalls or other interfaces.
> >
> > This patch makes a few of the kernel interfaces accept tagged user
> > pointers. The kernel is already able to handle user faults with tagged
> > pointers and has the untagged_addr macro, which this patchset reuses.
> >
> > We're not trying to cover all possible ways the kernel accepts user
> > pointers in one patchset, so this one should be considered as a start.
> >
> > Thanks!
> >
> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> 
> Is there anything I should do to move forward with this?
> 
> I've received zero replies to this patch set (v3 and v4) over the last
> month.

The patches in this series look fine but my concern is that they are not
sufficient and we don't have (yet?) a way to identify where such
annotations are required. You even say in patch 6 that this is "some
initial work for supporting non-zero address tags passed to the kernel".
Unfortunately, merging (or relaxing) an ABI without a clear picture is
not really feasible.

While I support this work, as a maintainer I'd like to understand
whether we'd be in a continuous chase of ABI breaks with every kernel
release or we have a better way to identify potential issues. Is there
any way to statically analyse conversions from __user ptr to long for
example? Or, could we get the compiler to do this for us?

Thanks.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-26 17:29     ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-26 17:29 UTC (permalink / raw)
  To: Andrey Konovalov
  Cc: Will Deacon, Mark Rutland, Robin Murphy, Al Viro, Kees Cook,
	Kate Stewart, Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML,
	Chintan Pandya, Jacob Bramley, Ruben

Hi Andrey,

On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> > tags into the top byte of each pointer. Userspace programs (such as
> > HWASan, a memory debugging tool [1]) might use this feature and pass
> > tagged user pointers to the kernel through syscalls or other interfaces.
> >
> > This patch makes a few of the kernel interfaces accept tagged user
> > pointers. The kernel is already able to handle user faults with tagged
> > pointers and has the untagged_addr macro, which this patchset reuses.
> >
> > We're not trying to cover all possible ways the kernel accepts user
> > pointers in one patchset, so this one should be considered as a start.
> >
> > Thanks!
> >
> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> 
> Is there anything I should do to move forward with this?
> 
> I've received zero replies to this patch set (v3 and v4) over the last
> month.

The patches in this series look fine but my concern is that they are not
sufficient and we don't have (yet?) a way to identify where such
annotations are required. You even say in patch 6 that this is "some
initial work for supporting non-zero address tags passed to the kernel".
Unfortunately, merging (or relaxing) an ABI without a clear picture is
not really feasible.

While I support this work, as a maintainer I'd like to understand
whether we'd be in a continuous chase of ABI breaks with every kernel
release or we have a better way to identify potential issues. Is there
any way to statically analyse conversions from __user ptr to long for
example? Or, could we get the compiler to do this for us?

Thanks.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-26 17:29     ` Catalin Marinas
  0 siblings, 0 replies; 153+ messages in thread
From: Catalin Marinas @ 2018-06-26 17:29 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Andrey,

On Tue, Jun 26, 2018 at 02:47:50PM +0200, Andrey Konovalov wrote:
> On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> > tags into the top byte of each pointer. Userspace programs (such as
> > HWASan, a memory debugging tool [1]) might use this feature and pass
> > tagged user pointers to the kernel through syscalls or other interfaces.
> >
> > This patch makes a few of the kernel interfaces accept tagged user
> > pointers. The kernel is already able to handle user faults with tagged
> > pointers and has the untagged_addr macro, which this patchset reuses.
> >
> > We're not trying to cover all possible ways the kernel accepts user
> > pointers in one patchset, so this one should be considered as a start.
> >
> > Thanks!
> >
> > [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> 
> Is there anything I should do to move forward with this?
> 
> I've received zero replies to this patch set (v3 and v4) over the last
> month.

The patches in this series look fine but my concern is that they are not
sufficient and we don't have (yet?) a way to identify where such
annotations are required. You even say in patch 6 that this is "some
initial work for supporting non-zero address tags passed to the kernel".
Unfortunately, merging (or relaxing) an ABI without a clear picture is
not really feasible.

While I support this work, as a maintainer I'd like to understand
whether we'd be in a continuous chase of ABI breaks with every kernel
release or we have a better way to identify potential issues. Is there
any way to statically analyse conversions from __user ptr to long for
example? Or, could we get the compiler to do this for us?

Thanks.

-- 
Catalin

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
  2018-06-20 15:24 ` Andrey Konovalov
                     ` (2 preceding siblings ...)
  (?)
@ 2018-06-26 12:47   ` Andrey Konovalov
  -1 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-26 12:47 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
	Al Viro, Andrey Konovalov, Kees Cook, Kate Stewart,
	Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML
  Cc: Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov, Lee Smith,
	Ramana Radhakrishnan, Jacob Bramley, Ruben Ayrapetyan,
	Chintan Pandya

On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> tags into the top byte of each pointer. Userspace programs (such as
> HWASan, a memory debugging tool [1]) might use this feature and pass
> tagged user pointers to the kernel through syscalls or other interfaces.
>
> This patch makes a few of the kernel interfaces accept tagged user
> pointers. The kernel is already able to handle user faults with tagged
> pointers and has the untagged_addr macro, which this patchset reuses.
>
> We're not trying to cover all possible ways the kernel accepts user
> pointers in one patchset, so this one should be considered as a start.
>
> Thanks!
>
> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Hi!

Is there anything I should do to move forward with this?

I've received zero replies to this patch set (v3 and v4) over the last month.

Thanks!

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-26 12:47   ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-26 12:47 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
	Al Viro, Andrey Konovalov, Kees Cook, Kate Stewart,
	Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, Linux ARM, linux-doc,
	Linux Memory Management List, linux-arch, linux-kselftest, LKML
  Cc: Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov, Lee Smith,
	Ramana Radhakrishnan, Jacob Bramley, Ruben Ayrapetyan,
	Chintan Pandya

On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> tags into the top byte of each pointer. Userspace programs (such as
> HWASan, a memory debugging tool [1]) might use this feature and pass
> tagged user pointers to the kernel through syscalls or other interfaces.
>
> This patch makes a few of the kernel interfaces accept tagged user
> pointers. The kernel is already able to handle user faults with tagged
> pointers and has the untagged_addr macro, which this patchset reuses.
>
> We're not trying to cover all possible ways the kernel accepts user
> pointers in one patchset, so this one should be considered as a start.
>
> Thanks!
>
> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Hi!

Is there anything I should do to move forward with this?

I've received zero replies to this patch set (v3 and v4) over the last month.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-26 12:47   ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: andreyknvl @ 2018-06-26 12:47 UTC (permalink / raw)


On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl at google.com> wrote:
> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> tags into the top byte of each pointer. Userspace programs (such as
> HWASan, a memory debugging tool [1]) might use this feature and pass
> tagged user pointers to the kernel through syscalls or other interfaces.
>
> This patch makes a few of the kernel interfaces accept tagged user
> pointers. The kernel is already able to handle user faults with tagged
> pointers and has the untagged_addr macro, which this patchset reuses.
>
> We're not trying to cover all possible ways the kernel accepts user
> pointers in one patchset, so this one should be considered as a start.
>
> Thanks!
>
> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Hi!

Is there anything I should do to move forward with this?

I've received zero replies to this patch set (v3 and v4) over the last month.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-26 12:47   ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-26 12:47 UTC (permalink / raw)


On Wed, Jun 20, 2018@5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> tags into the top byte of each pointer. Userspace programs (such as
> HWASan, a memory debugging tool [1]) might use this feature and pass
> tagged user pointers to the kernel through syscalls or other interfaces.
>
> This patch makes a few of the kernel interfaces accept tagged user
> pointers. The kernel is already able to handle user faults with tagged
> pointers and has the untagged_addr macro, which this patchset reuses.
>
> We're not trying to cover all possible ways the kernel accepts user
> pointers in one patchset, so this one should be considered as a start.
>
> Thanks!
>
> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Hi!

Is there anything I should do to move forward with this?

I've received zero replies to this patch set (v3 and v4) over the last month.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-26 12:47   ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-26 12:47 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 20, 2018 at 5:24 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
> tags into the top byte of each pointer. Userspace programs (such as
> HWASan, a memory debugging tool [1]) might use this feature and pass
> tagged user pointers to the kernel through syscalls or other interfaces.
>
> This patch makes a few of the kernel interfaces accept tagged user
> pointers. The kernel is already able to handle user faults with tagged
> pointers and has the untagged_addr macro, which this patchset reuses.
>
> We're not trying to cover all possible ways the kernel accepts user
> pointers in one patchset, so this one should be considered as a start.
>
> Thanks!
>
> [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Hi!

Is there anything I should do to move forward with this?

I've received zero replies to this patch set (v3 and v4) over the last month.

Thanks!

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-20 15:24 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
	Al Viro, Andrey Konovalov, Kees Cook, Kate Stewart,
	Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, linux-arm-kernel, linux-doc,
	linux-mm, linux-arch, linux-kselftest, linux-kernel
  Cc: Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov, Lee Smith,
	Ramana Radhakrishnan, Jacob Bramley, Ruben Ayrapetyan,
	Chintan Pandya

arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.

This patch makes a few of the kernel interfaces accept tagged user
pointers. The kernel is already able to handle user faults with tagged
pointers and has the untagged_addr macro, which this patchset reuses.

We're not trying to cover all possible ways the kernel accepts user
pointers in one patchset, so this one should be considered as a start.

Thanks!

[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Changes in v4:
- Added a selftest for checking that passing tagged pointers to the 
  kernel succeeds.
- Rebased onto 81e97f013 (4.18-rc1+).

Changes in v3:
- Rebased onto e5c51f30 (4.17-rc6+).
- Added linux-arch@ to the list of recipients.

Changes in v2:
- Rebased onto 2d618bdf (4.17-rc3+).
- Removed excessive untagging in gup.c.
- Removed untagging pointers returned from __uaccess_mask_ptr.

Changes in v1:
- Rebased onto 4.17-rc1.

Changes in RFC v2:
- Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of
  defining it for each arch individually.
- Updated Documentation/arm64/tagged-pointers.txt.
- Dropped “mm, arm64: untag user addresses in memory syscalls”.
- Rebased onto 3eb2ce82 (4.16-rc7).

Andrey Konovalov (7):
  arm64: add type casts to untagged_addr macro
  uaccess: add untagged_addr definition for other arches
  arm64: untag user addresses in access_ok and __uaccess_mask_ptr
  mm, arm64: untag user addresses in mm/gup.c
  lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
  arm64: update Documentation/arm64/tagged-pointers.txt
  selftests, arm64: add a selftest for passing tagged pointers to kernel

 Documentation/arm64/tagged-pointers.txt       |  5 +++--
 arch/arm64/include/asm/uaccess.h              | 14 +++++++++-----
 include/linux/uaccess.h                       |  4 ++++
 lib/strncpy_from_user.c                       |  2 ++
 lib/strnlen_user.c                            |  2 ++
 mm/gup.c                                      |  4 ++++
 tools/testing/selftests/arm64/.gitignore      |  1 +
 tools/testing/selftests/arm64/Makefile        | 11 +++++++++++
 .../testing/selftests/arm64/run_tags_test.sh  | 12 ++++++++++++
 tools/testing/selftests/arm64/tags_test.c     | 19 +++++++++++++++++++
 10 files changed, 67 insertions(+), 7 deletions(-)
 create mode 100644 tools/testing/selftests/arm64/.gitignore
 create mode 100644 tools/testing/selftests/arm64/Makefile
 create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
 create mode 100644 tools/testing/selftests/arm64/tags_test.c

-- 
2.18.0.rc1.244.gcf134e6275-goog


^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-20 15:24 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
	Al Viro, Andrey Konovalov, Kees Cook, Kate Stewart,
	Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, linux-arm-kernel, linux-doc,
	linux-mm, linux-arch, linux-kselftest, linux-kernel
  Cc: Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov, Lee Smith,
	Ramana Radhakrishnan, Jacob Bramley, Ruben Ayrapetyan,
	Chintan Pandya

arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.

This patch makes a few of the kernel interfaces accept tagged user
pointers. The kernel is already able to handle user faults with tagged
pointers and has the untagged_addr macro, which this patchset reuses.

We're not trying to cover all possible ways the kernel accepts user
pointers in one patchset, so this one should be considered as a start.

Thanks!

[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Changes in v4:
- Added a selftest for checking that passing tagged pointers to the 
  kernel succeeds.
- Rebased onto 81e97f013 (4.18-rc1+).

Changes in v3:
- Rebased onto e5c51f30 (4.17-rc6+).
- Added linux-arch@ to the list of recipients.

Changes in v2:
- Rebased onto 2d618bdf (4.17-rc3+).
- Removed excessive untagging in gup.c.
- Removed untagging pointers returned from __uaccess_mask_ptr.

Changes in v1:
- Rebased onto 4.17-rc1.

Changes in RFC v2:
- Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of
  defining it for each arch individually.
- Updated Documentation/arm64/tagged-pointers.txt.
- Dropped “mm, arm64: untag user addresses in memory syscalls”.
- Rebased onto 3eb2ce82 (4.16-rc7).

Andrey Konovalov (7):
  arm64: add type casts to untagged_addr macro
  uaccess: add untagged_addr definition for other arches
  arm64: untag user addresses in access_ok and __uaccess_mask_ptr
  mm, arm64: untag user addresses in mm/gup.c
  lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
  arm64: update Documentation/arm64/tagged-pointers.txt
  selftests, arm64: add a selftest for passing tagged pointers to kernel

 Documentation/arm64/tagged-pointers.txt       |  5 +++--
 arch/arm64/include/asm/uaccess.h              | 14 +++++++++-----
 include/linux/uaccess.h                       |  4 ++++
 lib/strncpy_from_user.c                       |  2 ++
 lib/strnlen_user.c                            |  2 ++
 mm/gup.c                                      |  4 ++++
 tools/testing/selftests/arm64/.gitignore      |  1 +
 tools/testing/selftests/arm64/Makefile        | 11 +++++++++++
 .../testing/selftests/arm64/run_tags_test.sh  | 12 ++++++++++++
 tools/testing/selftests/arm64/tags_test.c     | 19 +++++++++++++++++++
 10 files changed, 67 insertions(+), 7 deletions(-)
 create mode 100644 tools/testing/selftests/arm64/.gitignore
 create mode 100644 tools/testing/selftests/arm64/Makefile
 create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
 create mode 100644 tools/testing/selftests/arm64/tags_test.c

-- 
2.18.0.rc1.244.gcf134e6275-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-20 15:24 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: andreyknvl @ 2018-06-20 15:24 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3033 bytes --]

arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.

This patch makes a few of the kernel interfaces accept tagged user
pointers. The kernel is already able to handle user faults with tagged
pointers and has the untagged_addr macro, which this patchset reuses.

We're not trying to cover all possible ways the kernel accepts user
pointers in one patchset, so this one should be considered as a start.

Thanks!

[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Changes in v4:
- Added a selftest for checking that passing tagged pointers to the 
  kernel succeeds.
- Rebased onto 81e97f013 (4.18-rc1+).

Changes in v3:
- Rebased onto e5c51f30 (4.17-rc6+).
- Added linux-arch@ to the list of recipients.

Changes in v2:
- Rebased onto 2d618bdf (4.17-rc3+).
- Removed excessive untagging in gup.c.
- Removed untagging pointers returned from __uaccess_mask_ptr.

Changes in v1:
- Rebased onto 4.17-rc1.

Changes in RFC v2:
- Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of
  defining it for each arch individually.
- Updated Documentation/arm64/tagged-pointers.txt.
- Dropped “mm, arm64: untag user addresses in memory syscalls”.
- Rebased onto 3eb2ce82 (4.16-rc7).

Andrey Konovalov (7):
  arm64: add type casts to untagged_addr macro
  uaccess: add untagged_addr definition for other arches
  arm64: untag user addresses in access_ok and __uaccess_mask_ptr
  mm, arm64: untag user addresses in mm/gup.c
  lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
  arm64: update Documentation/arm64/tagged-pointers.txt
  selftests, arm64: add a selftest for passing tagged pointers to kernel

 Documentation/arm64/tagged-pointers.txt       |  5 +++--
 arch/arm64/include/asm/uaccess.h              | 14 +++++++++-----
 include/linux/uaccess.h                       |  4 ++++
 lib/strncpy_from_user.c                       |  2 ++
 lib/strnlen_user.c                            |  2 ++
 mm/gup.c                                      |  4 ++++
 tools/testing/selftests/arm64/.gitignore      |  1 +
 tools/testing/selftests/arm64/Makefile        | 11 +++++++++++
 .../testing/selftests/arm64/run_tags_test.sh  | 12 ++++++++++++
 tools/testing/selftests/arm64/tags_test.c     | 19 +++++++++++++++++++
 10 files changed, 67 insertions(+), 7 deletions(-)
 create mode 100644 tools/testing/selftests/arm64/.gitignore
 create mode 100644 tools/testing/selftests/arm64/Makefile
 create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
 create mode 100644 tools/testing/selftests/arm64/tags_test.c

-- 
2.18.0.rc1.244.gcf134e6275-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-20 15:24 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)


arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.

This patch makes a few of the kernel interfaces accept tagged user
pointers. The kernel is already able to handle user faults with tagged
pointers and has the untagged_addr macro, which this patchset reuses.

We're not trying to cover all possible ways the kernel accepts user
pointers in one patchset, so this one should be considered as a start.

Thanks!

[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Changes in v4:
- Added a selftest for checking that passing tagged pointers to the 
  kernel succeeds.
- Rebased onto 81e97f013 (4.18-rc1+).

Changes in v3:
- Rebased onto e5c51f30 (4.17-rc6+).
- Added linux-arch@ to the list of recipients.

Changes in v2:
- Rebased onto 2d618bdf (4.17-rc3+).
- Removed excessive untagging in gup.c.
- Removed untagging pointers returned from __uaccess_mask_ptr.

Changes in v1:
- Rebased onto 4.17-rc1.

Changes in RFC v2:
- Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of
  defining it for each arch individually.
- Updated Documentation/arm64/tagged-pointers.txt.
- Dropped “mm, arm64: untag user addresses in memory syscalls”.
- Rebased onto 3eb2ce82 (4.16-rc7).

Andrey Konovalov (7):
  arm64: add type casts to untagged_addr macro
  uaccess: add untagged_addr definition for other arches
  arm64: untag user addresses in access_ok and __uaccess_mask_ptr
  mm, arm64: untag user addresses in mm/gup.c
  lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
  arm64: update Documentation/arm64/tagged-pointers.txt
  selftests, arm64: add a selftest for passing tagged pointers to kernel

 Documentation/arm64/tagged-pointers.txt       |  5 +++--
 arch/arm64/include/asm/uaccess.h              | 14 +++++++++-----
 include/linux/uaccess.h                       |  4 ++++
 lib/strncpy_from_user.c                       |  2 ++
 lib/strnlen_user.c                            |  2 ++
 mm/gup.c                                      |  4 ++++
 tools/testing/selftests/arm64/.gitignore      |  1 +
 tools/testing/selftests/arm64/Makefile        | 11 +++++++++++
 .../testing/selftests/arm64/run_tags_test.sh  | 12 ++++++++++++
 tools/testing/selftests/arm64/tags_test.c     | 19 +++++++++++++++++++
 10 files changed, 67 insertions(+), 7 deletions(-)
 create mode 100644 tools/testing/selftests/arm64/.gitignore
 create mode 100644 tools/testing/selftests/arm64/Makefile
 create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
 create mode 100644 tools/testing/selftests/arm64/tags_test.c

-- 
2.18.0.rc1.244.gcf134e6275-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-20 15:24 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
	Al Viro, Andrey Konovalov, Kees Cook, Kate Stewart,
	Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, linux-arm-kernel, linux-doc,
	linux-mm, linux-arch, linux-kselftest, linux-kernel
  Cc: Chintan Pandya, Jacob Bramley, Ruben Ayrapetyan, Lee Smith,
	Kostya Serebryany, Dmitry Vyukov, Ramana Radhakrishnan,
	Evgeniy Stepanov

arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.

This patch makes a few of the kernel interfaces accept tagged user
pointers. The kernel is already able to handle user faults with tagged
pointers and has the untagged_addr macro, which this patchset reuses.

We're not trying to cover all possible ways the kernel accepts user
pointers in one patchset, so this one should be considered as a start.

Thanks!

[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Changes in v4:
- Added a selftest for checking that passing tagged pointers to the 
  kernel succeeds.
- Rebased onto 81e97f013 (4.18-rc1+).

Changes in v3:
- Rebased onto e5c51f30 (4.17-rc6+).
- Added linux-arch@ to the list of recipients.

Changes in v2:
- Rebased onto 2d618bdf (4.17-rc3+).
- Removed excessive untagging in gup.c.
- Removed untagging pointers returned from __uaccess_mask_ptr.

Changes in v1:
- Rebased onto 4.17-rc1.

Changes in RFC v2:
- Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of
  defining it for each arch individually.
- Updated Documentation/arm64/tagged-pointers.txt.
- Dropped “mm, arm64: untag user addresses in memory syscalls”.
- Rebased onto 3eb2ce82 (4.16-rc7).

Andrey Konovalov (7):
  arm64: add type casts to untagged_addr macro
  uaccess: add untagged_addr definition for other arches
  arm64: untag user addresses in access_ok and __uaccess_mask_ptr
  mm, arm64: untag user addresses in mm/gup.c
  lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
  arm64: update Documentation/arm64/tagged-pointers.txt
  selftests, arm64: add a selftest for passing tagged pointers to kernel

 Documentation/arm64/tagged-pointers.txt       |  5 +++--
 arch/arm64/include/asm/uaccess.h              | 14 +++++++++-----
 include/linux/uaccess.h                       |  4 ++++
 lib/strncpy_from_user.c                       |  2 ++
 lib/strnlen_user.c                            |  2 ++
 mm/gup.c                                      |  4 ++++
 tools/testing/selftests/arm64/.gitignore      |  1 +
 tools/testing/selftests/arm64/Makefile        | 11 +++++++++++
 .../testing/selftests/arm64/run_tags_test.sh  | 12 ++++++++++++
 tools/testing/selftests/arm64/tags_test.c     | 19 +++++++++++++++++++
 10 files changed, 67 insertions(+), 7 deletions(-)
 create mode 100644 tools/testing/selftests/arm64/.gitignore
 create mode 100644 tools/testing/selftests/arm64/Makefile
 create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
 create mode 100644 tools/testing/selftests/arm64/tags_test.c

-- 
2.18.0.rc1.244.gcf134e6275-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-20 15:24 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy,
	Al Viro, Andrey Konovalov, Kees Cook, Kate Stewart,
	Greg Kroah-Hartman, Andrew Morton, Ingo Molnar,
	Kirill A . Shutemov, Shuah Khan, linux-arm-kernel, linux-doc,
	linux-mm, linux-arch, linux-kselftest, linux-kernel
  Cc: Dmitry Vyukov, Kostya Serebryany, Evgeniy Stepanov, Lee Smith,
	Ramana Radhakrishnan, Jacob Bramley, Ruben Ayrapetyan,
	Chintan Pandya

arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.

This patch makes a few of the kernel interfaces accept tagged user
pointers. The kernel is already able to handle user faults with tagged
pointers and has the untagged_addr macro, which this patchset reuses.

We're not trying to cover all possible ways the kernel accepts user
pointers in one patchset, so this one should be considered as a start.

Thanks!

[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Changes in v4:
- Added a selftest for checking that passing tagged pointers to the 
  kernel succeeds.
- Rebased onto 81e97f013 (4.18-rc1+).

Changes in v3:
- Rebased onto e5c51f30 (4.17-rc6+).
- Added linux-arch@ to the list of recipients.

Changes in v2:
- Rebased onto 2d618bdf (4.17-rc3+).
- Removed excessive untagging in gup.c.
- Removed untagging pointers returned from __uaccess_mask_ptr.

Changes in v1:
- Rebased onto 4.17-rc1.

Changes in RFC v2:
- Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of
  defining it for each arch individually.
- Updated Documentation/arm64/tagged-pointers.txt.
- Dropped a??mm, arm64: untag user addresses in memory syscallsa??.
- Rebased onto 3eb2ce82 (4.16-rc7).

Andrey Konovalov (7):
  arm64: add type casts to untagged_addr macro
  uaccess: add untagged_addr definition for other arches
  arm64: untag user addresses in access_ok and __uaccess_mask_ptr
  mm, arm64: untag user addresses in mm/gup.c
  lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
  arm64: update Documentation/arm64/tagged-pointers.txt
  selftests, arm64: add a selftest for passing tagged pointers to kernel

 Documentation/arm64/tagged-pointers.txt       |  5 +++--
 arch/arm64/include/asm/uaccess.h              | 14 +++++++++-----
 include/linux/uaccess.h                       |  4 ++++
 lib/strncpy_from_user.c                       |  2 ++
 lib/strnlen_user.c                            |  2 ++
 mm/gup.c                                      |  4 ++++
 tools/testing/selftests/arm64/.gitignore      |  1 +
 tools/testing/selftests/arm64/Makefile        | 11 +++++++++++
 .../testing/selftests/arm64/run_tags_test.sh  | 12 ++++++++++++
 tools/testing/selftests/arm64/tags_test.c     | 19 +++++++++++++++++++
 10 files changed, 67 insertions(+), 7 deletions(-)
 create mode 100644 tools/testing/selftests/arm64/.gitignore
 create mode 100644 tools/testing/selftests/arm64/Makefile
 create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
 create mode 100644 tools/testing/selftests/arm64/tags_test.c

-- 
2.18.0.rc1.244.gcf134e6275-goog

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH v4 0/7] arm64: untag user pointers passed to the kernel
@ 2018-06-20 15:24 ` Andrey Konovalov
  0 siblings, 0 replies; 153+ messages in thread
From: Andrey Konovalov @ 2018-06-20 15:24 UTC (permalink / raw)
  To: linux-arm-kernel

arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.

This patch makes a few of the kernel interfaces accept tagged user
pointers. The kernel is already able to handle user faults with tagged
pointers and has the untagged_addr macro, which this patchset reuses.

We're not trying to cover all possible ways the kernel accepts user
pointers in one patchset, so this one should be considered as a start.

Thanks!

[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html

Changes in v4:
- Added a selftest for checking that passing tagged pointers to the 
  kernel succeeds.
- Rebased onto 81e97f013 (4.18-rc1+).

Changes in v3:
- Rebased onto e5c51f30 (4.17-rc6+).
- Added linux-arch@ to the list of recipients.

Changes in v2:
- Rebased onto 2d618bdf (4.17-rc3+).
- Removed excessive untagging in gup.c.
- Removed untagging pointers returned from __uaccess_mask_ptr.

Changes in v1:
- Rebased onto 4.17-rc1.

Changes in RFC v2:
- Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of
  defining it for each arch individually.
- Updated Documentation/arm64/tagged-pointers.txt.
- Dropped ?mm, arm64: untag user addresses in memory syscalls?.
- Rebased onto 3eb2ce82 (4.16-rc7).

Andrey Konovalov (7):
  arm64: add type casts to untagged_addr macro
  uaccess: add untagged_addr definition for other arches
  arm64: untag user addresses in access_ok and __uaccess_mask_ptr
  mm, arm64: untag user addresses in mm/gup.c
  lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
  arm64: update Documentation/arm64/tagged-pointers.txt
  selftests, arm64: add a selftest for passing tagged pointers to kernel

 Documentation/arm64/tagged-pointers.txt       |  5 +++--
 arch/arm64/include/asm/uaccess.h              | 14 +++++++++-----
 include/linux/uaccess.h                       |  4 ++++
 lib/strncpy_from_user.c                       |  2 ++
 lib/strnlen_user.c                            |  2 ++
 mm/gup.c                                      |  4 ++++
 tools/testing/selftests/arm64/.gitignore      |  1 +
 tools/testing/selftests/arm64/Makefile        | 11 +++++++++++
 .../testing/selftests/arm64/run_tags_test.sh  | 12 ++++++++++++
 tools/testing/selftests/arm64/tags_test.c     | 19 +++++++++++++++++++
 10 files changed, 67 insertions(+), 7 deletions(-)
 create mode 100644 tools/testing/selftests/arm64/.gitignore
 create mode 100644 tools/testing/selftests/arm64/Makefile
 create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
 create mode 100644 tools/testing/selftests/arm64/tags_test.c

-- 
2.18.0.rc1.244.gcf134e6275-goog

^ permalink raw reply	[flat|nested] 153+ messages in thread

end of thread, other threads:[~2023-05-17 18:39 UTC | newest]

Thread overview: 153+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-17 18:39 [PATCH v4 0/7] arm64: untag user pointers passed to the kernel Parlett23
  -- strict thread matches above, loose matches on Subject: below --
2018-06-20 15:24 Andrey Konovalov
2018-06-20 15:24 ` Andrey Konovalov
2018-06-20 15:24 ` Andrey Konovalov
2018-06-20 15:24 ` Andrey Konovalov
2018-06-20 15:24 ` Andrey Konovalov
2018-06-20 15:24 ` andreyknvl
2018-06-20 15:24 ` Andrey Konovalov
2018-06-26 12:47 ` Andrey Konovalov
2018-06-26 12:47   ` Andrey Konovalov
2018-06-26 12:47   ` Andrey Konovalov
2018-06-26 12:47   ` andreyknvl
2018-06-26 12:47   ` Andrey Konovalov
2018-06-26 17:29   ` Catalin Marinas
2018-06-26 17:29     ` Catalin Marinas
2018-06-26 17:29     ` Catalin Marinas
2018-06-26 17:29     ` Catalin Marinas
2018-06-26 17:29     ` catalin.marinas
2018-06-26 17:29     ` Catalin Marinas
2018-06-27 15:05     ` Andrey Konovalov
2018-06-27 15:05       ` Andrey Konovalov
2018-06-27 15:05       ` Andrey Konovalov
2018-06-27 15:05       ` Andrey Konovalov
2018-06-27 15:05       ` andreyknvl
2018-06-27 15:05       ` Andrey Konovalov
2018-06-27 15:08       ` Ramana Radhakrishnan
2018-06-27 15:08         ` Ramana Radhakrishnan
2018-06-27 15:08         ` Ramana Radhakrishnan
2018-06-27 15:08         ` Ramana Radhakrishnan
2018-06-27 15:08         ` Ramana Radhakrishnan
2018-06-27 15:08         ` ramana.radhakrishnan
2018-06-27 15:08         ` Ramana Radhakrishnan
2018-06-27 17:17         ` Catalin Marinas
2018-06-27 17:17           ` Catalin Marinas
2018-06-27 17:17           ` Catalin Marinas
2018-06-27 17:17           ` Catalin Marinas
2018-06-27 17:17           ` Catalin Marinas
2018-06-27 17:17           ` catalin.marinas
2018-06-27 17:17           ` Catalin Marinas
2018-06-28  6:17           ` Luc Van Oostenryck
2018-06-28  6:17             ` Luc Van Oostenryck
2018-06-28  6:17             ` Luc Van Oostenryck
2018-06-28  6:17             ` Luc Van Oostenryck
2018-06-28  6:17             ` Luc Van Oostenryck
2018-06-28  6:17             ` luc.vanoostenryck
2018-06-28  6:17             ` Luc Van Oostenryck
2018-06-28 10:27             ` Catalin Marinas
2018-06-28 10:27               ` Catalin Marinas
2018-06-28 10:27               ` Catalin Marinas
2018-06-28 10:27               ` Catalin Marinas
2018-06-28 10:27               ` Catalin Marinas
2018-06-28 10:27               ` catalin.marinas
2018-06-28 10:27               ` Catalin Marinas
2018-06-28 10:46               ` Luc Van Oostenryck
2018-06-28 10:46                 ` Luc Van Oostenryck
2018-06-28 10:46                 ` Luc Van Oostenryck
2018-06-28 10:46                 ` Luc Van Oostenryck
2018-06-28 10:46                 ` Luc Van Oostenryck
2018-06-28 10:46                 ` luc.vanoostenryck
2018-06-28 10:46                 ` Luc Van Oostenryck
2018-06-28 14:48                 ` Catalin Marinas
2018-06-28 14:48                   ` Catalin Marinas
2018-06-28 14:48                   ` Catalin Marinas
2018-06-28 14:48                   ` Catalin Marinas
2018-06-28 14:48                   ` Catalin Marinas
2018-06-28 14:48                   ` catalin.marinas
2018-06-28 14:48                   ` Catalin Marinas
2018-06-28 15:28                   ` Luc Van Oostenryck
2018-06-28 15:28                     ` Luc Van Oostenryck
2018-06-28 15:28                     ` Luc Van Oostenryck
2018-06-28 15:28                     ` Luc Van Oostenryck
2018-06-28 15:28                     ` Luc Van Oostenryck
2018-06-28 15:28                     ` luc.vanoostenryck
2018-06-28 15:28                     ` Luc Van Oostenryck
2018-06-29 15:27                   ` David Laight
2018-06-29 15:27                     ` David Laight
2018-06-29 15:27                     ` David Laight
2018-06-29 15:27                     ` David Laight
2018-06-29 15:27                     ` David Laight
2018-06-29 15:27                     ` David.Laight
2018-06-29 15:27                     ` David Laight
2018-06-28 19:30       ` Andrey Konovalov
2018-06-28 19:30         ` Andrey Konovalov
2018-06-28 19:30         ` Andrey Konovalov
2018-06-28 19:30         ` Andrey Konovalov
2018-06-28 19:30         ` andreyknvl
2018-06-28 19:30         ` Andrey Konovalov
2018-06-29 15:19         ` Andrey Konovalov
2018-06-29 15:19           ` Andrey Konovalov
2018-06-29 15:19           ` Andrey Konovalov
2018-06-29 15:19           ` Andrey Konovalov
2018-06-29 15:19           ` andreyknvl
2018-06-29 15:19           ` Andrey Konovalov
2018-06-29 15:20           ` Andrey Konovalov
2018-06-29 15:20             ` Andrey Konovalov
2018-06-29 15:20             ` Andrey Konovalov
2018-06-29 15:20             ` Andrey Konovalov
2018-06-29 15:20             ` andreyknvl
2018-06-29 15:20             ` Andrey Konovalov
2018-07-16 11:25         ` Andrey Konovalov
2018-07-16 11:25           ` Andrey Konovalov
2018-07-16 11:25           ` Andrey Konovalov
2018-07-16 11:25           ` Andrey Konovalov
2018-07-16 11:25           ` andreyknvl
2018-07-16 11:25           ` Andrey Konovalov
2018-07-31 13:23           ` Andrey Konovalov
2018-07-31 13:23             ` Andrey Konovalov
2018-07-31 13:23             ` Andrey Konovalov
2018-07-31 13:23             ` Andrey Konovalov
2018-07-31 13:23             ` andreyknvl
2018-07-31 13:23             ` Andrey Konovalov
2018-08-01 17:42           ` Catalin Marinas
2018-08-01 17:42             ` Catalin Marinas
2018-08-01 17:42             ` Catalin Marinas
2018-08-01 17:42             ` Catalin Marinas
2018-08-01 17:42             ` catalin.marinas
2018-08-01 17:42             ` Catalin Marinas
2018-08-02 15:00             ` Andrey Konovalov
2018-08-02 15:00               ` Andrey Konovalov
2018-08-02 15:00               ` Andrey Konovalov
2018-08-02 15:00               ` Andrey Konovalov
2018-08-02 15:00               ` andreyknvl
2018-08-02 15:00               ` Andrey Konovalov
2018-08-03 14:59               ` Andrey Konovalov
2018-08-03 14:59                 ` Andrey Konovalov
2018-08-03 14:59                 ` Andrey Konovalov
2018-08-03 14:59                 ` Andrey Konovalov
2018-08-03 14:59                 ` andreyknvl
2018-08-03 14:59                 ` Andrey Konovalov
2018-08-03 15:09                 ` Greg Kroah-Hartman
2018-08-03 15:09                   ` Greg Kroah-Hartman
2018-08-03 15:09                   ` Greg Kroah-Hartman
2018-08-03 15:09                   ` Greg Kroah-Hartman
2018-08-03 15:09                   ` gregkh
2018-08-03 15:09                   ` Greg Kroah-Hartman
2018-08-03 16:43                   ` Matthew Wilcox
2018-08-03 16:43                     ` Matthew Wilcox
2018-08-03 16:43                     ` Matthew Wilcox
2018-08-03 16:43                     ` Matthew Wilcox
2018-08-03 16:43                     ` willy
2018-08-03 16:43                     ` Matthew Wilcox
2018-08-03 16:54                     ` Andrey Konovalov
2018-08-03 16:54                       ` Andrey Konovalov
2018-08-03 16:54                       ` Andrey Konovalov
2018-08-03 16:54                       ` Andrey Konovalov
2018-08-03 16:54                       ` andreyknvl
2018-08-03 16:54                       ` Andrey Konovalov
2018-08-06 19:12                   ` Luc Van Oostenryck
2018-08-06 19:12                     ` Luc Van Oostenryck
2018-08-06 19:12                     ` Luc Van Oostenryck
2018-08-06 19:12                     ` Luc Van Oostenryck
2018-08-06 19:12                     ` luc.vanoostenryck
2018-08-06 19:12                     ` Luc Van Oostenryck

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.