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: <YuLBBe2BXrC7CNiu@quatroqueijos>
Date:   Thu, 28 Jul 2022 14:01:57 -0300
From:   Thadeu Lima de Souza Cascardo <cascardo@...onical.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Dimitri John Ledkov <dimitri.ledkov@...onical.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        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

On Thu, Jul 28, 2022 at 05:50:06PM +0200, Borislav Petkov wrote:
> + 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...
> 

I may be completely wrong here, so excuse me throwing out this idea.

But isn't it also possible that userspace attacks the kernel by leveraging
speculative execution when in firmware? So even when firmware is trusted, it
might not have mitigations like retpoline and rethunks. So userspace will train
the BTB in order to make a RET in the firmware speculate to a firmware gadget
that may spill out kernel bits to the cache.

Even though there is some limited mapping when doing the firmware calls, there
are still some kernel pages mapped.

Cascardo.

> Thx.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette