From: Peter Zijlstra <peterz@infradead.org>
To: Jiri Kosina <jikos@kernel.org>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
"Woodhouse, David" <dwmw@amazon.co.uk>,
Oleg Nesterov <oleg@redhat.com>,
Casey Schaufler <casey.schaufler@intel.com>,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH v3 1/3] ptrace: Provide ___ptrace_may_access() that can be applied on arbitrary tasks
Date: Wed, 5 Sep 2018 10:00:24 +0200 [thread overview]
Message-ID: <20180905080024.GP24124@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <nycvar.YFH.7.76.1809041932590.15880@cbobk.fhfr.pm>
On Tue, Sep 04, 2018 at 07:35:29PM +0200, Jiri Kosina wrote:
> On Tue, 4 Sep 2018, Tim Chen wrote:
>
> > > Current ptrace_may_access() implementation assumes that the 'source' task is
> > > always the caller (current).
> > >
> > > Expose ___ptrace_may_access() that can be used to apply the check on arbitrary
> > > tasks.
> >
> > Casey recently has proposed putting the decision making of whether to
> > do IBPB in the security module.
> >
> > https://lwn.net/ml/kernel-hardening/20180815235355.14908-4-casey.schaufler@intel.com/
> >
> > That will have the advantage of giving the administrator a more flexibility
> > of when to turn on IBPB. The policy is very similar to what you have proposed here
> > but I think the security module is a more appropriate place for the security policy.
>
> Yeah, well, honestly, I have a bit hard time buying the "generic
> sidechannel prevention security module" idea, given how completely
> different in nature all the mitigations have been so far. I don't see that
> trying to abstract this somehow provides more clarity.
>
> 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.
Yeah, I'm not convinced on LSM either. Lets just do these here patches
first and then Casey can try and convince us later.
next prev parent reply other threads:[~2018-09-05 8:00 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
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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
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=20180905080024.GP24124@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aarcange@redhat.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=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