From: "Schaufler, Casey" <casey.schaufler@intel.com>
To: Jann Horn <jannh@google.com>
Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>,
kernel list <linux-kernel@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
"selinux@tycho.nsa.gov" <selinux@tycho.nsa.gov>,
"Hansen, Dave" <dave.hansen@intel.com>,
"Dock, Deneen T" <deneen.t.dock@intel.com>,
"kristen@linux.intel.com" <kristen@linux.intel.com>,
Arjan van de Ven <arjan@linux.intel.com>
Subject: RE: [PATCH RFC v2 2/5] X86: Support LSM determination of side-channel vulnerability
Date: Mon, 20 Aug 2018 14:45:10 +0000 [thread overview]
Message-ID: <99FC4B6EFCEFD44486C35F4C281DC6732143F769@ORSMSX107.amr.corp.intel.com> (raw)
In-Reply-To: <CAG48ez23G+wcnkCMNZV_mxYMS=h+pZkpx1451Wz5GB9_tcDv3Q@mail.gmail.com>
> -----Original Message-----
> From: Jann Horn [mailto:jannh@google.com]
> Sent: Friday, August 17, 2018 4:55 PM
> To: Schaufler, Casey <casey.schaufler@intel.com>
> Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>; kernel list
> <linux-kernel@vger.kernel.org>; linux-security-module <linux-security-
> module@vger.kernel.org>; selinux@tycho.nsa.gov; Hansen, Dave
> <dave.hansen@intel.com>; Dock, Deneen T <deneen.t.dock@intel.com>;
> kristen@linux.intel.com; Arjan van de Ven <arjan@linux.intel.com>
> Subject: Re: [PATCH RFC v2 2/5] X86: Support LSM determination of side-
> channel vulnerability
>
> On Sat, Aug 18, 2018 at 12:17 AM Casey Schaufler
> <casey.schaufler@intel.com> wrote:
> >
> > From: Casey Schaufler <cschaufler@localhost.localdomain>
> >
> > When switching between tasks it may be necessary
> > to set an indirect branch prediction barrier if the
> > tasks are potentially vulnerable to side-channel
> > attacks. This adds a call to security_task_safe_sidechannel
> > so that security modules can weigh in on the decision.
> >
> > Signed-off-by: Casey Schaufler <casey.schaufler@intel.com>
> > ---
> > arch/x86/mm/tlb.c | 12 ++++++++----
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> > index 6eb1f34c3c85..8714d4af06aa 100644
> > --- a/arch/x86/mm/tlb.c
> > +++ b/arch/x86/mm/tlb.c
> > @@ -7,6 +7,7 @@
> > #include <linux/export.h>
> > #include <linux/cpu.h>
> > #include <linux/debugfs.h>
> > +#include <linux/security.h>
> >
> > #include <asm/tlbflush.h>
> > #include <asm/mmu_context.h>
> > @@ -270,11 +271,14 @@ void switch_mm_irqs_off(struct mm_struct *prev,
> struct mm_struct *next,
> > * threads. It will also not flush if we switch to idle
> > * thread and back to the same process. It will flush if we
> > * switch to a different non-dumpable process.
> > + * If a security module thinks that the transition
> > + * is unsafe do the flush.
> > */
> > - if (tsk && tsk->mm &&
> > - tsk->mm->context.ctx_id != last_ctx_id &&
> > - get_dumpable(tsk->mm) != SUID_DUMP_USER)
> > - indirect_branch_prediction_barrier();
> > + if (tsk && tsk->mm && tsk->mm->context.ctx_id != last_ctx_id) {
> > + if (get_dumpable(tsk->mm) != SUID_DUMP_USER ||
> > + security_task_safe_sidechannel(tsk) != 0)
> > + indirect_branch_prediction_barrier();
> > + }
>
> When you posted v1 of this series, I asked:
>
> | Does this enforce transitivity? What happens if we first switch from
> | an attacker task to a task without ->mm, and immediately afterwards
> | from the task without ->mm to a victim task? In that case, whether a
> | flush happens between the attacker task and the victim task depends on
> | whether the LSM thinks that the mm-less task should have access to the
> | victim task, right?
>
> Have you addressed that? I don't see it...
Nope. That's going to require maintaining state about all the
tasks in the chain that might still have cache involvement.
A -> B -> C -> D
If B and C don't do anything cacheworthy D could conceivably attack A.
The amount of state required to detect this case would be prohibitive.
I think that if you're sufficiently concerned about this case you should just
go ahead and set the barrier. I'm willing to learn something that says I'm
wrong.
next prev parent reply other threads:[~2018-08-20 14:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-17 22:16 [PATCH RFC v2 0/5] LSM: Add and use a hook for side-channel safety checks Casey Schaufler
2018-08-17 22:16 ` [PATCH RFC v2 1/5] LSM: Introduce a hook for side-channel danger Casey Schaufler
2018-08-17 22:16 ` [PATCH RFC v2 2/5] X86: Support LSM determination of side-channel vulnerability Casey Schaufler
2018-08-17 23:55 ` Jann Horn
2018-08-20 14:45 ` Schaufler, Casey [this message]
2018-08-21 10:20 ` Jann Horn
2018-08-21 16:37 ` Schaufler, Casey
2018-08-21 17:45 ` Jann Horn
2018-08-17 22:16 ` [PATCH RFC v2 3/5] LSM: Security module checking for side-channel dangers Casey Schaufler
2018-08-17 23:52 ` Jann Horn
2018-08-20 15:31 ` Schaufler, Casey
2018-08-17 22:16 ` [PATCH RFC v2 4/5] Smack: Support determination of side-channel vulnerability Casey Schaufler
2018-08-17 22:16 ` [PATCH RFC v2 5/5] SELinux: Support SELinux " Casey Schaufler
2018-08-20 16:02 ` Stephen Smalley
2018-08-20 16:59 ` Schaufler, Casey
2018-08-20 17:43 ` Stephen Smalley
2018-08-20 19:30 ` Schaufler, Casey
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=99FC4B6EFCEFD44486C35F4C281DC6732143F769@ORSMSX107.amr.corp.intel.com \
--to=casey.schaufler@intel.com \
--cc=arjan@linux.intel.com \
--cc=dave.hansen@intel.com \
--cc=deneen.t.dock@intel.com \
--cc=jannh@google.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=kristen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=selinux@tycho.nsa.gov \
/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).