linux-kernel - Re: [PATCH v4 0/5] Next revision of the L1D flush patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 27 Apr 2021 00:24:16 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Kees Cook <keescook@...omium.org>, bsingharora@...il.com
Cc:     "mingo\@redhat.com" <mingo@...hat.com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz\@infradead.org" <peterz@...radead.org>,
        "torvalds\@linux-foundation.org" <torvalds@...ux-foundation.org>,
        "jpoimboe\@redhat.com" <jpoimboe@...hat.com>,
        "x86\@kernel.org" <x86@...nel.org>,
        "tony.luck\@intel.com" <tony.luck@...el.com>,
        "dave.hansen\@intel.com" <dave.hansen@...el.com>,
        "thomas.lendacky\@amd.com" <thomas.lendacky@....com>,
        "benh\@kernel.crashing.org" <benh@...nel.crashing.org>,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH v4 0/5] Next revision of the L1D flush patches

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