Re: [PATCH V2] UefiCpuPkg: Check invalid RegisterCpuFeature parameter

[Laszlo Ersek <lersek@redhat.com>]

On 12/13/17 03:35, Song, BinX wrote:
> V2:
> Update function name, add more detail description.
> V1:
> Check and assert invalid RegisterCpuFeature function parameter
> 
> Cc: Eric Dong <eric.dong@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bell Song <binx.song@intel.com>
> ---
>  .../Include/Library/RegisterCpuFeaturesLib.h       |  5 ++++
>  .../RegisterCpuFeaturesLib.c                       | 29 ++++++++++++++++++++++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> index 9331e49..fc3ccda 100644
> --- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> +++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> @@ -71,6 +71,11 @@
>  #define CPU_FEATURE_APIC_TPR_UPDATE_MESSAGE         (32+9)
>  #define CPU_FEATURE_ENERGY_PERFORMANCE_BIAS         (32+10)
>  #define CPU_FEATURE_PPIN                            (32+11)
> +//
> +// Currently, CPU_FEATURE_PROC_TRACE is the MAX feature we support.
> +// If you define a feature bigger than it, please also replace it
> +// in RegisterCpuFeatureLibIsFeatureValid function.
> +//
>  #define CPU_FEATURE_PROC_TRACE                      (32+12)
>  
>  #define CPU_FEATURE_BEFORE_ALL                      BIT27
> diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> index dd6a82b..6ec26e1 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> @@ -81,6 +81,34 @@ DumpCpuFeature (
>  }
>  
>  /**
> +  Determines if the CPU feature is valid.
> +
> +  @param[in]  Feature        Pointer to CPU feature
> +
> +  @retval TRUE  The CPU feature is valid.
> +  @retval FALSE The CPU feature is invalid.
> +**/
> +BOOLEAN
> +RegisterCpuFeatureLibIsFeatureValid (
> +  IN UINT32        Feature
> +  )
> +{
> +  UINT32      Data;
> +
> +  Data = Feature;
> +  Data &= ~(CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER | CPU_FEATURE_BEFORE_ALL | CPU_FEATURE_AFTER_ALL);
> +  //
> +  // Currently, CPU_FEATURE_PROC_TRACE is the MAX feature we support.
> +  // If you define a feature bigger than it, please replace it at below.
> +  //
> +  if (Data > CPU_FEATURE_PROC_TRACE) {
> +    DEBUG ((DEBUG_ERROR, "Invalid CPU feature: 0x%x ", Feature));
> +    return FALSE;
> +  }
> +  return TRUE;
> +}
> +
> +/**
>    Determines if the feature bit mask is in dependent CPU feature bit mask buffer.
>  
>    @param[in]  FeatureMask        Pointer to CPU feature bit mask
> @@ -444,6 +472,7 @@ RegisterCpuFeature (
>  
>    VA_START (Marker, InitializeFunc);
>    Feature = VA_ARG (Marker, UINT32);
> +  ASSERT (RegisterCpuFeatureLibIsFeatureValid(Feature));
>    while (Feature != CPU_FEATURE_END) {
>      ASSERT ((Feature & (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER))
>                      != (CPU_FEATURE_BEFORE | CPU_FEATURE_AFTER));
> 

The consensus thus far seems to be that we should not add a separate
_MAX macro for this purpose. I don't understand why -- in my opinion it
would be easier to update the macro in one place only.

Now, I realize we have a library class header file here, and a library
instance. Those things are separate; it is conceivable that another
library instance is developed independently, and thus we should not tie
the MAX feature of *all* library instances to the same central class header.

However, this separation is already being violated in this patch: the
RegisterCpuFeatureLibIsFeatureValid() function is an implementation
detail of the (currently only one) library instance. Thus, the lib class
header should not refer to it, even in a comment.

So, I don't understand why we can't just add a _MAX macro. The central
library instance could use _MAX; all other (out of tree) instances would
not use _MAX.

Anyway, this doesn't mean the patch is not correct.

Acked-by: Laszlo Ersek <lersek@redhat.com>

Thanks
Laszlo