All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Kees Cook <keescook@chromium.org>, bsingharora@gmail.com
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: Tue, 27 Apr 2021 00:24:16 +0200	[thread overview]
Message-ID: <87tunsofan.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <87y2d5tpjh.ffs@nanos.tec.linutronix.de>

On Mon, Apr 26 2021 at 10:31, Thomas Gleixner wrote:
> On Thu, Apr 08 2021 at 13:23, Kees Cook wrote:
>>
>> 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.
>
> Sorry for dropping the ball on this. It's in my list of things to deal
> with. Starting to look at it now.

So I went through the pile and for remorse I sat down and made the
tweaks I think are necessary myself.

I've pushed out the result to

  git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git x86/l1dflush

The only thing I did not address yet is that the documentation lacks any
mentioning of the SIGBUS mechanism which is invoked when a task which
asked for L1D flush protection ends up on a SMT sibling for whatever
reason. That's essential to have because it's part of the contract of
that prctl.

Balbir, can you please double check the result and prepare an updated
version from there?

If you don't have cycles, please let me know.

Thanks,

        tglx

  parent reply	other threads:[~2021-04-26 22:24 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
     [not found]     ` <87y2d5tpjh.ffs@nanos.tec.linutronix.de>
2021-04-26 22:24       ` Thomas Gleixner [this message]
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=87tunsofan.ffs@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=benh@kernel.crashing.org \
    --cc=bsingharora@gmail.com \
    --cc=dave.hansen@intel.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --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.