linux-kernel - Re: [PATCH 0/7] IBRS patch series

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20180105144340.GF26807@redhat.com>
Date:   Fri, 5 Jan 2018 15:43:40 +0100
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     "Van De Ven, Arjan" <arjan.van.de.ven@...el.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/7] IBRS patch series

On Thu, Jan 04, 2018 at 09:22:34PM +0000, Van De Ven, Arjan wrote:
> personally I am comfortable with retpoline on Skylake, but I would
>like to have IBRS as an opt in for the paranoid.

I think this whole variant#2 issue has to be fixed mathematically or
not at all, the reason is that it's already "near zero risk" to begin
with.

If we leave any theoretical issues open we can as well stick with the
"near zero risk" wording on AMD website and not fix anything.

Doing a huge amount of work with reptoline and then you find SMM is
called reproducibly somehow and a new PoC could exist for it, not fun.

Whatever solution should be total and guaranteed or there's huge
amount of resources wasted.

Again spectre variant#2 this is "near zero risk" to begin with, on all
CPUs because of the complexity to mount an attack on any given
kernel/CPU combination out there. I'm mostly thinking about the "guest
mode"/"host kernel mod" isolation here but this should apply in
general to all kernel protection for spectre variant#2.

If we can do a 3 way alternative IBRS on skylake, repotline + IBRS
around all BIOS, graphics firmware and pci firmware + kernel asm
patched with a 2-way alternative between amd reptoline and intel
reptoline emitted 2-way by same gcc build, and still guarantee this
solution is as mathematically safe as a pure IBRS (which is obviously
mathematically safe), ok. Otherwise it'd prefer to stick to pure IBRS
and skip the reptoline complexity and fallouts here and there around
bios asm firmware SMM etc.. not to tell the need to rebuild qemu with
reptoline with 2-way amd/intel alternatives self modifying code in
userland during qemu startup to achieve ibrs 1 ibpb 1 + prctl IBRS on
qemu with repotline.

Thanks,
Andrea