New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
esys: change the hierarchy type according to the spec #1531
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tstruk this will certainly break the command line options interface for tools release 4.0 and will require a 5.0 release. Can we put this PR on hold?
Is this PR required immediately for any reported bugs?
@idesai this can be certainly put on hold for now. This PR is to start the discussion on what the best solution would be. |
@idesai just thinking that to keep the options interface compatible you could actually support both types TPMI_RH_HIERARCHY and ESYS_TR and remap to the correct value before invoking the ESYS function. That one possible solution. |
what do the handle values look like for ESYS_TR? Is it fixed? |
|
That's a big one... :-( I guess the tools would not mind the command line options, but basically the tools would reuire an #ifdef for tss2_esys < 3.0 and tss2_esys >= 3.0 Seems like we're now guaranteed to break ABI... |
Tools can handle this change as follows: tpm2-software/tpm2-tools#1776 |
Fixes: #1522 |
There is a discrepancy between ESYS specification v0.90 rev4 and the ESYS implementation, where the specification defines hierarchy as ESYS_TR type and the implementation uses TPMI_RH_HIERARCHY type. The affected functions include: Esys_Hash(), Esys_HierarchyControl(), Esys_LoadExternal(), and Esys_SequenceComplete() plus their _Async() versions. This change makes the spec and the implementation consistent. Fixes: #1522 Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Codecov Report
@@ Coverage Diff @@
## master #1531 +/- ##
==========================================
- Coverage 80.46% 80.45% -0.01%
==========================================
Files 334 334
Lines 36421 36433 +12
==========================================
+ Hits 29305 29313 +8
- Misses 7116 7120 +4
Continue to review full report at Codecov.
|
The comment stated that we went from ESYS_TR types to TPM2_ types, however that is backwards. The change: - tpm2-software/tpm2-tss#1531 Went from TPM2_ types to ESYS_TR types, and thus for 3.0 we need to map to the right values. Signed-off-by: William Roberts <william.c.roberts@intel.com>
…arning systemd-cryptenroll complains (but succeeds!) upon binding to a signed PCR policy: $ systemd-cryptenroll --unlock-key-file=/tmp/passphrase --tpm2-device=auto --tpm2-public-key=... --tpm2-signature=..." /tmp/tmp.img ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x40000001 ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x4000000 New TPM2 token enrolled as key slot 1. The problem seems to be that Esys_LoadExternal() function from tpm2-tss expects a 'ESYS_TR_RH*' constant specifying the requested hierarchy and not a 'TPM2_RH_*' one (see Esys_LoadExternal() -> Esys_LoadExternal_Async() -> iesys_handle_to_tpm_handle() call chain). It all works because Esys_LoadExternal_Async() falls back to using the supplied values when iesys_handle_to_tpm_handle() fails: r = iesys_handle_to_tpm_handle(hierarchy, &tpm_hierarchy); if (r != TSS2_RC_SUCCESS) { ... tpm_hierarchy = hierarchy; } Note, TPM2_RH_OWNER was used on purpose to support older tpm2-tss versions (pre tpm2-software/tpm2-tss#1531), use meson magic to preserve compatibility. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
…arning systemd-cryptenroll complains (but succeeds!) upon binding to a signed PCR policy: $ systemd-cryptenroll --unlock-key-file=/tmp/passphrase --tpm2-device=auto --tpm2-public-key=... --tpm2-signature=..." /tmp/tmp.img ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x40000001 ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x4000000 New TPM2 token enrolled as key slot 1. The problem seems to be that Esys_LoadExternal() function from tpm2-tss expects a 'ESYS_TR_RH*' constant specifying the requested hierarchy and not a 'TPM2_RH_*' one (see Esys_LoadExternal() -> Esys_LoadExternal_Async() -> iesys_handle_to_tpm_handle() call chain). It all works because Esys_LoadExternal_Async() falls back to using the supplied values when iesys_handle_to_tpm_handle() fails: r = iesys_handle_to_tpm_handle(hierarchy, &tpm_hierarchy); if (r != TSS2_RC_SUCCESS) { ... tpm_hierarchy = hierarchy; } Note, TPM2_RH_OWNER was used on purpose to support older tpm2-tss versions (pre tpm2-software/tpm2-tss#1531), use meson magic to preserve compatibility. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
…arning systemd-cryptenroll complains (but succeeds!) upon binding to a signed PCR policy: $ systemd-cryptenroll --unlock-key-file=/tmp/passphrase --tpm2-device=auto --tpm2-public-key=... --tpm2-signature=..." /tmp/tmp.img ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x40000001 ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x4000000 New TPM2 token enrolled as key slot 1. The problem seems to be that Esys_LoadExternal() function from tpm2-tss expects a 'ESYS_TR_RH*' constant specifying the requested hierarchy and not a 'TPM2_RH_*' one (see Esys_LoadExternal() -> Esys_LoadExternal_Async() -> iesys_handle_to_tpm_handle() call chain). It all works because Esys_LoadExternal_Async() falls back to using the supplied values when iesys_handle_to_tpm_handle() fails: r = iesys_handle_to_tpm_handle(hierarchy, &tpm_hierarchy); if (r != TSS2_RC_SUCCESS) { ... tpm_hierarchy = hierarchy; } Note, TPM2_RH_OWNER was used on purpose to support older tpm2-tss versions (pre tpm2-software/tpm2-tss#1531), use meson magic to preserve compatibility. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> (cherry picked from commit 155c512)
…arning systemd-cryptenroll complains (but succeeds!) upon binding to a signed PCR policy: $ systemd-cryptenroll --unlock-key-file=/tmp/passphrase --tpm2-device=auto --tpm2-public-key=... --tpm2-signature=..." /tmp/tmp.img ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x40000001 ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x4000000 New TPM2 token enrolled as key slot 1. The problem seems to be that Esys_LoadExternal() function from tpm2-tss expects a 'ESYS_TR_RH*' constant specifying the requested hierarchy and not a 'TPM2_RH_*' one (see Esys_LoadExternal() -> Esys_LoadExternal_Async() -> iesys_handle_to_tpm_handle() call chain). It all works because Esys_LoadExternal_Async() falls back to using the supplied values when iesys_handle_to_tpm_handle() fails: r = iesys_handle_to_tpm_handle(hierarchy, &tpm_hierarchy); if (r != TSS2_RC_SUCCESS) { ... tpm_hierarchy = hierarchy; } Note, TPM2_RH_OWNER was used on purpose to support older tpm2-tss versions (pre tpm2-software/tpm2-tss#1531), use meson magic to preserve compatibility. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> (cherry picked from commit 155c512) Related: #2138081
…arning systemd-cryptenroll complains (but succeeds!) upon binding to a signed PCR policy: $ systemd-cryptenroll --unlock-key-file=/tmp/passphrase --tpm2-device=auto --tpm2-public-key=... --tpm2-signature=..." /tmp/tmp.img ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x40000001 ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x4000000 New TPM2 token enrolled as key slot 1. The problem seems to be that Esys_LoadExternal() function from tpm2-tss expects a 'ESYS_TR_RH*' constant specifying the requested hierarchy and not a 'TPM2_RH_*' one (see Esys_LoadExternal() -> Esys_LoadExternal_Async() -> iesys_handle_to_tpm_handle() call chain). It all works because Esys_LoadExternal_Async() falls back to using the supplied values when iesys_handle_to_tpm_handle() fails: r = iesys_handle_to_tpm_handle(hierarchy, &tpm_hierarchy); if (r != TSS2_RC_SUCCESS) { ... tpm_hierarchy = hierarchy; } Note, TPM2_RH_OWNER was used on purpose to support older tpm2-tss versions (pre tpm2-software/tpm2-tss#1531), use meson magic to preserve compatibility. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> (cherry picked from commit 155c51293d5bf37f54c65fd0a66ea29e6eedd580)
…arning systemd-cryptenroll complains (but succeeds!) upon binding to a signed PCR policy: $ systemd-cryptenroll --unlock-key-file=/tmp/passphrase --tpm2-device=auto --tpm2-public-key=... --tpm2-signature=..." /tmp/tmp.img ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x40000001 ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x4000000 New TPM2 token enrolled as key slot 1. The problem seems to be that Esys_LoadExternal() function from tpm2-tss expects a 'ESYS_TR_RH*' constant specifying the requested hierarchy and not a 'TPM2_RH_*' one (see Esys_LoadExternal() -> Esys_LoadExternal_Async() -> iesys_handle_to_tpm_handle() call chain). It all works because Esys_LoadExternal_Async() falls back to using the supplied values when iesys_handle_to_tpm_handle() fails: r = iesys_handle_to_tpm_handle(hierarchy, &tpm_hierarchy); if (r != TSS2_RC_SUCCESS) { ... tpm_hierarchy = hierarchy; } Note, TPM2_RH_OWNER was used on purpose to support older tpm2-tss versions (pre tpm2-software/tpm2-tss#1531), use meson magic to preserve compatibility. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
…arning systemd-cryptenroll complains (but succeeds!) upon binding to a signed PCR policy: $ systemd-cryptenroll --unlock-key-file=/tmp/passphrase --tpm2-device=auto --tpm2-public-key=... --tpm2-signature=..." /tmp/tmp.img ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x40000001 ERROR:esys:src/tss2-esys/esys_iutil.c:394:iesys_handle_to_tpm_handle() Error: Esys invalid ESAPI handle (40000001). WARNING:esys:src/tss2-esys/esys_iutil.c:415:iesys_is_platform_handle() Convert handle from TPM2_RH to ESYS_TR, got: 0x4000000 New TPM2 token enrolled as key slot 1. The problem seems to be that Esys_LoadExternal() function from tpm2-tss expects a 'ESYS_TR_RH*' constant specifying the requested hierarchy and not a 'TPM2_RH_*' one (see Esys_LoadExternal() -> Esys_LoadExternal_Async() -> iesys_handle_to_tpm_handle() call chain). It all works because Esys_LoadExternal_Async() falls back to using the supplied values when iesys_handle_to_tpm_handle() fails: r = iesys_handle_to_tpm_handle(hierarchy, &tpm_hierarchy); if (r != TSS2_RC_SUCCESS) { ... tpm_hierarchy = hierarchy; } Note, TPM2_RH_OWNER was used on purpose to support older tpm2-tss versions (pre tpm2-software/tpm2-tss#1531), use meson magic to preserve compatibility. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
There is a discrepancy between ESYS specification v0.90 rev4 and the
ESYS implementation, where the specification defines hierarchy
as ESYS_TR type and the implementation uses TPMI_RH_HIERARCHY type.
The affected functions include: Esys_Hash(), Esys_HierarchyControl(),
Esys_LoadExternal(), and Esys_SequenceComplete() plus their _Async()
version. This change makes the spec and the implementation consistent.