All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: "Singh, Balbir" <sblbir@amazon.com>, tglx@linutronix.de
Cc: "mingo@redhat.com" <mingo@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
	"jpoimboe@redhat.com" <jpoimboe@redhat.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"dave.hansen@intel.com" <dave.hansen@intel.com>,
	"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
	"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH v4 0/5] Next revision of the L1D flush patches
Date: Thu, 8 Apr 2021 13:23:06 -0700	[thread overview]
Message-ID: <202104081319.DAB1D817@keescook> (raw)
In-Reply-To: <cf89f0389379daaaff0cbce9c5f1550866e55e91.camel@amazon.com>

*thread necromancy*
https://lore.kernel.org/lkml/20210108121056.21940-1-sblbir@amazon.com/

On Mon, Jan 25, 2021 at 09:27:38AM +0000, Singh, Balbir wrote:
> On Fri, 2021-01-08 at 23:10 +1100, Balbir Singh wrote:
> > Implement a mechanism that allows tasks to conditionally flush
> > their L1D cache (mitigation mechanism suggested in [2]). The previous
> > posts of these patches were sent for inclusion (see [3]) and were not
> > included due to the concern for the need for additional checks,
> > those checks were:
> > 
> > 1. Implement this mechanism only for CPUs affected by the L1TF bug
> > 2. Disable the software fallback
> > 3. Provide an override to enable this mechanism
> > 4. Be SMT aware in the implementation
> > [...]
> Ping on any review comments? Suggested refactoring?

Hi!

I'd still really like to see this -- it's a big hammer, but that's the
point for cases where some new flaw appears and we can point to the
toolbox and say "you can mitigate it with this while you wait for new
kernel/CPU."

Any further thoughts from x86 maintainers? This seems like it addressed
all of tglx's review comments.

-- 
Kees Cook

  reply	other threads:[~2021-04-08 20:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08 12:10 [PATCH v4 0/5] Next revision of the L1D flush patches Balbir Singh
2021-01-08 12:10 ` [PATCH v4 1/5] x86/smp: Add a per-cpu view of SMT state Balbir Singh
2021-07-28  9:58   ` [tip: x86/cpu] " tip-bot2 for Balbir Singh
2021-01-08 12:10 ` [PATCH v4 2/5] x86/mm: Refactor cond_ibpb() to support other use cases Balbir Singh
2021-07-28  9:58   ` [tip: x86/cpu] " tip-bot2 for Balbir Singh
2021-01-08 12:10 ` [PATCH v4 3/5] x86/mm: Optionally flush L1D on context switch Balbir Singh
2021-01-08 17:31   ` kernel test robot
2021-01-08 12:10 ` [PATCH v4 4/5] prctl: Hook L1D flushing in via prctl Balbir Singh
2021-07-28  9:58   ` [tip: x86/cpu] x86, " tip-bot2 for Balbir Singh
2021-01-08 12:10 ` [PATCH v4 5/5] Documentation: Add L1D flushing Documentation Balbir Singh
2021-07-28  9:58   ` [tip: x86/cpu] " tip-bot2 for Balbir Singh
2021-01-25  9:27 ` [PATCH v4 0/5] Next revision of the L1D flush patches Singh, Balbir
2021-04-08 20:23   ` Kees Cook [this message]
     [not found]     ` <87y2d5tpjh.ffs@nanos.tec.linutronix.de>
2021-04-26 22:24       ` Thomas Gleixner
2021-04-28 20:08         ` Kees Cook
2021-06-04 10:06           ` Balbir Singh
2021-06-04 19:09             ` Kees Cook
2021-05-13  1:06         ` Balbir Singh
2021-07-28  9:58 ` [tip: x86/cpu] x86/mm: Prepare for opt-in based L1D flush in switch_mm() tip-bot2 for Balbir Singh
2021-07-28  9:58 ` [tip: x86/cpu] x86/process: Make room for TIF_SPEC_L1D_FLUSH tip-bot2 for Balbir Singh
2021-07-28  9:58 ` [tip: x86/cpu] sched: Add task_work callback for paranoid L1D flush tip-bot2 for Balbir Singh

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=202104081319.DAB1D817@keescook \
    --to=keescook@chromium.org \
    --cc=benh@kernel.crashing.org \
    --cc=dave.hansen@intel.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sblbir@amazon.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.