Re: [PATCH 3.16 045/305] x86/speculation: Apply IBPB more strictly to avoid cross-process data leak

2019-02-04 Thread Ben Hutchings
On Sun, 2019-02-03 at 13:37 -0800, Andi Kleen wrote:
> On Sun, Feb 03, 2019 at 08:05:53PM +0100, Jiri Kosina wrote:
> > On Sun, 3 Feb 2019, Ben Hutchings wrote:
> > 
> > > 3.16.63-rc1 review patch.  If anyone has any objections, please let me 
> > > know.
> > > 
> > > --
> > > 
> > > From: Jiri Kosina 
> > > 
> > > commit dbfe2953f63c640463c630746cd5d9de8b2f63ae upstream.
> > 
> > You really want the whole IBPB+STIBP revamp from upstream, otherwise 
> > you're going to get noticeable performance penalties on some workloads 
> > with some microcodes.
> 
> Yes, we would need the opt-in/opt-out support too.
> 
> Please don't merge it just as is.

Thanks, I've now dropped this.

Ben.

-- 
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.




signature.asc
Description: This is a digitally signed message part


Re: [PATCH 3.16 045/305] x86/speculation: Apply IBPB more strictly to avoid cross-process data leak

2019-02-03 Thread Andi Kleen
On Sun, Feb 03, 2019 at 08:05:53PM +0100, Jiri Kosina wrote:
> On Sun, 3 Feb 2019, Ben Hutchings wrote:
> 
> > 3.16.63-rc1 review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Jiri Kosina 
> > 
> > commit dbfe2953f63c640463c630746cd5d9de8b2f63ae upstream.
> 
> You really want the whole IBPB+STIBP revamp from upstream, otherwise 
> you're going to get noticeable performance penalties on some workloads 
> with some microcodes.

Yes, we would need the opt-in/opt-out support too.

Please don't merge it just as is.

-Andi


Re: [PATCH 3.16 045/305] x86/speculation: Apply IBPB more strictly to avoid cross-process data leak

2019-02-03 Thread Jiri Kosina
On Sun, 3 Feb 2019, Ben Hutchings wrote:

> 3.16.63-rc1 review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Jiri Kosina 
> 
> commit dbfe2953f63c640463c630746cd5d9de8b2f63ae upstream.

You really want the whole IBPB+STIBP revamp from upstream, otherwise 
you're going to get noticeable performance penalties on some workloads 
with some microcodes.

-- 
Jiri Kosina
SUSE Labs



[PATCH 3.16 045/305] x86/speculation: Apply IBPB more strictly to avoid cross-process data leak

2019-02-03 Thread Ben Hutchings
3.16.63-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jiri Kosina 

commit dbfe2953f63c640463c630746cd5d9de8b2f63ae upstream.

Currently, IBPB is only issued in cases when switching into a non-dumpable
process, the rationale being to protect such 'important and security
sensitive' processess (such as GPG) from data leaking into a different
userspace process via spectre v2.

This is however completely insufficient to provide proper userspace-to-userpace
spectrev2 protection, as any process can poison branch buffers before being
scheduled out, and the newly scheduled process immediately becomes spectrev2
victim.

In order to minimize the performance impact (for usecases that do require
spectrev2 protection), issue the barrier only in cases when switching between
processess where the victim can't be ptraced by the potential attacker (as in
such cases, the attacker doesn't have to bother with branch buffers at all).

[ tglx: Split up PTRACE_MODE_NOACCESS_CHK into PTRACE_MODE_SCHED and
  PTRACE_MODE_IBPB to be able to do ptrace() context tracking reasonably
  fine-grained ]

Fixes: 18bf3c3ea8 ("x86/speculation: Use Indirect Branch Prediction Barrier in 
context switch")
Originally-by: Tim Chen 
Signed-off-by: Jiri Kosina 
Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Josh Poimboeuf 
Cc: Andrea Arcangeli 
Cc:  "WoodhouseDavid" 
Cc: Andi Kleen 
Cc:  "SchauflerCasey" 
Link: 
https://lkml.kernel.org/r/nycvar.yfh.7.76.1809251437340.15...@cbobk.fhfr.pm
[bwh: Backported to 3.16: We don't have mm_context_t::ctx_id so can't use
 it to compare task identity.]
Signed-off-by: Ben Hutchings 
---
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -95,6 +96,19 @@ void switch_mm(struct mm_struct *prev, s
local_irq_restore(flags);
 }
 
+static bool ibpb_needed(struct task_struct *tsk)
+{
+   /*
+* Check if the current (previous) task has access to the memory
+* of the @tsk (next) task. If access is denied, make sure to
+* issue a IBPB to stop user->user Spectre-v2 attacks.
+*
+* Note: __ptrace_may_access() returns 0 or -ERRNO.
+*/
+   return (tsk && tsk->mm &&
+   ptrace_may_access_sched(tsk, PTRACE_MODE_SPEC_IBPB));
+}
+
 void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
struct task_struct *tsk)
 {
@@ -107,16 +121,13 @@ void switch_mm_irqs_off(struct mm_struct
 * one process from doing Spectre-v2 attacks on another.
 *
 * As an optimization, flush indirect branches only when
-* switching into processes that disable dumping. This
-* protects high value processes like gpg, without having
-* too high performance overhead. IBPB is *expensive*!
-*
-* This will not flush branches when switching into kernel
-* threads. It will flush if we switch to a different non-
-* dumpable process.
+* switching into a processes that can't be ptrace by the
+* current one (as in such case, attacker has much more
+* convenient way how to tamper with the next process than
+* branch buffer poisoning).
 */
-   if (tsk && tsk->mm &&
-   get_dumpable(tsk->mm) != SUID_DUMP_USER)
+   if (static_cpu_has(X86_FEATURE_USE_IBPB) &&
+   ibpb_needed(tsk))
indirect_branch_prediction_barrier();
 
this_cpu_write(cpu_tlbstate.state, TLBSTATE_OK);
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -59,14 +59,17 @@ extern void exit_ptrace(struct task_stru
 #define PTRACE_MODE_READ   0x01
 #define PTRACE_MODE_ATTACH 0x02
 #define PTRACE_MODE_NOAUDIT0x04
-#define PTRACE_MODE_FSCREDS 0x08
-#define PTRACE_MODE_REALCREDS 0x10
+#define PTRACE_MODE_FSCREDS0x08
+#define PTRACE_MODE_REALCREDS  0x10
+#define PTRACE_MODE_SCHED  0x20
+#define PTRACE_MODE_IBPB   0x40
 
 /* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
 #define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
 #define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
 #define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
 #define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH | 
PTRACE_MODE_REALCREDS)
+#define PTRACE_MODE_SPEC_IBPB (PTRACE_MODE_ATTACH_REALCREDS | PTRACE_MODE_IBPB)
 
 /**
  * ptrace_may_access - check whether the caller is permitted to access
@@ -84,6 +87,20 @@ extern void exit_ptrace(struct task_stru
  */
 extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
 
+/**
+ * ptrace_may_access - check whether the caller is permitted to access
+ * a target task.
+ *