On 12/13/2017 4:44 PM, Laszlo Ersek wrote:
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.d...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bell Song <binx.s...@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.
I do not understand either:)
But if the change doesn't expose more interfaces (_MAX in this case), I
feel safe because we can change much freely in future.
Anyway, this doesn't mean the patch is not correct.
Acked-by: Laszlo Ersek <ler...@redhat.com>
Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
--
Thanks,
Ray
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
