Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
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
In-Reply-To: <87y2d5tpjh.ffs@nanos.tec.linutronix.de>
References: <20210108121056.21940-1-sblbir@amazon.com> <cf89f0389379daaaff0cbce9c5f1550866e55e91.camel@amazon.com> <202104081319.DAB1D817@keescook> <87y2d5tpjh.ffs@nanos.tec.linutronix.de>
Date:   Tue, 27 Apr 2021 00:24:16 +0200
Message-ID: <87tunsofan.ffs@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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