Received: by 2002:ac0:e34a:0:0:0:0:0 with SMTP id g10csp638473imn; Thu, 28 Jul 2022 11:11:19 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s6+e6ICySgp2QCQ5MJ78GmWKhpsZZz1w2v1SnfLwYHiAoCCl0bctZ0sqm7jwk0mEOKzHWN X-Received: by 2002:a17:907:6295:b0:703:92b8:e113 with SMTP id nd21-20020a170907629500b0070392b8e113mr120897ejc.594.1659031878998; Thu, 28 Jul 2022 11:11:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659031878; cv=none; d=google.com; s=arc-20160816; b=i4qjeG/57tbytUrQmWdvXvTC4XQPbAzVZkM6PI5c9xLiCYhLnq6Nj6Yd2MUde12VMj bKkxnjtaaYCb5a7lFcgkVpzaQxQSTlJsjMa9V1zEjEDlG8/yjXS4sA6VyhFyatDsqKrW LBBPMbANx9PmVFf5+Ye5vszEhgTKlNEUgWg/pipG1Ze7Jm37lm2BVhVN9zchJRJtn+/3 HutV/UxlNkK0IRr5SZTEV1UnSIG8tm5+Le4X6Yz+e4brcazXU8+bTJetwWJfHuZcWAAk rQ6gNi/RN1htN7U4MaLCEAr6SNiF0R1oIEI1EX9hCWWnv6BwDwxrHtvD97p8EUs+otU2 kyTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=eJFVXCtA/nJevHAQEgQ8T/YTuTveTIvqgwNCM/uhRKs=; b=dKDMzuMxeoWwU1Lb6DQd/60ebZSEIWV1oU9NuTaJywOl+L2qbSyqV4Xp2la/NtL75L 0qfiXkOihroWlU8ymdNx54PGQHuDgrrQ0on/Rj722rex71DhQQ9v9oWwj9zqhvAW8KgJ 0QCzwDWG1ORhiA/BtvcCV7CIGwcI1u6Uw+JWm94WpXg5bz/c5VEUY/s0JwEngJBNFinF 97EW6J2dtKB6MZswW64OiJjEYleQrADpA/tJNykFSeJilsmNeIee/zexftdYOHh26R6D FGuD270RS1xsHIiMMAlrMh/cXyvVkvqlh0RCXI6Bzta3SZRAM9yUEewKYlyDWf6KChkK ZE2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b="BjTP/uyZ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y6-20020a056402270600b0043a1267f8dbsi1459457edd.120.2022.07.28.11.10.54; Thu, 28 Jul 2022 11:11:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b="BjTP/uyZ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232153AbiG1RCK (ORCPT + 99 others); Thu, 28 Jul 2022 13:02:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229632AbiG1RCH (ORCPT ); Thu, 28 Jul 2022 13:02:07 -0400 Received: from smtp-relay-canonical-1.canonical.com (smtp-relay-canonical-1.canonical.com [185.125.188.121]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A884953D32 for ; Thu, 28 Jul 2022 10:02:05 -0700 (PDT) Received: from quatroqueijos (1.general.cascardo.us.vpn [10.172.70.58]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-1.canonical.com (Postfix) with ESMTPSA id 47D25416EC; Thu, 28 Jul 2022 17:02:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1659027723; bh=eJFVXCtA/nJevHAQEgQ8T/YTuTveTIvqgwNCM/uhRKs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=BjTP/uyZp7aD9rA17SRyJYGVEchnk5xL/j+S+UEUrkAosmZJbOOrAZ3S2UQc4YVBN s6soNx5Ch8N9eylVJCXhA9AMQMjZLE+MyF4RsCWO8sWkiUTTZdTcxvMKeSUGHSn+HH ffBuOhBEsqpWu5MqxgDPlAA3HyDjTo8sNkpbIfmlBo8ZG6ra+HRwAxJEVPjbWdexfz U60Wd9jauPD5vFpqvsBkvIdDeSRhhPVDnipCRaeSi2/A2T25QN2rHr5UpVPbmXg03R cjH240bdyfXBD/NTpzhPk2EUa88d+3MUG38BWrDmwHMd75FIcTxWv3qtL6ER0aCGL7 R/YcbCIcl0q7Q== Date: Thu, 28 Jul 2022 14:01:57 -0300 From: Thadeu Lima de Souza Cascardo To: Borislav Petkov Cc: Dimitri John Ledkov , Andrew Cooper , linux-kernel@vger.kernel.org, x86@kernel.org, Peter Zijlstra Subject: Re: [PATCH] x86/bugs: Do not enable IBPB at firmware entry when IBPB is not available Message-ID: References: <20220728122602.2500509-1-cascardo@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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