chore(deps): Bump tdx-attest-rs from DCAP_1.16 to DCAP_1.19

[dependabot]

Bumps tdx-attest-rs from DCAP_1.16 to DCAP_1.19.

Release notes

Sourced from tdx-attest-rs's releases.

Intel(R) SGX DCAP 1.19 Release

Resigned all Intel SGX Architecture Enclaves.

Upgraded Intel SGX Quote Verification Enclave to integrate OpenSSL/SgxSSL 3.0.10.

Added Attestation Library support for Intel(R) TDX Migration TD.

Added Rust wrapper for low-level Quote Generation APIs.

Enabled SE_TRACE log in release binary.

Updated Rust QVL wrapper to use native Rust structure for quote verification collateral.

Added a limitation in the DCAP QVL to only allow the user to set the QvE load policy once.

Fixed bugs.

Intel(R) SGX DCAP 1.18 Release

Introduced Intel(R) TDX 1.4 and 1.5 support.

Upgraded Ring3 Abstraction Layer (R3AAL) library to support Intel(R) TDX MVP 6.2 kernel.

Enhanced quote verification performance in multi-thread scenarios.

Upgraded Intel(R) SGX Quote Verification Enclave to integrate latest OpenSSL/SgxSSL 1.1.1u.

Fixed bugs.

Intel(R) SGX DCAP 1.17 Release

Applied CVE-2023-1255, CVE-2023-0465, and CVE-2023-0466 patches to SgxSSL/OpenSSL 1.1.1t.

Upgraded to Intel(R) Integrated Performance Primitives (IPP) Cryptography library version 2021.7.

Upgraded Intel SGX Quote Verification Enclave to integrate updated SgxSSL.

Enhanced the attestation local cache functionality by giving users the option to provide their own cache file.

Enabled QPL/QCNL log in DCAP samples.

Fixed bugs.

Commits

• 8a40733 Intel(R) SGX DCAP 1.19 Release
• 6882afa Intel(R) SGX DCAP 1.18 Release
• e7604e0 fix(sgx-dcap-quoteverify-sys): successfull build with SGX_SDK unset
• b1cdd25 build(deps): increase bindgen version
• 0443ae2 Intel(R) SGX DCAP 1.17 Release
• 4cb5c8b Fix typo in comments
• 71bc4f6 Fix typo in sgx_dcap_quoteverify.h
• 7f84575 Update to correct URL for Azure local_pck_url (#307)
• 1e969e0 QuoteGeneration/Makefile: Fix incorrect usage of exit
• 3ea8e6b Merge pull request #300 from fqiu1/add-qgs-get-platform-info
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[fitzthum]

@Xynnn007 @arronwy is this safe?

[Xynnn007]

it is not safe for the underlying lib version

[mythi]

it is not safe for the underlying lib version

What's the concern? AFAICS the crate has not had functional changes since 1.16 and the builds are already using "latest" due to #352

[Xynnn007]

it is not safe for the underlying lib version

What's the concern? AFAICS the crate has not had functional changes since 1.16 and the builds are already using "latest" due to #352

I have checked inside the code that the API does not change, while I get suggestions from Intel folks that it is recommended to use the same version of DCAP as the underlying libtdx in guest image.

It is awkward that current rootfs uses dcap v1.15 https://github.com/kata-containers/kata-containers/blob/CCv0/tools/osbuilder/rootfs-builder/ubuntu/rootfs_lib.sh#L52 and it works well. My idea is we can leave it as-is in this release because if it fails we must need another PR to guest-components to fix, which will waste time. We can try to update the lib here and the version in guest image in next release cycle, during which we will have much time to fix potential bugs.

[fitzthum]

Ok. Let's not merge this right now if we are uncertain about it.

[mythi]

It is awkward that current rootfs uses dcap v1.15

should it move to v1.16 for the release to match what guest-component uses? v1.15 is almost 1 year old

[mythi]

We can try to update the lib here and the version in guest image in next release cycle, during which we will have much time to fix potential bugs.

Maybe now is the time?

[Xynnn007]

We can try to update the lib here and the version in guest image in next release cycle, during which we will have much time to fix potential bugs.

Maybe now is the time?

Could I assign this to you?

[mythi]

We can try to update the lib here and the version in guest image in next release cycle, during which we will have much time to fix potential bugs.

Maybe now is the time?

Could I assign this to you?

I don't have the powers to merge. I think it needs to be made in two stages: 1) get this PR merged first, 2) update the rootfs packages at the same time a new version of this repo is pulled into the kata build

[Xynnn007]

1. get this PR merged first,

I can help to get this merged

2. update the rootfs packages at the same time a new version of this repo is pulled into the kata build

I know that people are busy doing merge-to-main things. I am not sure which branch and whether it is ok to do this now. Hi @fitzthum @stevenhorsman Could you share some contexts?

[stevenhorsman]

I know that people are busy doing merge-to-main things. I am not sure which branch and whether it is ok to do this now. Hi @fitzthum @stevenhorsman Could you share some contexts?

So it order to get this merged and tested in kata-container's rootfs, we aren't in a good spot now:

• CCv0 has the attestation-agent included, but doesn't have any CI running at the moment
• main doesn't have the attestation-agent in yet.

I guess there are a couple of approaches we could take if this is urgent to merge into attestation-agent now:

• bump the attestation-agent version in CCv0 and rely on people locally building and testing it
• Accept that we don't have CI at the moment and we'll take a risk that it's not tested as part of kata-containers until we have a feature like sealed secrets that integrations the attestation-agent in main]

I'm not sure if this helps - sorry if I'm missing background, or other suggestions.

[dependabot]

Superseded by #442.