You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But sometimes some of these do not really reflect completely what the test was for or if there's a need for next steps.
We came up with an idea of moving to reporting these results with return codes. The format is:
Bits (64)
Field
63:32
Type
31:4
Test identifier
3:0
Reserved
Type
With types being (for example):
[63] Locks
[62] Mitigation
[61] Configuration
[60] Protection
[59] Access (write/read)
[58] Device disabled
[57] Feature disabled
[56] Unsupported feature
[55] Debug feature
[54] Not applicable
[53] All FFs
The return code could potentially have more than one type of result set, depending on what the test checks. If the test passes no bit will get set so type will be 0.
Test identifier
Each test would have a unique ID.
Return code example:
0x8000_0000_0030_0000 (Locks bit 63, ID bits 20 and 21).
0x0000_0000_0030_0000 (Same test but successful run)
This feature will touch most files and will also change the way logging looks. Instead of the current results each test would return a code and a link to documentation where more information and next steps can be found. The idea is to bring changes little by little to give time to adjust. Here's a general schedule, more details to come later:
Step 1
Finish logger transition to make better use of python logging.
Step 2
Implement return codes while keeping old interface
Step 3
Start migration and documentation updates
The intent of this discussion is to let everyone know about this idea and share opinions and thoughts on it before implementation.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently CHIPSEC modules return a
ModuleResult
which are defined as follows:But sometimes some of these do not really reflect completely what the test was for or if there's a need for next steps.
We came up with an idea of moving to reporting these results with return codes. The format is:
Type
With types being (for example):
The return code could potentially have more than one type of result set, depending on what the test checks. If the test passes no bit will get set so type will be 0.
Test identifier
Each test would have a unique ID.
Return code example:
This feature will touch most files and will also change the way logging looks. Instead of the current results each test would return a code and a link to documentation where more information and next steps can be found. The idea is to bring changes little by little to give time to adjust. Here's a general schedule, more details to come later:
Step 1
Finish logger transition to make better use of python logging.
Step 2
Implement return codes while keeping old interface
Step 3
Start migration and documentation updates
The intent of this discussion is to let everyone know about this idea and share opinions and thoughts on it before implementation.
Beta Was this translation helpful? Give feedback.
All reactions