From: Pavel Machek <pavel@ucw.cz>
To: Jiri Kosina <jikos@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"Woodhouse, David" <dwmw@amazon.co.uk>,
Andi Kleen <ak@linux.intel.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
"Schaufler, Casey" <casey.schaufler@intel.com>,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid cross-process data leak
Date: Sun, 21 Oct 2018 21:38:27 +0200 [thread overview]
Message-ID: <20181021193827.GB26042@amd> (raw)
In-Reply-To: <nycvar.YFH.7.76.1809101123020.15880@cbobk.fhfr.pm>
[-- Attachment #1: Type: text/plain, Size: 991 bytes --]
Hi!
> 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).
Testing if attacker can ptrace victim is very good approximation, and
certainly better than "dumpable" check, but it is still not correct.
Imagine JIT running evil code (flash, javascript). JIT will prevent
evil code from doing ptrace() (or maybe there is syscall filter in
effect or something like that), but if evil code can poison branch
buffers and do timings, security problem stays.
Do we need prctl(I_DONT_RUN_EVIL_CODE)?
Or maybe we should just do barrier unconditionally for now?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2018-10-21 19:38 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-10 9:22 [PATCH v5 0/2] Harden spectrev2 userspace-userspace protection Jiri Kosina
2018-09-10 9:23 ` [PATCH v5 1/2] x86/speculation: apply IBPB more strictly to avoid cross-process data leak Jiri Kosina
2018-09-10 18:26 ` Schaufler, Casey
2018-09-10 19:14 ` Jiri Kosina
2018-09-10 19:26 ` Schaufler, Casey
2018-09-10 19:36 ` Jiri Kosina
2018-09-10 20:27 ` Schaufler, Casey
2018-09-10 20:42 ` Jiri Kosina
2018-09-10 21:29 ` Schaufler, Casey
2018-09-10 21:36 ` Jiri Kosina
2018-09-11 21:15 ` Thomas Gleixner
2018-09-11 22:25 ` Schaufler, Casey
2018-09-12 12:01 ` Thomas Gleixner
2018-10-21 19:38 ` Pavel Machek [this message]
2018-10-21 23:32 ` Jiri Kosina
2018-09-10 9:24 ` [PATCH v5 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation Jiri Kosina
2018-09-10 10:04 ` Thomas Gleixner
2018-09-10 11:01 ` Jiri Kosina
2018-09-10 11:46 ` Jiri Kosina
2018-09-11 17:32 ` Tim Chen
2018-09-11 21:16 ` Thomas Gleixner
2018-09-11 21:46 ` Thomas Gleixner
2018-09-12 17:16 ` Tom Lendacky
2018-09-12 21:26 ` Tim Chen
2018-09-12 21:45 ` Jiri Kosina
2018-09-12 22:56 ` Tim Chen
2018-09-13 14:53 ` Tom Lendacky
2018-09-12 9:05 ` [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection Jiri Kosina
2018-09-12 9:06 ` [PATCH v6 1/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak Jiri Kosina
2018-09-13 0:04 ` Schaufler, Casey
2018-09-14 11:00 ` Jiri Kosina
2018-09-14 11:05 ` Thomas Gleixner
2018-09-12 9:07 ` [PATCH v6 2/3] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation Jiri Kosina
2018-09-12 19:14 ` Thomas Gleixner
2018-09-12 19:16 ` Jiri Kosina
2018-09-12 9:08 ` [PATCH v6 3/3] x86/speculation: Propagate information about RSB filling mitigation to sysfs Jiri Kosina
2018-09-17 16:09 ` [PATCH v6 0/3] Harden spectrev2 userspace-userspace protection Schaufler, Casey
2018-09-19 15:48 ` Peter Zijlstra
2018-09-22 7:38 ` Jiri Kosina
2018-09-22 9:53 ` Thomas Gleixner
2018-09-22 10:18 ` Peter Zijlstra
2018-09-22 10:20 ` Thomas Gleixner
2018-09-22 13:30 ` Thomas Gleixner
2018-09-22 14:31 ` Peter Zijlstra
2018-09-24 8:43 ` Jiri Kosina
2018-09-24 12:38 ` Thomas Gleixner
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=20181021193827.GB26042@amd \
--to=pavel@ucw.cz \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=casey.schaufler@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--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