All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Andi Kleen <ak@linux.intel.com>, X86 ML <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 1/3] x86/entry: Clear extra registers beyond syscall arguments for 64bit kernels
Date: Sat, 3 Feb 2018 17:25:23 -0800	[thread overview]
Message-ID: <CAPcyv4jczornu9b1kjWEK6MZXNG81NFfwvy_4PL+CsUkLHo+uQ@mail.gmail.com> (raw)
In-Reply-To: <CALCETrUtU7j3wHfvrSmiA0wkE4=gXXgFsTG3VXh3x3E8WHxvMg@mail.gmail.com>

On Sat, Feb 3, 2018 at 4:14 PM, Andy Lutomirski <luto@kernel.org> wrote:
> On Sat, Feb 3, 2018 at 11:21 PM, Dan Williams <dan.j.williams@intel.com> wrote:
>> At entry userspace may have populated the extra registers outside the
>> syscall calling convention with values that could be useful in a
>> speculative execution attack. Clear them to minimize the kernel's attack
>> surface. Note, this only clears the extra registers and not the unused
>> registers for syscalls less than 6 arguments since those registers are
>> likely to be clobbered well before their values could be put to use
>> under speculation.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> Cc: x86@kernel.org
>> Cc: Andy Lutomirski <luto@kernel.org>
>> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
>> Reported-by: Andi Kleen <ak@linux.intel.com>
>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> ---
>>  arch/x86/entry/calling.h  |   17 +++++++++++++++++
>>  arch/x86/entry/entry_64.S |    1 +
>>  2 files changed, 18 insertions(+)
>>
>> diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h
>> index 3f48f695d5e6..daee2d19e73d 100644
>> --- a/arch/x86/entry/calling.h
>> +++ b/arch/x86/entry/calling.h
>> @@ -147,6 +147,23 @@ For 32-bit we have the following conventions - kernel is built with
>>         UNWIND_HINT_REGS offset=\offset
>>         .endm
>>
>> +       /*
>> +        * Sanitize extra registers of values that a speculation attack
>> +        * might want to exploit. In the CONFIG_FRAME_POINTER=y case,
>> +        * the expectation is that %ebp will be clobbered before it
>> +        * could be used.
>> +        */
>> +       .macro CLEAR_EXTRA_REGS_NOSPEC
>> +       xorq %r15, %r15
>> +       xorq %r14, %r14
>> +       xorq %r13, %r13
>> +       xorq %r12, %r12
>> +       xorl %ebx, %ebx
>> +#ifndef CONFIG_FRAME_POINTER
>> +       xorl %ebp, %ebp
>> +#endif
>> +       .endm
>> +
>
> Can we make the clears only happen if we have CONFIG_RETPOLINE?  Or is
> there maybe some reason why we want this even without retpolines on?

We have the other Spectre variant1 mitigations on by default. I'm not
opposed to adding a config to turn them all off, but I think we should
be consistent either way, and I don't think CONFIG_RETPOLINE is the
right config to gate those.

>>         .macro POP_EXTRA_REGS
>>         popq %r15
>>         popq %r14
>> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
>> index c752abe89d80..46260e951da6 100644
>> --- a/arch/x86/entry/entry_64.S
>> +++ b/arch/x86/entry/entry_64.S
>> @@ -247,6 +247,7 @@ GLOBAL(entry_SYSCALL_64_after_hwframe)
>>         TRACE_IRQS_OFF
>>
>>         /* IRQs are off. */
>> +       CLEAR_EXTRA_REGS_NOSPEC
>
> Please put the clears before TRACE_IRQS_OFF to protect users that use tracing.

Ok.

  reply	other threads:[~2018-02-04  1:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-03 23:21 [PATCH 0/3] x86/entry: clear registers to sanitize speculative usages Dan Williams
2018-02-03 23:21 ` [PATCH 1/3] x86/entry: Clear extra registers beyond syscall arguments for 64bit kernels Dan Williams
2018-02-04  0:14   ` Andy Lutomirski
2018-02-04  1:25     ` Dan Williams [this message]
2018-02-04  1:29       ` Andy Lutomirski
2018-02-04 13:01   ` Brian Gerst
2018-02-04 17:42     ` Dan Williams
2018-02-04 18:40       ` Linus Torvalds
2018-02-05 16:26         ` Ingo Molnar
2018-02-05 16:38           ` Andy Lutomirski
2018-02-05 18:29             ` Ingo Molnar
2018-02-05 18:47               ` Brian Gerst
2018-02-05 19:48                 ` Ingo Molnar
2018-02-05 20:25                   ` Andy Lutomirski
2018-02-05 20:05           ` Ingo Molnar
2018-02-06  8:48             ` Ingo Molnar
2018-02-03 23:21 ` [PATCH 2/3] x86/entry: Clear registers for 64bit exceptions/interrupts Dan Williams
2018-02-03 23:21 ` [PATCH 3/3] x86/entry: Clear registers for compat syscalls Dan Williams

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=CAPcyv4jczornu9b1kjWEK6MZXNG81NFfwvy_4PL+CsUkLHo+uQ@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=ak@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --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.