Skip to content
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

Merged
merged 1 commit into from Mar 12, 2020
Merged

esys: change the hierarchy type according to the spec #1531

merged 1 commit into from Mar 12, 2020

Conversation

tstruk
Copy link
Contributor

@tstruk tstruk commented Sep 26, 2019

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.

Copy link
Member

@idesai idesai left a 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?

@tstruk
Copy link
Contributor Author

tstruk commented Sep 26, 2019

@idesai this can be certainly put on hold for now. This PR is to start the discussion on what the best solution would be.

@tstruk
Copy link
Contributor Author

tstruk commented Sep 26, 2019

@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.

@idesai
Copy link
Member

idesai commented Sep 26, 2019

@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?

@tstruk
Copy link
Contributor Author

tstruk commented Sep 26, 2019

what do the handle values look like for ESYS_TR? Is it fixed?
Yes, see https://github.com/tpm2-software/tpm2-tss/blob/master/include/tss2/tss2_esys.h#L54

@AndreasFuchsTPM
Copy link
Member

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...
You could add a commit to this PR to set the version to 3.0-dev in configure.ac... ;-)

@tstruk
Copy link
Contributor Author

tstruk commented Oct 8, 2019

Tools can handle this change as follows: tpm2-software/tpm2-tools#1776

@tstruk tstruk closed this Jan 27, 2020
@tstruk tstruk deleted the hierarhy branch January 27, 2020 17:21
@tstruk tstruk restored the hierarhy branch January 27, 2020 20:00
@tstruk tstruk reopened this Jan 27, 2020
@tstruk
Copy link
Contributor Author

tstruk commented Feb 21, 2020

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
Copy link

codecov bot commented Mar 12, 2020

Codecov Report

Merging #1531 into master will decrease coverage by <.01%.
The diff coverage is 71.42%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
src/tss2-fapi/ifapi_policy_execute.c 91.22% <ø> (ø) ⬆️
src/tss2-fapi/api/Fapi_ExportKey.c 94.15% <ø> (ø) ⬆️
src/tss2-esys/api/Esys_LoadExternal.c 89.38% <66.66%> (-0.62%) ⬇️
src/tss2-esys/api/Esys_SequenceComplete.c 93.75% <66.66%> (-0.75%) ⬇️
src/tss2-esys/api/Esys_Hash.c 92% <75%> (-0.79%) ⬇️
src/tss2-esys/api/Esys_HierarchyControl.c 94.62% <75%> (-0.94%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9d3288a...8e577c2. Read the comment docs.

@tstruk tstruk merged commit 9d48cc7 into tpm2-software:master Mar 12, 2020
@tstruk tstruk deleted the hierarhy branch March 12, 2020 23:21
williamcroberts pushed a commit to williamcroberts/tpm2-tools that referenced this pull request Aug 13, 2020
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>
vittyvk added a commit to vittyvk/systemd that referenced this pull request Nov 16, 2022
…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>
poettering pushed a commit to systemd/systemd that referenced this pull request Nov 16, 2022
…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>
keszybz pushed a commit to systemd/systemd-stable that referenced this pull request Nov 24, 2022
…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)
jamacku pushed a commit to redhat-plumbers/systemd-rhel9 that referenced this pull request Nov 28, 2022
…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
Yamakuzure pushed a commit to elogind/elogind that referenced this pull request Dec 29, 2022
…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)
d-hatayama pushed a commit to d-hatayama/systemd that referenced this pull request Feb 15, 2023
…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>
Yamakuzure pushed a commit to elogind/elogind that referenced this pull request Oct 31, 2023
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants