From: Kees Cook <keescook@chromium.org>
To: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Luis Machado <luis.machado@linaro.org>,
catalin.marinas@arm.com, Keno Fischer <keno@juliacomputing.com>,
kernel-team@android.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 6/7] arm64: ptrace: Use NO_SYSCALL instead of -1 in syscall_trace_enter()
Date: Sun, 12 Jul 2020 19:32:13 -0700 [thread overview]
Message-ID: <202007121931.A31FBE6@keescook> (raw)
In-Reply-To: <20200710161148.GC31036@willie-the-truck>
On Fri, Jul 10, 2020 at 05:11:48PM +0100, Will Deacon wrote:
> On Fri, Jul 10, 2020 at 09:04:08AM -0700, Kees Cook wrote:
> > On Fri, Jul 10, 2020 at 02:07:01PM +0100, Will Deacon wrote:
> > > Setting a system call number of -1 is special, as it indicates that the
> > > current system call should be skipped.
> > >
> > > Use NO_SYSCALL instead of -1 when checking for this scenario, which is
> > > different from the -1 returned due to a seccomp failure.
> >
> > I can't understand this paragraph. NO_SYSCALL is -1, so how is this
> > "different"?
> >
> > arch/arm64/include/asm/ptrace.h:#define NO_SYSCALL (-1)
> >
> > Do you just mean "stop using a literal '-1'"?
>
> Yes, I'm trying to distinguish '-1' when used as a system call number
> from '-1' when used as the return value of secure_computing() on failure.
> It's currently all mixed up, and I think it's confusing trying to realise
> what is a system call number and what is an error code.
Okay, I gotcha now. Yes, that's entirely reasonable. (It's perhaps an
artifact of x86's implementation that they get directly passed through.)
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-13 2:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-10 13:06 [PATCH v3 0/7] arm64: Fix single-step handling and syscall tracing Will Deacon
2020-07-10 13:06 ` [PATCH v3 1/7] arm64: ptrace: Consistently use pseudo-singlestep exceptions Will Deacon
2020-07-10 13:06 ` Will Deacon
2020-07-16 0:27 ` Sasha Levin
2020-07-16 0:27 ` Sasha Levin
2020-07-10 13:06 ` [PATCH v3 2/7] arm64: ptrace: Override SPSR.SS when single-stepping is enabled Will Deacon
2020-07-10 13:06 ` Will Deacon
2020-07-16 0:27 ` Sasha Levin
2020-07-16 0:27 ` Sasha Levin
2020-07-10 13:06 ` [PATCH v3 3/7] arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return Will Deacon
2020-07-10 13:06 ` Will Deacon
2020-07-16 0:27 ` Sasha Levin
2020-07-16 0:27 ` Sasha Levin
2020-07-10 13:06 ` [PATCH v3 4/7] arm64: ptrace: Add a comment describing our syscall entry/exit trap ABI Will Deacon
2020-07-10 13:07 ` [PATCH v3 5/7] arm64: syscall: Expand the comment about ptrace and syscall(-1) Will Deacon
2020-07-10 13:07 ` [PATCH v3 6/7] arm64: ptrace: Use NO_SYSCALL instead of -1 in syscall_trace_enter() Will Deacon
2020-07-10 16:04 ` Kees Cook
2020-07-10 16:11 ` Will Deacon
2020-07-13 2:32 ` Kees Cook [this message]
2020-07-10 13:07 ` [PATCH v3 7/7] arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEP Will Deacon
2020-07-14 11:57 ` [PATCH v3 0/7] arm64: Fix single-step handling and syscall tracing Luis Machado
2020-07-15 12:25 ` Luis Machado
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=202007121931.A31FBE6@keescook \
--to=keescook@chromium.org \
--cc=catalin.marinas@arm.com \
--cc=keno@juliacomputing.com \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=luis.machado@linaro.org \
--cc=mark.rutland@arm.com \
--cc=will@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.