From: Chuck Ebbert <cebbert.lkml@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Thomas Gleixner <tglx@linutronix.de>, X86 ML <x86@kernel.org>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Sebastian Lackner <sebastian@fds-team.de>,
Anish Bhatt <anish@chelsio.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
stable@kernel.org
Subject: Re: [PATCH 1/2] x86_64,entry: Filter RFLAGS.NT on entry from userspace
Date: Tue, 30 Sep 2014 19:27:40 -0500 [thread overview]
Message-ID: <20140930192741.73144817@as> (raw)
In-Reply-To: <c4b7904ef2ddd3dec27400d18bcd00badb4dcedf.1412105369.git.luto@amacapital.net>
On Tue, 30 Sep 2014 12:40:35 -0700
Andy Lutomirski <luto@amacapital.net> wrote:
> The NT flag doesn't do anything in long mode other than causing IRET
> to #GP. Oddly, CPL3 code can still net NT using popf.
>
> Entry via hardware or software interrupt clears NT automatically, so
> the only relevant entries are fast syscalls.
>
> This patch programs the CPU to clear NT on entry via SYSCALL (both
> 32-bit and 64-bit, by my reading of the AMD APM). It also clears NT
> (and some other flags) in software on SYSENTER.
>
> I haven't touched anything on 32-bit kernels.
>
> If user code causes kernel code to run with NT set, then there's at
> least some (small) chance that it could cause trouble. For example,
> user code could cause a call to EFI code with NT set, and who knows
> what would happen. Apparently Wine sometimes does this (!), and, if
> an IRET return happens, Wine will segfault.
>
> I think that Wine should be fixed to stop setting NT when a syscall
> happens, but handling NT more gracefully is still nice.
>
> The syscall mask change comes from a variant of this patch by Anish
> Bhatt.
>
> Cc: stable@kernel.org
> Reported-by: Anish Bhatt <anish@chelsio.com>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
> arch/x86/ia32/ia32entry.S | 10 +++++++++-
> arch/x86/kernel/cpu/common.c | 2 +-
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
> index 4299eb05023c..079f42a7ad58 100644
> --- a/arch/x86/ia32/ia32entry.S
> +++ b/arch/x86/ia32/ia32entry.S
> @@ -143,7 +143,15 @@ ENTRY(ia32_sysenter_target)
> pushq_cfi %r10
> CFI_REL_OFFSET rip,0
> pushq_cfi %rax
> - cld
> +
> + /*
> + * Sysenter doesn't filter flags, so we should filter them
> + * ourselves.
> + */
> + pushfq_cfi
> + andl $~(X86_EFLAGS_TF|X86_EFLAGS_DF|X86_EFLAGS_NT|X86_EFLAGS_IOPL),(%rsp)
> + popfq_cfi
Can't you just push a constant and pop that onto flags instead? It's
not like we care what's in there on entry to the kernel.
> +
> SAVE_ARGS 0,1,0
> /* no need to do an access_ok check here because rbp has been
> 32bit zero extended */
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index e4ab2b42bd6f..31265580c38a 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1184,7 +1184,7 @@ void syscall_init(void)
> /* Flags to clear on syscall */
> wrmsrl(MSR_SYSCALL_MASK,
> X86_EFLAGS_TF|X86_EFLAGS_DF|X86_EFLAGS_IF|
> - X86_EFLAGS_IOPL|X86_EFLAGS_AC);
> + X86_EFLAGS_IOPL|X86_EFLAGS_AC|X86_EFLAGS_NT);
> }
>
> /*
next prev parent reply other threads:[~2014-10-01 0:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 19:40 [PATCH 0/2] x86_64,entry: Clear NT on entry and speed up switch_to Andy Lutomirski
2014-09-30 19:40 ` [PATCH 1/2] x86_64,entry: Filter RFLAGS.NT on entry from userspace Andy Lutomirski
2014-09-30 21:39 ` Sebastian Lackner
2014-09-30 21:45 ` Andy Lutomirski
2014-09-30 22:23 ` Sebastian Lackner
2014-09-30 22:27 ` Thomas Gleixner
2014-09-30 22:33 ` Andy Lutomirski
2014-09-30 23:21 ` Thomas Gleixner
2014-10-01 17:50 ` H. Peter Anvin
2014-10-01 17:53 ` H. Peter Anvin
2014-09-30 22:42 ` H. Peter Anvin
2014-10-01 0:27 ` Chuck Ebbert [this message]
2014-10-01 0:38 ` Andy Lutomirski
2014-09-30 19:40 ` [PATCH 2/2] x86_64: Don't save flags on context switch Andy Lutomirski
2014-09-30 22:21 ` [PATCH 0/2] x86_64,entry: Clear NT on entry and speed up switch_to Thomas Gleixner
2014-09-30 22:30 ` 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=20140930192741.73144817@as \
--to=cebbert.lkml@gmail.com \
--cc=anish@chelsio.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=sebastian@fds-team.de \
--cc=stable@kernel.org \
--cc=tglx@linutronix.de \
--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