linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Balbir Singh <sblbir@amazon.com>
To: <linux-kernel@vger.kernel.org>, <tglx@linutronix.de>
Cc: <tony.luck@intel.com>, <keescook@chromium.org>, <x86@kernel.org>,
	<benh@kernel.crashing.org>, <dave.hansen@intel.com>,
	Balbir Singh <sblbir@amazon.com>
Subject: [RFC PATCH v2 0/4] arch/x86: Optionally flush L1D on context switch
Date: Wed, 25 Mar 2020 18:10:57 +1100	[thread overview]
Message-ID: <20200325071101.29556-1-sblbir@amazon.com> (raw)

This patch is a continuation of RFC/PoC to start the discussion on optionally
flushing L1D cache.  The goal is to allow tasks that are paranoid due to the
recent snoop assisted data sampling vulnerabilites, to flush their L1D on being
switched out.  This protects their data from being snooped or leaked via
side channels after the task has context switched out.

The points of discussion/review are (with updates):

1. Discuss the use case and the right approach to address this
A. Generally there seems to be consensus that we need this

2. Does an arch prctl allowing for opt-in flushing make sense, would other
   arches care about something similar?
A. We definitely build this for x86, have not heard from any other arch
   maintainers. There was suggestion to make this a prctl and let each
   arch implement L1D flushing if needed, there is no arch agnostic
   software L1D flush.

3. There is a fallback software L1D load, similar to what L1TF does, but
   we don't prefetch the TLB, is that sufficient?
A. There was no conclusion, I suspect we don't need this

4. Should we consider cleaning up the L1D on arrival of tasks?
A. For now, we think this case is not the priority for this patchset.

In summary, this is an early PoC to start the discussion on the need for
conditional L1D flushing based on the security posture of the
application and the sensitivity of the data it has access to or might
have access to.

Changelog v2:
 - Reuse existing code for allocation and flush
 - Simplify the goto logic in the actual l1d_flush function
 - Optimize the code path with jump labels/static functions

Cc: keescook@chromium.org

Balbir Singh (4):
  arch/x86/kvm: Refactor l1d flush lifecycle management
  arch/x86: Refactor tlbflush and l1d flush
  arch/x86: Optionally flush L1D on context switch
  arch/x86: L1D flush, optimize the context switch

 arch/x86/include/asm/cacheflush.h    |  6 ++
 arch/x86/include/asm/nospec-branch.h |  2 +
 arch/x86/include/asm/thread_info.h   |  4 ++
 arch/x86/include/asm/tlbflush.h      |  6 ++
 arch/x86/include/uapi/asm/prctl.h    |  3 +
 arch/x86/kernel/Makefile             |  1 +
 arch/x86/kernel/l1d_flush.c          | 85 ++++++++++++++++++++++++++++
 arch/x86/kernel/process_64.c         | 10 +++-
 arch/x86/kvm/vmx/vmx.c               | 56 +++---------------
 arch/x86/mm/tlb.c                    | 85 ++++++++++++++++++++++++++++
 10 files changed, 209 insertions(+), 49 deletions(-)
 create mode 100644 arch/x86/kernel/l1d_flush.c

-- 
2.17.1


             reply	other threads:[~2020-03-25  7:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25  7:10 Balbir Singh [this message]
2020-03-25  7:10 ` [RFC PATCH v2 1/4] arch/x86/kvm: Refactor l1d flush lifecycle management Balbir Singh
2020-03-25  7:10 ` [RFC PATCH v2 2/4] arch/x86: Refactor tlbflush and l1d flush Balbir Singh
2020-03-25  7:11 ` [RFC PATCH v2 3/4] arch/x86: Optionally flush L1D on context switch Balbir Singh
2020-03-31 18:34   ` Thomas Gleixner
2020-03-31 23:56     ` Singh, Balbir
2020-03-25  7:11 ` [RFC PATCH v2 4/4] arch/x86: L1D flush, optimize the " Balbir Singh
2020-03-25  7:15   ` Singh, Balbir
2020-03-30  1:13 ` [RFC PATCH v2 0/4] arch/x86: Optionally flush L1D on " Singh, Balbir

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=20200325071101.29556-1-sblbir@amazon.com \
    --to=sblbir@amazon.com \
    --cc=benh@kernel.crashing.org \
    --cc=dave.hansen@intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@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;
as well as URLs for NNTP newsgroup(s).