From: keescook@chromium.org (Kees Cook)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM: Call syscall_trace_exit even when system call skipped
Date: Thu, 15 Mar 2018 13:14:31 -0700 [thread overview]
Message-ID: <CAGXu5jKVQu9BrL6S9XY_qpNqZOPmie7e=EEXcsJB9eX9wvs+kQ@mail.gmail.com> (raw)
In-Reply-To: <162293d1df0.2772.8578bc6afb023d3c4d0bd68fb35b28aa@members.leeds.ac.uk>
On Thu, Mar 15, 2018 at 3:38 AM, <T.E.Baldwin99@members.leeds.ac.uk> wrote:
> On 15 March 2018 00:45:01 Kees Cook <keescook@chromium.org> wrote:
>
>>>> --- a/arch/arm/kernel/entry-common.S
>>>> +++ b/arch/arm/kernel/entry-common.S
>>>> @@ -288,16 +288,15 @@ __sys_trace:
>>>> cmp scno, #-1 @ skip the syscall?
>>>> bne 2b
>>>> add sp, sp, #S_OFF @ restore stack
>>>> - b ret_slow_syscall
>>>>
>>>> -__sys_trace_return:
>>>> - str r0, [sp, #S_R0 + S_OFF]! @ save returned r0
>>>> +__sys_trace_return_nosave:
>>>> + enable_irq_notrace
>>
>>
>> Why is __sys_trace_return_nosave the correct destination here? The
>> original handle set up for lr a few lines above is for
>> __sys_trace_return. It's not clear to me why this change is made?
>
>
> __sys_trace_return stores the current r0 value on the stack which will
> reloaded on exit to user mode. However if skipping a system call r0 is -1
> and storing it would destroy the users r0 value, unlike the case where the
> system call is made and r0 is the return value.
>
> The enabling of interrupts is redundant for this purpose, the reuse of code
> is a size optimization.
Ah right. Cool, thanks!
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Kees Cook <keescook@chromium.org>
I assume Dmitry can add a Tested-by too?
This seems good to go into the ARM patch tracker...
-Kees
--
Kees Cook
Pixel Security
next prev parent reply other threads:[~2018-03-15 20:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-03 15:21 [PATCH] ARM: Call syscall_trace_exit even when system call skipped Timothy E Baldwin
2018-03-13 23:58 ` Dmitry V. Levin
2018-03-15 0:44 ` Kees Cook
2018-03-15 10:38 ` T.E.Baldwin99 at members.leeds.ac.uk
2018-03-15 20:14 ` Kees Cook [this message]
2018-09-29 23:03 ` Eugene Syromyatnikov
2018-10-08 7:11 ` Eugene Syromyatnikov
2018-10-08 9:58 ` Vladimir Murzin
2018-10-08 11:00 ` Eugene Syromyatnikov
2018-10-08 18:08 ` Kees Cook
2018-10-08 18:13 ` Russell King - ARM Linux
2018-10-08 18:33 ` Eugene Syromyatnikov
2018-10-08 18:26 ` Eugene Syromyatnikov
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='CAGXu5jKVQu9BrL6S9XY_qpNqZOPmie7e=EEXcsJB9eX9wvs+kQ@mail.gmail.com' \
--to=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).