[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 4/4] x86/microcode: Prevent attempting updates if DIS_MCU_LOAD is set


  • To: Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 13 Jun 2023 08:57:06 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VHKBkZaCGJ1syBz6AmdtxAal+mFQZGoQ0aIUijLnACs=; b=lqrZkmtAiH7BPYupaG+U3raA2Jz6NVz4OCBCbd043LPsb+bPk0DMEayEOJajvSMF4zqQw/uFD/kuPvj6EI2DQ+62ehqZ34/nasgzsa9879D9Yr7o4zdOMCRCkyN5aXHiWr0R034KV+mROvpsTkYqunO9s2C+++LX5Mhy6WPS3p98YiZnlHd7vglrVex5eRxbytmOb3MSJQ2EL+C+gvJYrdkw1EQnIz3JvkRFfvL6BTq/rrss/FJQTGT/D00eYCKemeT+piPGVAR6sxsuS9TL2U53cl2uziCRkomBJujO5QMtzIH2vgBbbWQZqwJosk/T0/nG8V4oNgSsUgoIgcvIIQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nNLxqfcdNpqQk/PNtc4KWIo8w3pLI2E15Vc2tHBqiHUjGKJQ3i58+dW+u1fXVmJCOWhNp5GYDGkhU/1fCcYhseEIPiL0OUrzjwSqcsGMvkJqxHcEmQ1jPoAXzOABGlzBKuCk5NGIyEHHzTYe2a2726/NNWJywQaE8uv0l5D+ZF7kLqqIa1PPdcb5AZW29wPqD9GzoN/Ar/nUX7MBCoQJ5Rc8qWtTXj6uW3nl2EpMvx+kzM2Wj4Zz594sZPvXWLxXhKZgYidNFZEi/OAPBP/4m0V86V1SYgoFvtg/FM80exlu0dimR1PxoBGS0WEYz8K8MkAcX+rRC2eIClLoSSJoHQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 13 Jun 2023 06:57:23 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 05.06.2023 19:08, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -749,11 +749,12 @@ __initcall(microcode_init);
>  /* Load a cached update to current cpu */
>  int microcode_update_one(void)
>  {
> +    if ( ucode_ops.collect_cpu_info )
> +        alternative_vcall(ucode_ops.collect_cpu_info);
> +
>      if ( !ucode_ops.apply_microcode )
>          return -EOPNOTSUPP;
>  
> -    alternative_vcall(ucode_ops.collect_cpu_info);
> -
>      return microcode_update_cpu(NULL);
>  }

This adjustment (and related logic below) doesn't really fit the purpose
that the title states. I wonder if the two things wouldn't better be
split.

> @@ -849,12 +850,25 @@ static void __init early_read_cpuid_7d0(void)
>              = cpuid_count_edx(7, 0);
>  }
>  
> +static bool __init this_cpu_can_install_update(void)
> +{
> +    uint64_t mcu_ctrl;
> +
> +    if ( !cpu_has_mcu_ctrl )
> +        return true;
> +
> +    rdmsrl(MSR_MCU_CONTROL, mcu_ctrl);
> +    return !(mcu_ctrl & MCU_CONTROL_DIS_MCU_LOAD);
> +}

As Andrew says, in principle AMD could have a means as well. Surely that
would be a different one, so I wonder if this shouldn't be a new hook.

> @@ -871,6 +885,15 @@ int __init early_microcode_init(unsigned long 
> *module_map,
>           * present.
>           */
>          ucode_ops = intel_ucode_ops;
> +
> +        /*
> +         * In the case where microcode updates are blocked by the
> +         * DIS_MCU_LOAD bit we can still read the microcode version even if
> +         * we can't change it.
> +         */
> +        if ( !this_cpu_can_install_update() )
> +            ucode_ops = (struct microcode_ops){ .collect_cpu_info =
> +                                    intel_ucode_ops.collect_cpu_info };

Similarly I'm not happy to see a direct reference to some vendor specific
field. I think it wants to be the hook to return such an override struct.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.