linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Jiri Kosina <jikos@kernel.org>,
	"Schaufler, Casey" <casey.schaufler@intel.com>
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>,
	Oleg Nesterov <oleg@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks
Date: Tue, 4 Sep 2018 16:26:54 -0700	[thread overview]
Message-ID: <3f24e8c8-eab8-66c2-9a8d-957e30cac809@linux.intel.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.1809042046180.15880@cbobk.fhfr.pm>

On 09/04/2018 11:48 AM, Jiri Kosina wrote:
> On Tue, 4 Sep 2018, Schaufler, Casey wrote:
> 
>>> So if this should be done in LSM, it'd probably have to be written by
>>> someone else than me :) who actually understands how the "sidechannel LSM"
>>> idea works.
>>
>> Yes. That would be me. 
> 
> Ok, cool. Then 1/2 and 2/3 can be ignored / replaced by Casey's LSM stuff. 
> 
> Some form of 3/3 still should be merged independently on that.


I think STIBP should be an opt in option as it will have significant
impact on performance.  The attack from neighbor thread is pretty
difficult to pull off considering you have to know what the sibling
thread is running and its address allocation.

We could also use a security module to opt in the STIBP policy.

Tim 

> 
> Thanks,
> 


  reply	other threads:[~2018-09-04 23:26 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31 20:56 [PATCH] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation Jiri Kosina
2018-09-03  8:51 ` Jiri Kosina
2018-09-03 12:45 ` [PATCH v2 0/3] Harden spectrev2 userspace-userspace protection Jiri Kosina
2018-09-04 14:23 ` [PATCH v3 " Jiri Kosina
2018-09-04 14:40   ` [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks Jiri Kosina
2018-09-04 16:13     ` Thomas Gleixner
2018-09-04 16:21       ` Thomas Gleixner
2018-09-04 17:26     ` Tim Chen
2018-09-04 17:35       ` Jiri Kosina
2018-09-04 18:10         ` Schaufler, Casey
2018-09-04 18:48           ` Jiri Kosina
2018-09-04 23:26             ` Tim Chen [this message]
2018-09-05  6:22               ` Jiri Kosina
2018-09-05 15:58                 ` Andi Kleen
2018-09-05 18:04                   ` Andrea Arcangeli
2018-09-05 18:29                     ` Jiri Kosina
2018-09-05 18:40                       ` Andrea Arcangeli
2018-09-05 18:42                         ` Jiri Kosina
2018-09-05 19:03                         ` Peter Zijlstra
2018-09-05 19:27                           ` Schaufler, Casey
2018-09-05 20:02                         ` Jiri Kosina
2018-09-05 18:26                   ` Thomas Gleixner
2018-09-05 18:35                   ` Jiri Kosina
2018-09-04 23:37           ` Andrea Arcangeli
2018-09-05  1:00             ` Schaufler, Casey
2018-09-05  2:38               ` Andrea Arcangeli
2018-09-05  8:00         ` Peter Zijlstra
2018-09-05 15:37           ` Schaufler, Casey
2018-09-05  7:51     ` Peter Zijlstra
2018-09-04 14:42   ` [PATCH v3 2/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak Jiri Kosina
2018-09-04 16:18     ` Thomas Gleixner
2018-09-05  7:59       ` Peter Zijlstra
2018-09-05  8:02         ` Jiri Kosina
2018-09-05  9:40           ` Peter Zijlstra
2018-09-05  7:52     ` Peter Zijlstra
2018-09-05  7:55       ` Jiri Kosina
2018-09-04 14:42   ` [PATCH v3 3/3] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation Jiri Kosina
2018-09-04 14:24 [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks Jiri Kosina

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=3f24e8c8-eab8-66c2-9a8d-957e30cac809@linux.intel.com \
    --to=tim.c.chen@linux.intel.com \
    --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=oleg@redhat.com \
    --cc=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).