linux-kernel - Re: [PATCH] x86/bugs: Do not enable IBPB at firmware entry when IBPB is not available

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: <YuKwLnYlzC0R8xrF@zn.tnic>
Date:   Thu, 28 Jul 2022 17:50:06 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Dimitri John Ledkov <dimitri.ledkov@...onical.com>,
        Thadeu Lima de Souza Cascardo <cascardo@...onical.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] x86/bugs: Do not enable IBPB at firmware entry when IBPB
 is not available

+ Cooper to sanity-check me.

On Thu, Jul 28, 2022 at 05:18:31PM +0200, Borislav Petkov wrote:
> On Thu, Jul 28, 2022 at 03:33:35PM +0100, Dimitri John Ledkov wrote:
> > Azure public cloud (so it is Azure custom hyper-v hypervisor) these
> > instance types https://docs.microsoft.com/en-us/azure/virtual-machines/dav4-dasv4-series
> 
> Thank you both for the info.
> 
> Virt is an awful piece of sh*t when it goes and emulates all kinds of
> imaginary CPUs. And AMD machine *without* an IBPB which is affected by
> retbleed. Well, f*ck that.
> 
> Does that say somewhere on azure that those guests need to even enable
> the mitigation or does the HV mitigate it for them?
> 
> Because I wouldn't mind to simply disable the mitigation when on a
> hypervisor which doesn't support IBPB.

So for 5.19 we probably should take the one-liner just so that we
release with all known issues fixed.

Going forward, I'm thinking all that FW-mitigation selection should go
into a function called something like firmware_select_mitigations()
which gets called at the end of check_bugs(), after all mitigation
selectors have run.

And in there, the first check should be if X86_FEATURE_HYPERVISOR and if
set, not set any mitigations for firmware calls.

Because, frankly, is there any point in protecting against firmware
calls in the guest? The guest firmware is part of the hypervisor which
gets supplied by the guest owner or cloud provider or so.

In the former case you probably don't need protection and in the latter,
you don't have a choice.

But I'm unclear on the fw-in-the-guest thing - I'm sure Andy has a
better idea...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette