"The NV space defined by the platform firmware has an additional control, phEnableNV. When SET, NV
space defined by the platform firmware is accessible. When CLEAR, it is inaccessible. This permits
independent control of the platform firmware hierarchy and its NV space. For example, the platform
hierarchy can be disabled while still permitting access to platform firmware NV space."
This led me to believe that I could define a space under the platform hierarchy, and access it while the hierarchy was disabled for as long as phEnableNV is SET. However this doesn't work with the simulator.
Additionally, browsing through the source code of the simulator, I do not see any evidence that phEnableNV has been implemented the way it's described in the spec. There are only a few times phEnableNV is used in the code, in NVCommands.c and NVDymanic.c, and when it is, it's to further enforce the disabling of access to NV space (i.e. disable access if phEnableNV is CLEAR, even if phEnable is SET) rather than the reverse: enabling access when SET even if phEnable is CLEAR.
Am I incorrectly interpreting the wording from the specification, or has this feature just not been fully implemented yet?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The test case that does not work:
clear phEnable
set phEnableNV
attempt to access the NV index created under the platform hierarchy and expect success
According to my reading of the specification this should work. (the relevant quote is "For example, the platform hierarchy can be disabled while still permitting access to platform firmware NV space")
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The spec wording is (section 13.1 here: https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.38.pdf):
"The NV space defined by the platform firmware has an additional control, phEnableNV. When SET, NV
space defined by the platform firmware is accessible. When CLEAR, it is inaccessible. This permits
independent control of the platform firmware hierarchy and its NV space. For example, the platform
hierarchy can be disabled while still permitting access to platform firmware NV space."
This led me to believe that I could define a space under the platform hierarchy, and access it while the hierarchy was disabled for as long as phEnableNV is SET. However this doesn't work with the simulator.
Additionally, browsing through the source code of the simulator, I do not see any evidence that phEnableNV has been implemented the way it's described in the spec. There are only a few times phEnableNV is used in the code, in NVCommands.c and NVDymanic.c, and when it is, it's to further enforce the disabling of access to NV space (i.e. disable access if phEnableNV is CLEAR, even if phEnable is SET) rather than the reverse: enabling access when SET even if phEnable is CLEAR.
Am I incorrectly interpreting the wording from the specification, or has this feature just not been fully implemented yet?
The code is NvIndexIsAccessible().
I did one test case where I cleared phEnableNV and the index was not accessible.
Can you tell me one precise test case that you think does not work?
The test case that does not work:
clear phEnable
set phEnableNV
attempt to access the NV index created under the platform hierarchy and expect success
According to my reading of the specification this should work. (the relevant quote is "For example, the platform hierarchy can be disabled while still permitting access to platform firmware NV space")
This worked for me.
Here's a working script. I script test cases rather than writing code because it's much faster.