From: Dominik Brodowski <linux@dominikbrodowski.net>
To: David Woodhouse <dwmw@amazon.co.uk>
Cc: arjan@linux.intel.com, tglx@linutronix.de, karahmed@amazon.de,
x86@kernel.org, linux-kernel@vger.kernel.org,
tim.c.chen@linux.intel.com, bp@alien8.de, peterz@infradead.org,
pbonzini@redhat.com, ak@linux.intel.com,
torvalds@linux-foundation.org, gregkh@linux-foundation.org,
mingo@kernel.org, luto@kernel.org, jcm@redhat.com
Subject: Re: [PATCH] x86/speculation: Use Indirect Branch Prediction Barrier in context switch
Date: Mon, 29 Jan 2018 13:28:03 +0100 [thread overview]
Message-ID: <20180129122803.GA23664@isilmar-4.linta.de> (raw)
In-Reply-To: <1517225608-9153-1-git-send-email-dwmw@amazon.co.uk>
On Mon, Jan 29, 2018 at 11:33:28AM +0000, David Woodhouse wrote:
> From: Tim Chen <tim.c.chen@linux.intel.com>
>
> Flush indirect branches when switching into a process that marked itself
> non dumpable. This protects high value processes like gpg better,
> without having too high performance overhead.
>
> If done naïvely, we could switch to a kernel idle thread and then back
> to the original process, such as:
>
> process A -> idle -> process A
>
> In such scenario, we do not have to do IBPB here even though the process
> is non-dumpable, as we are switching back to the same process after a
> hiatus.
>
> To avoid the redundant IBPB, which is expensive, we track the last mm
> user context ID. The cost is to have an extra u64 mm context id to track
> the last mm we were using before switching to the init_mm used by idle.
> Avoiding the extra IBPB is probably worth the extra memory for this
> common scenario.
>
> For those cases where tlb_defer_switch_to_init_mm() returns true (non
> PCID), lazy tlb will defer switch to init_mm, so we will not be changing
> the mm for the process A -> idle -> process A switch. So IBPB will be
> skipped for this case.
>
> Thanks to the reviewers and Andy Lutomirski for the suggestion of
> using ctx_id which got rid of the problem of mm pointer recycling.
>
> Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> How close are we to done with bikeshedding this one?...
The commit message is much more about the A->idle-> improvement than
on the basic design decisions to limit this to non-dumpable processes. And
that still seems to be under discussion (see, for example, Jon Masters
message of today, https://lkml.org/lkml/2018/1/29/34 ). So this design
choice should, at least, be more explicit (if not tunable...).
> @@ -219,6 +220,25 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
> } else {
> u16 new_asid;
> bool need_flush;
> + u64 last_ctx_id = this_cpu_read(cpu_tlbstate.last_ctx_id);
> +
> + /*
> + * Avoid user/user BTB poisoning by flushing the branch
> + * predictor when switching between processes. This stops
> + * one process from doing Spectre-v2 attacks on another.
> + *
> + * As an optimization, flush indirect branches only when
> + * switching into processes that disable dumping.
> + *
> + * This will not flush branches when switching into kernel
> + * threads. It will also not flush if we switch to idle
Whitespace damage. And maybe add ", as the kernel depends on retpoline
protection instead" after "threads" here -- I think that was the reason why
you think kernel threads are safe; or did I misunderstand you?
> + * thread and back to the same process. It will flush if we
> + * switch to a different non-dumpable process.
"process, as that gives additional protection to high value processes like
gpg. Other processes are left unprotected here to reduce the overhead of the
barrier [... maybe add some rationale here ...]"
Thanks,
Dominik
next prev parent reply other threads:[~2018-01-29 12:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-29 11:33 David Woodhouse
2018-01-29 12:28 ` Dominik Brodowski [this message]
2018-01-29 12:44 ` David Woodhouse
2018-01-29 13:56 ` Dominik Brodowski
2018-01-29 22:04 David Woodhouse
2018-01-30 17:48 ` Josh Poimboeuf
2018-01-30 21:23 ` Tim Chen
2018-01-30 22:00 ` Borislav Petkov
2018-01-30 22:21 ` Thomas Gleixner
2018-01-30 22:55 ` Borislav Petkov
2018-01-31 3:59 ` Josh Poimboeuf
2018-01-31 23:25 ` Tim Chen
2018-01-30 20:38 ` Borislav Petkov
2018-01-30 21:03 ` Tim Chen
2018-01-30 21:57 ` Borislav Petkov
2018-01-30 22:26 ` Tim Chen
2018-01-30 22:43 ` Borislav Petkov
2018-01-31 0:25 ` Tim Chen
2018-01-31 0:41 ` Borislav Petkov
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=20180129122803.GA23664@isilmar-4.linta.de \
--to=linux@dominikbrodowski.net \
--cc=ak@linux.intel.com \
--cc=arjan@linux.intel.com \
--cc=bp@alien8.de \
--cc=dwmw@amazon.co.uk \
--cc=gregkh@linux-foundation.org \
--cc=jcm@redhat.com \
--cc=karahmed@amazon.de \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®