From: Denys Vlasenko <dvlasenk@redhat.com>
To: Brian Gerst <brgerst@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@amacapital.net>,
Oleg Nesterov <oleg@redhat.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Alexei Starovoitov <ast@plumgrid.com>,
Will Drewry <wad@chromium.org>, Kees Cook <keescook@chromium.org>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/9] x86/asm/entry/64: do not SAVE_EXTRA_REGS in stub_sigreturn
Date: Thu, 02 Apr 2015 17:20:03 +0200 [thread overview]
Message-ID: <551D5E23.2050002@redhat.com> (raw)
In-Reply-To: <CAMzpN2jEj7FHPSXm=WrxdPU+Eqa3ygq6c5t-=oMK9jTb=fQOyw@mail.gmail.com>
On 04/02/2015 05:01 PM, Brian Gerst wrote:
> On Thu, Apr 2, 2015 at 10:36 AM, Denys Vlasenko <dvlasenk@redhat.com> wrote:
>> stub_sigreturn ignores old values of pt_regs->REG for all general-purpose
>> registers, it sets them to values saved on userspace
>> signal stack.
>>
>> Which is hardly surprising - it would be a bug if it would use pt_regs->REG.
>> sigreturn must restore all registers.
>>
>> Therefore, SAVE_EXTRA_REGS in it ought to be redundant.
>>
>> It is a leftover from the time SAVE_EXTRA_REGS wasn't only saving registers,
>> but it also was extending stack to "full" pt_regs.
>>
>> Delete this SAVE_EXTRA_REGS.
>>
>> Run-tested.
>>
>> Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
>> CC: Linus Torvalds <torvalds@linux-foundation.org>
>> CC: Steven Rostedt <rostedt@goodmis.org>
>> CC: Ingo Molnar <mingo@kernel.org>
>> CC: Borislav Petkov <bp@alien8.de>
>> CC: "H. Peter Anvin" <hpa@zytor.com>
>> CC: Andy Lutomirski <luto@amacapital.net>
>> CC: Oleg Nesterov <oleg@redhat.com>
>> CC: Frederic Weisbecker <fweisbec@gmail.com>
>> CC: Alexei Starovoitov <ast@plumgrid.com>
>> CC: Will Drewry <wad@chromium.org>
>> CC: Kees Cook <keescook@chromium.org>
>> CC: x86@kernel.org
>> CC: linux-kernel@vger.kernel.org
>> ---
>> arch/x86/kernel/entry_64.S | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
>> index ec51598..1cf245d 100644
>> --- a/arch/x86/kernel/entry_64.S
>> +++ b/arch/x86/kernel/entry_64.S
>> @@ -447,7 +447,12 @@ ENTRY(stub_rt_sigreturn)
>> CFI_STARTPROC
>> addq $8, %rsp
>> DEFAULT_FRAME 0
>> - SAVE_EXTRA_REGS
>> + /*
>> + * Despite RESTORE_EXTRA_REGS in return_from_stub,
>> + * no need to SAVE_EXTRA_REGS here:
>> + * sys_rt_sigreturn overwrites all general purpose pt_regs->REGs
>> + * on stack, for RESTORE_{EXTRA,C}_REGS to pick them up.
>> + */
>> call sys_rt_sigreturn
>> jmp return_from_stub
>> CFI_ENDPROC
>> @@ -458,7 +463,7 @@ ENTRY(stub_x32_rt_sigreturn)
>> CFI_STARTPROC
>> addq $8, %rsp
>> DEFAULT_FRAME 0
>> - SAVE_EXTRA_REGS
>> + /* No need to SAVE_EXTRA_REGS */
>> call sys32_x32_rt_sigreturn
>> jmp return_from_stub
>> CFI_ENDPROC
>
> I had the same idea, but determined sigreturn can fault and return an
> error code without modifying all the registers. This would leak junk
> from the stack.
This still can be made to work by not RESTORE'ing EXTRA_REGS either,
if there is a way to detect the failure:
call sys_rt_sigreturn
- jmp return_from_stub
+ testl ???????????
+ jz return_from_stub
+ ret
CFI_ENDPROC
But this is not a normal syscall, off-hand I don't see an easy way
to do the test. sys_rt_sigreturn() on failure runs this code:
...
segfault:
force_sig(SIGSEGV, current);
return 0;
}
Help?
next prev parent reply other threads:[~2015-04-02 15:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-02 14:36 [PATCH 1/9] x86/asm/entry/64: reuse stub return code Denys Vlasenko
2015-04-02 14:36 ` [PATCH 2/9] x86/asm/entry/64: optimize [v]fork/clone stubs Denys Vlasenko
2015-04-02 14:36 ` [PATCH 3/9] x86/asm/entry/64: do not SAVE_EXTRA_REGS in stub_sigreturn Denys Vlasenko
2015-04-02 15:01 ` Brian Gerst
2015-04-02 15:20 ` Denys Vlasenko [this message]
2015-04-02 19:10 ` Brian Gerst
2015-04-02 19:40 ` Denys Vlasenko
2015-04-02 19:40 ` Andy Lutomirski
2015-04-02 14:36 ` [PATCH 4/9] x86/asm/entry/64: delay popping return address in stubs Denys Vlasenko
2015-04-02 14:36 ` [PATCH 5/9] x86/asm/entry/64: if execve fails, no need to use IRET return Denys Vlasenko
2015-04-02 14:36 ` [PATCH 6/9] x86/asm/entry/64: reuse stub epilogue by ret_from_fork Denys Vlasenko
2015-04-02 14:36 ` [PATCH 7/9] x86/asm/entry/64: remove a redundant jump Denys Vlasenko
2015-04-02 14:36 ` [PATCH 8/9] x86/asm/entry/64: simplify jumps in ret_from_fork Denys Vlasenko
2015-04-02 14:36 ` [PATCH 9/9] x86/asm/entry/64: Remove GET_THREAD_INFO " Denys Vlasenko
2015-04-02 19:02 ` Andy Lutomirski
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=551D5E23.2050002@redhat.com \
--to=dvlasenk@redhat.com \
--cc=ast@plumgrid.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=wad@chromium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox