From: Ingo Molnar <mingo@kernel.org>
To: Brian Gerst <brgerst@gmail.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Denys Vlasenko <dvlasenk@redhat.com>,
Andy Lutomirski <luto@amacapital.net>,
Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] x86: execve and sigreturn syscalls must return via iret
Date: Mon, 23 Mar 2015 08:56:37 +0100 [thread overview]
Message-ID: <20150323075637.GA25620@gmail.com> (raw)
In-Reply-To: <1426978461-32089-1-git-send-email-brgerst@gmail.com>
* Brian Gerst <brgerst@gmail.com> wrote:
> Both the execve and sigreturn family of syscalls have the ability to change
> registers in ways that may not be compatabile with the syscall path they
> were called from. In particular, sysret and sysexit can't handle non-default
> %cs and %ss, and some bits in eflags. These syscalls have stubs that are
> hardcoded to jump to the iret path, and not return to the original syscall
> path. Commit 76f5df43cab5e765c0bd42289103e8f625813ae1 (Always allocate a
> complete "struct pt_regs" on the kernel stack) recently changed this for
> some 32-bit compat syscalls, but introduced a bug where execve from a 32-bit
> program to a 64-bit program would fail because it still returned via sysretl.
> This caused Wine to fail when built for both 32-bit and 64-bit.
>
> This patch sets TIF_NOTIFY_RESUME for execve and sigreturn so that the iret
> path is always taken on exit to userspace.
>
> Signed-off-by: Brian Gerst <brgerst@gmail.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Denys Vlasenko <dvlasenk@redhat.com>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> ---
> arch/x86/ia32/ia32_signal.c | 2 ++
> arch/x86/include/asm/ptrace.h | 2 +-
> arch/x86/include/asm/thread_info.h | 7 +++++++
> arch/x86/kernel/process_32.c | 6 +-----
> arch/x86/kernel/process_64.c | 1 +
> arch/x86/kernel/signal.c | 2 ++
> 6 files changed, 14 insertions(+), 6 deletions(-)
Applied the fix to tip:x86/asm, thanks Brian!
> +
> +/*
> + * force syscall return via iret by making it look as if there was
> + * some work pending.
> +*/
> +#define force_iret() set_thread_flag(TIF_NOTIFY_RESUME)
I extended this comment to:
/*
* Force syscall return via IRET by making it look as if there was
* some work pending. IRET is our most capable (but slowest) syscall
* return path, which is able to restore modified SS, CS and certain
* EFLAGS values that other (fast) syscall return instructions
* are not able to restore properly.
*/
#define force_iret() set_thread_flag(TIF_NOTIFY_RESUME)
Just to preserve the underlying reason for force_iret() for the future
and such.
Btw., it might be a worthwile optimization to detect non-standard SS,
CS and EFLAGS values and only force_iret() in that case, that will
speed up 99.9999% of execve() and sigreturn() syscalls and only force
the 'weird' process startup modes into the slow return path.
>From an access security POV it should be a relatively safe
optimization: if we get it wrong then we don't allow certain ABI
angles, but we won't make the kernel unsafe AFAICS.
Thanks,
Ingo
next prev parent reply other threads:[~2015-03-23 7:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-21 22:54 [PATCH] x86: execve and sigreturn syscalls must return via iret Brian Gerst
2015-03-23 7:56 ` Ingo Molnar [this message]
2015-03-23 15:24 ` Brian Gerst
2015-03-23 18:42 ` Andy Lutomirski
2015-03-23 12:19 ` [tip:x86/asm] x86/asm/entry: Fix execve() and sigreturn() syscalls to always return via IRET tip-bot for Brian Gerst
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=20150323075637.GA25620@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=torvalds@linux-foundation.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.