tpm2: configure vendor/manufacturer values#369
tpm2: configure vendor/manufacturer values#369ben-dav-lytle wants to merge 3 commits intostefanberger:masterfrom
Conversation
Signed-off-by: Ben Lytle <ben.dav.lytle@hpe.com>
I am not sure whether this flexibility will be very helpful, though: By now any change to any of the fields can cause backwards compatibility issues, such as for example with pkcs11 drivers where the name of the device goes into the pkcs11 URI and an upgrade of libtpms could then be causing the device URI not to work anymore (since the device is identified differently) and crypto to fail. If we want to make it flexible then the default values MUST all be exactly as they are now. Also, migration between differently configured libtpms could cause these types of issues. |
That's what I was afraid of.
If we make the default values the exact same as they are now, I can see one obvious issue with differing libtpms versions - |
That would be an unnecessary annoyance for any user that doesn't know why things do not work anymore. Who would be configuring libtpms with differing values than what they have been for years now? |
Completely agree.
If a different company wants to use this project to create a TPM, and brand it as something else (something like Google Cloud: https://cloud.google.com/blog/products/identity-security/virtual-trusted-platform-module-for-shielded-vms-security-in-plaintext, where they use https://sourceforge.net/projects/ibmswtpm2/). |
Is this an expressed intention from Google Cloud (or anyone else) or a hypothesis? |
src/tpm2/VendorString.h
Outdated
| Define up to 4, 4-byte, vendor-specific strings. The strings must each be 4 bytes long. | ||
| These values define the response for TPM_PT_VENDOR_STRING_(1-4) in TPM2_GetCapability(). */ | ||
| #ifndef CONFIG_VENDOR_STRING_1 | ||
| #define VENDOR_STRING_1 "fTPM" |
There was a problem hiding this comment.
The default here would have to be "SW "
|
|
||
| // the less significant 32-bits of a vendor-specific value indicating the version of the firmware | ||
| #define FIRMWARE_V2 (0x00163636) | ||
| #ifdef CONFIG_VENDOR_STRING_2 |
There was a problem hiding this comment.
This would have to have a default of " TPM".
src/tpm2/VendorString.h
Outdated
| #define _STRINGIFY(x) #x | ||
| #endif | ||
| #ifndef STRINGIFY | ||
| #define STRINGIFY(x) _STRINGIFY(x) |
There was a problem hiding this comment.
These could be useful elsewhere. Move to a Utils.h?
There was a problem hiding this comment.
Found it already defined in tpm_library_intern.h
src/tpm2/VendorString.h
Outdated
| #error FIRMWARE_V1 is not provided. \ | ||
| Please modify VendorString.h to provide a vendor specific firmware \ | ||
| version | ||
| #define FIRMWARE_V1 0x00000000 |
There was a problem hiding this comment.
Also this here should go back to its previous default value. None of the existing users, like distros, should have to modify their build process and ./configure line to get back the old default values. So all values have to default to what they were before.
I believe what Google Cloud has detailed in the article is their current vTPM solution. Other than that, it is a hypothesis. |
Signed-off-by: Ben Lytle <ben.dav.lytle@hpe.com>
Pull Request Test Coverage Report for Build 2762
💛 - Coveralls |
3 participants
Provide a way to configure Vendor/Manufacturer values.
This also changes default vendor/manufacturer strings to be more generic (remove IBM specifics; makes IBM less liable? 😄)
Cleaned up comments that were a little confusing in VendorString.h, most likely from the Microsoft Reference code port.
I know a major concern is swtpm state and downgrading versions, and these values (at least Manufacturer, Vendor Strings, and Firmware Version) show up in the properties-fixed get capability command. What I'm not sure of is how tightly this is coupled with
the swtpm state and how it would affect earlier libtpms versions.