All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com,
	linux-mips@vger.kernel.org, x86@kernel.org,
	Will Deacon <will.deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>,
	Russell King <linux@armlinux.org.uk>,
	Paul Burton <paul.burton@mips.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, Stephen Boyd <sboyd@kernel.org>,
	Mark Salyzyn <salyzyn@android.com>,
	Kees Cook <keescook@chromium.org>,
	Peter Collingbourne <pcc@google.com>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Andrei Vagin <avagin@openvz.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Marc Zyngier <maz@kernel.org>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH v4 18/26] arm64: vdso32: Replace TASK_SIZE_32 check in vgettimeofday
Date: Tue, 17 Mar 2020 17:48:06 +0000	[thread overview]
Message-ID: <20200317174806.GE632169@arrakis.emea.arm.com> (raw)
In-Reply-To: <83aaf9e1-0a8f-4908-577a-23766541b2ba@arm.com>

On Tue, Mar 17, 2020 at 04:40:48PM +0000, Vincenzo Frascino wrote:
> On 3/17/20 3:50 PM, Catalin Marinas wrote:
> > On Tue, Mar 17, 2020 at 03:04:01PM +0000, Vincenzo Frascino wrote:
> >> On 3/17/20 2:38 PM, Catalin Marinas wrote:
> >>> On Tue, Mar 17, 2020 at 12:22:12PM +0000, Vincenzo Frascino wrote:
> >>
> >> Can TASK_SIZE > UINTPTR_MAX on an arm64 system?
> > 
> > TASK_SIZE yes on arm64 but not TASK_SIZE_32. I was asking about the
> > arm32 check where TASK_SIZE < UINTPTR_MAX. How does the vdsotest return
> > -EFAULT on arm32? Which code path causes this in the user vdso code?
> 
> Sorry I got confused because you referred to arch/arm/vdso/vgettimeofday.c which
> is the arm64 implementation, not the compat one :)

You figured out (in your subsequent reply) that I was indeed talking
about arm32 ;).

> In the case of arm32 everything is handled via syscall fallback.

So clock_gettime() on arm32 always falls back to the syscall?

> > My guess is that on arm32 it only fails with -EFAULT in the syscall
> > fallback path since a copy_to_user() would fail the access_ok() check.
> > Does it always take the fallback path if ts > TASK_SIZE?
> 
> Correct, it goes via fallback. The return codes for these syscalls are specified
> by the ABI [1]. Then I agree with you the way on which arm32 achieves it should
> be via access_ok() check.

"it should be" or "it is" on arm32?

If, on arm32, clock_gettime() is (would be?) handled in the vdso
entirely, who checks for the pointer outside the accessible address
space (as per the clock_gettime man page)?

I'm fine with such check as long as it is consistent across arm32 and
arm64 compat. Or even on arm64 native between syscall fallback and vdso
execution. I haven't figured out yet whether this is the case.

> >>> This last check needs an explanation. If the clock_id is invalid but res
> >>> is not NULL, we allow it. I don't see where the compatibility issue is,
> >>> arm32 doesn't have such check.
> >>
> >> The case that you are describing has to return -EPERM per ABI spec. This case
> >> has to return -EINVAL.
> >>
> >> The first case is taken care from the generic code. But if we don't do this
> >> check before on arm64 compat we end up returning the wrong error code.
> > 
> > I guess I have the same question as above. Where does the arm32 code
> > return -EINVAL for that case? Did it work correctly before you removed
> > the TASK_SIZE_32 check?
> 
> I repeated the test and seems that it was failing even before I removed
> TASK_SIZE_32. For reasons I can't explain I did not catch it before.
> 
> The getres syscall should return -EINVAL in the cases specified in [1].

It states 'clk_id specified is not supported on this system'. Fair
enough but it doesn't say that it returns -EINVAL only if res == NULL.
You also don't explain why __cvdso_clock_getres_time32() doesn't already
detect an invalid clk_id on arm64 compat (but does it on arm32).

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com,
	linux-mips@vger.kernel.org, x86@kernel.org,
	Will Deacon <will.deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>,
	Russell King <linux@armlinux.org.uk>,
	Paul Burton <paul.burton@mips.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andy Lutomirski <luto@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>, Stephen Boyd <sboyd@kernel.org>,
	Mark Salyzyn <salyzyn@android.com>,
	Kees Cook <keescook@chromium.org>,
	Peter Collingbourne <pcc@google.com>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Andrei Vagin <avagin@openvz.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Marc Zyngier <maz@kernel.org>Mark
Subject: Re: [PATCH v4 18/26] arm64: vdso32: Replace TASK_SIZE_32 check in vgettimeofday
Date: Tue, 17 Mar 2020 17:48:06 +0000	[thread overview]
Message-ID: <20200317174806.GE632169@arrakis.emea.arm.com> (raw)
In-Reply-To: <83aaf9e1-0a8f-4908-577a-23766541b2ba@arm.com>

On Tue, Mar 17, 2020 at 04:40:48PM +0000, Vincenzo Frascino wrote:
> On 3/17/20 3:50 PM, Catalin Marinas wrote:
> > On Tue, Mar 17, 2020 at 03:04:01PM +0000, Vincenzo Frascino wrote:
> >> On 3/17/20 2:38 PM, Catalin Marinas wrote:
> >>> On Tue, Mar 17, 2020 at 12:22:12PM +0000, Vincenzo Frascino wrote:
> >>
> >> Can TASK_SIZE > UINTPTR_MAX on an arm64 system?
> > 
> > TASK_SIZE yes on arm64 but not TASK_SIZE_32. I was asking about the
> > arm32 check where TASK_SIZE < UINTPTR_MAX. How does the vdsotest return
> > -EFAULT on arm32? Which code path causes this in the user vdso code?
> 
> Sorry I got confused because you referred to arch/arm/vdso/vgettimeofday.c which
> is the arm64 implementation, not the compat one :)

You figured out (in your subsequent reply) that I was indeed talking
about arm32 ;).

> In the case of arm32 everything is handled via syscall fallback.

So clock_gettime() on arm32 always falls back to the syscall?

> > My guess is that on arm32 it only fails with -EFAULT in the syscall
> > fallback path since a copy_to_user() would fail the access_ok() check.
> > Does it always take the fallback path if ts > TASK_SIZE?
> 
> Correct, it goes via fallback. The return codes for these syscalls are specified
> by the ABI [1]. Then I agree with you the way on which arm32 achieves it should
> be via access_ok() check.

"it should be" or "it is" on arm32?

If, on arm32, clock_gettime() is (would be?) handled in the vdso
entirely, who checks for the pointer outside the accessible address
space (as per the clock_gettime man page)?

I'm fine with such check as long as it is consistent across arm32 and
arm64 compat. Or even on arm64 native between syscall fallback and vdso
execution. I haven't figured out yet whether this is the case.

> >>> This last check needs an explanation. If the clock_id is invalid but res
> >>> is not NULL, we allow it. I don't see where the compatibility issue is,
> >>> arm32 doesn't have such check.
> >>
> >> The case that you are describing has to return -EPERM per ABI spec. This case
> >> has to return -EINVAL.
> >>
> >> The first case is taken care from the generic code. But if we don't do this
> >> check before on arm64 compat we end up returning the wrong error code.
> > 
> > I guess I have the same question as above. Where does the arm32 code
> > return -EINVAL for that case? Did it work correctly before you removed
> > the TASK_SIZE_32 check?
> 
> I repeated the test and seems that it was failing even before I removed
> TASK_SIZE_32. For reasons I can't explain I did not catch it before.
> 
> The getres syscall should return -EINVAL in the cases specified in [1].

It states 'clk_id specified is not supported on this system'. Fair
enough but it doesn't say that it returns -EINVAL only if res == NULL.
You also don't explain why __cvdso_clock_getres_time32() doesn't already
detect an invalid clk_id on arm64 compat (but does it on arm32).

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Mark Rutland <Mark.Rutland@arm.com>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	linux-mips@vger.kernel.org, Will Deacon <will@kernel.org>,
	linux-arch@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
	x86@kernel.org, Russell King <linux@armlinux.org.uk>,
	clang-built-linux@googlegroups.com,
	Ingo Molnar <mingo@redhat.com>, Kees Cook <keescook@chromium.org>,
	Arnd Bergmann <arnd@arndb.de>, Will Deacon <will.deacon@arm.com>,
	Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Collingbourne <pcc@google.com>,
	linux-arm-kernel@lists.infradead.org,
	Andrei Vagin <avagin@openvz.org>, Stephen Boyd <sboyd@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-kernel@vger.kernel.org, Mark Salyzyn <salyzyn@android.com>,
	Paul Burton <paul.burton@mips.com>
Subject: Re: [PATCH v4 18/26] arm64: vdso32: Replace TASK_SIZE_32 check in vgettimeofday
Date: Tue, 17 Mar 2020 17:48:06 +0000	[thread overview]
Message-ID: <20200317174806.GE632169@arrakis.emea.arm.com> (raw)
In-Reply-To: <83aaf9e1-0a8f-4908-577a-23766541b2ba@arm.com>

On Tue, Mar 17, 2020 at 04:40:48PM +0000, Vincenzo Frascino wrote:
> On 3/17/20 3:50 PM, Catalin Marinas wrote:
> > On Tue, Mar 17, 2020 at 03:04:01PM +0000, Vincenzo Frascino wrote:
> >> On 3/17/20 2:38 PM, Catalin Marinas wrote:
> >>> On Tue, Mar 17, 2020 at 12:22:12PM +0000, Vincenzo Frascino wrote:
> >>
> >> Can TASK_SIZE > UINTPTR_MAX on an arm64 system?
> > 
> > TASK_SIZE yes on arm64 but not TASK_SIZE_32. I was asking about the
> > arm32 check where TASK_SIZE < UINTPTR_MAX. How does the vdsotest return
> > -EFAULT on arm32? Which code path causes this in the user vdso code?
> 
> Sorry I got confused because you referred to arch/arm/vdso/vgettimeofday.c which
> is the arm64 implementation, not the compat one :)

You figured out (in your subsequent reply) that I was indeed talking
about arm32 ;).

> In the case of arm32 everything is handled via syscall fallback.

So clock_gettime() on arm32 always falls back to the syscall?

> > My guess is that on arm32 it only fails with -EFAULT in the syscall
> > fallback path since a copy_to_user() would fail the access_ok() check.
> > Does it always take the fallback path if ts > TASK_SIZE?
> 
> Correct, it goes via fallback. The return codes for these syscalls are specified
> by the ABI [1]. Then I agree with you the way on which arm32 achieves it should
> be via access_ok() check.

"it should be" or "it is" on arm32?

If, on arm32, clock_gettime() is (would be?) handled in the vdso
entirely, who checks for the pointer outside the accessible address
space (as per the clock_gettime man page)?

I'm fine with such check as long as it is consistent across arm32 and
arm64 compat. Or even on arm64 native between syscall fallback and vdso
execution. I haven't figured out yet whether this is the case.

> >>> This last check needs an explanation. If the clock_id is invalid but res
> >>> is not NULL, we allow it. I don't see where the compatibility issue is,
> >>> arm32 doesn't have such check.
> >>
> >> The case that you are describing has to return -EPERM per ABI spec. This case
> >> has to return -EINVAL.
> >>
> >> The first case is taken care from the generic code. But if we don't do this
> >> check before on arm64 compat we end up returning the wrong error code.
> > 
> > I guess I have the same question as above. Where does the arm32 code
> > return -EINVAL for that case? Did it work correctly before you removed
> > the TASK_SIZE_32 check?
> 
> I repeated the test and seems that it was failing even before I removed
> TASK_SIZE_32. For reasons I can't explain I did not catch it before.
> 
> The getres syscall should return -EINVAL in the cases specified in [1].

It states 'clk_id specified is not supported on this system'. Fair
enough but it doesn't say that it returns -EINVAL only if res == NULL.
You also don't explain why __cvdso_clock_getres_time32() doesn't already
detect an invalid clk_id on arm64 compat (but does it on arm32).

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-03-17 17:48 UTC|newest]

Thread overview: 108+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-17 12:21 [PATCH v4 00/26] Introduce common headers for vDSO Vincenzo Frascino
2020-03-17 12:21 ` Vincenzo Frascino
2020-03-17 12:21 ` [PATCH v4 01/26] linux/const.h: Extract common header " Vincenzo Frascino
2020-03-17 12:21   ` Vincenzo Frascino
2020-03-17 12:21 ` [PATCH v4 02/26] linux/bits.h: " Vincenzo Frascino
2020-03-17 12:21   ` Vincenzo Frascino
2020-03-17 12:21 ` [PATCH v4 03/26] linux/limits.h: " Vincenzo Frascino
2020-03-17 12:21   ` Vincenzo Frascino
2020-03-17 12:21 ` [PATCH v4 04/26] x86:Introduce asm/vdso/clocksource.h Vincenzo Frascino
2020-03-17 12:21   ` Vincenzo Frascino
2020-03-17 12:21 ` [PATCH v4 05/26] arm: Introduce asm/vdso/clocksource.h Vincenzo Frascino
2020-03-17 12:21   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 06/26] arm64: " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 07/26] mips: " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 08/26] linux/clocksource.h: Extract common header for vDSO Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 09/26] linux/math64.h: " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 10/26] linux/time.h: " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 11/26] linux/time32.h: " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 12/26] linux/time64.h: " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 13/26] linux/jiffies.h: " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 14/26] linux/ktime.h: " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 15/26] common: Introduce processor.h Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 16/26] scripts: Fix the inclusion order in modpost Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 17/26] linux/elfnote.h: Replace elf.h with UAPI equivalent Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 18/26] arm64: vdso32: Replace TASK_SIZE_32 check in vgettimeofday Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 14:38   ` Catalin Marinas
2020-03-17 14:38     ` Catalin Marinas
2020-03-17 14:38     ` Catalin Marinas
2020-03-17 15:04     ` Vincenzo Frascino
2020-03-17 15:04       ` Vincenzo Frascino
2020-03-17 15:04       ` Vincenzo Frascino
2020-03-17 15:50       ` Catalin Marinas
2020-03-17 15:50         ` Catalin Marinas
2020-03-17 15:50         ` Catalin Marinas
2020-03-17 16:40         ` Vincenzo Frascino
2020-03-17 16:40           ` Vincenzo Frascino
2020-03-17 16:40           ` Vincenzo Frascino
2020-03-17 16:43           ` Vincenzo Frascino
2020-03-17 16:43             ` Vincenzo Frascino
2020-03-17 16:43             ` Vincenzo Frascino
2020-03-17 17:48           ` Catalin Marinas [this message]
2020-03-17 17:48             ` Catalin Marinas
2020-03-17 17:48             ` Catalin Marinas
2020-03-18 16:14             ` Vincenzo Frascino
2020-03-18 16:14               ` Vincenzo Frascino
2020-03-18 16:14               ` Vincenzo Frascino
2020-03-18 18:36               ` Catalin Marinas
2020-03-18 18:36                 ` Catalin Marinas
2020-03-18 18:36                 ` Catalin Marinas
2020-03-19 12:38                 ` Vincenzo Frascino
2020-03-19 12:38                   ` Vincenzo Frascino
2020-03-19 12:38                   ` Vincenzo Frascino
2020-03-19 18:10                   ` Catalin Marinas
2020-03-19 18:10                     ` Catalin Marinas
2020-03-19 18:10                     ` Catalin Marinas
2020-03-20 13:05                     ` Vincenzo Frascino
2020-03-20 13:05                       ` Vincenzo Frascino
2020-03-20 13:05                       ` Vincenzo Frascino
2020-03-20 14:22                       ` Catalin Marinas
2020-03-20 14:22                         ` Catalin Marinas
2020-03-20 14:22                         ` Catalin Marinas
2020-03-20 14:41                         ` Vincenzo Frascino
2020-03-20 14:41                           ` Vincenzo Frascino
2020-03-20 14:41                           ` Vincenzo Frascino
2020-03-19 15:49     ` Andy Lutomirski
2020-03-19 15:49       ` Andy Lutomirski
2020-03-19 15:49       ` Andy Lutomirski
2020-03-19 16:58       ` Vincenzo Frascino
2020-03-19 16:58         ` Vincenzo Frascino
2020-03-19 16:58         ` Vincenzo Frascino
2020-03-19 18:32         ` Will Deacon
2020-03-19 18:32           ` Will Deacon
2020-03-19 18:32           ` Will Deacon
2020-03-21 14:33   ` [tip: timers/core] arm64: vdso32: Code clean up tip-bot2 for Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 19/26] arm64: Introduce asm/vdso/processor.h Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 17:52   ` Catalin Marinas
2020-03-17 17:52     ` Catalin Marinas
2020-03-17 17:52     ` Catalin Marinas
2020-03-17 12:22 ` [PATCH v4 20/26] arm64: vdso: Include common headers in the vdso library Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 21/26] arm64: vdso32: " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 22/26] mips: vdso: Enable mips to use common headers Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 23/26] x86: vdso: Enable x86 " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 24/26] arm: vdso: Enable arm " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 25/26] lib: vdso: Enable " Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22 ` [PATCH v4 26/26] arm64: vdso32: Enable Clang Compilation Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino
2020-03-17 12:22   ` Vincenzo Frascino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200317174806.GE632169@arrakis.emea.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=0x7f454c46@gmail.com \
    --cc=Mark.Rutland@arm.com \
    --cc=arnd@arndb.de \
    --cc=avagin@openvz.org \
    --cc=bp@alien8.de \
    --cc=clang-built-linux@googlegroups.com \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=luto@kernel.org \
    --cc=maz@kernel.org \
    --cc=mingo@redhat.com \
    --cc=ndesaulniers@google.com \
    --cc=paul.burton@mips.com \
    --cc=pcc@google.com \
    --cc=salyzyn@android.com \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vincenzo.frascino@arm.com \
    --cc=will.deacon@arm.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is 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.