Unable to Generate Attestation Document - Response code value: 0x2d5

[kalamoo]

Hi,

I'm unable to generate a Nitro TPM attestation document using nitro-tpm-attest in any configuration I've tried. The attempts result in a TPM error indicating "structure is the wrong size" (error code 0x2d5).

Environment:

• OS: Amazon Linux 2023 (with kernel: 6.1.155-176.282.amzn2023.x86_64)
• Instance type: t3.small
• AMI: NitroTPM-enabled AMI created following this aws tutorial

After launching the instance, I can see the tpm devices.

$ ls /dev | grep tpm
tpm0
tpmrm0

Setting 1: using pre-installed binary in Amazon Linux 2023

• without sudo (permission denied)

$ /usr/bin/nitro-tpm-attest 
ERROR:tcti:src/tss2-tcti/tcti-device.c:454:Tss2_Tcti_Device_Init() Failed to open specified TCTI device file /dev/tpm0: Permission denied 
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:169:tcti_from_file() Could not initialize TCTI file: device 
ERROR:tcti:src/tss2-tcti/tctildr.c:430:Tss2_TctiLdr_Initialize_Ex() Failed to instantiate TCTI 
Error: response code not recognized

Caused by:
    0: response code not recognized
    1: Response code value: 0xa000a

• with sudo (tpm error, structure size error)

$ sudo /usr/bin/nitro-tpm-attest 
WARNING:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:345:Esys_NV_DefineSpace_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:121:Esys_NV_DefineSpace() Esys Finish ErrorCode (0x000002d5) 
Error: structure is the wrong size (associated with parameter number 2)

Caused by:
    0: structure is the wrong size (associated with parameter number 2)
    1: Response code value: 0x2d5

Setting 2: using this repository and cargo

$ git clone <this repo>
$ cd NitroTPM-Tools/nitro-tpm-attest
$ cargo build --release
$ sudo ./target/release/nitro-tpm-attest 
WARNING:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:345:Esys_NV_DefineSpace_Finish() Received TPM Error 
ERROR:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:121:Esys_NV_DefineSpace() Esys Finish ErrorCode (0x000002d5) 
Error: structure is the wrong size (associated with parameter number 2)

Caused by:
    0: structure is the wrong size (associated with parameter number 2)
    1: Response code value: 0x2d5

Note that the same 0x2d5 error occurs when adding options like --public-key, --nonce, or --user-data.

I appreciate any guidance on resolving this issue or clarifying the expected setup.

Thanks in advance!

[agraf]

Could you please try if it works when you run on a different instance type, such as c5.large?

[kalamoo]

Thanks for the reply!

Since I am using free tier now, so I don't have access to c5.large. But I quictly tested with other instance types c7i-flex.large and m7i-flex.large, and I found that they even don't have /usr/bin/nitro-tpm-attest installed (though I used the same way to re-create a NitroTPM-abled AMI again). And I also tried the setting 2, I found that tss dependencies are missing.

$ /usr/bin/nitro-tpm-attest
-bash: /usr/bin/nitro-tpm-attest: No such file or directory

$ (in ~/NitroTPM-Tools/nitro-tpm-attest) cargo build --release
thread 'main' panicked at /home/ec2-user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tss-esapi-sys-0.5.0/build.rs:42:14:
  Failed to find tss2-sys library.: 
  pkg-config exited with status code 1
  > PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --libs --cflags tss2-sys 'tss2-sys >= 2.4.6'

  The system library `tss2-sys` required by crate `tss-esapi-sys` was not found.
  The file `tss2-sys.pc` needs to be installed and the PKG_CONFIG_PATH environment variable must contain its parent directory.
  The PKG_CONFIG_PATH environment variable is not set.

  HINT: if you have installed the library, try setting PKG_CONFIG_PATH to the directory containing `tss2-sys.pc`.

[agraf]

Let's separate the 2 problems:

instance types - Is there any way for you to try on a non-free-tier instance type? A temporary issue only affecting these specific instances may prevent access to the NitroTPM attestation document.

AMI creation - The AMI you create should be identical regardless of instance type. So you can just reuse your existing AMI. The fact that /usr/bin/nitro-tpm-attest is not present in your instance is puzzling. Something must have gone badly the second time you built the AMI. Is there anything in the creation logs that would be able to provide insights as to what?

[kalamoo]

About the instance type: yes I would try a non-free-tier one.

About AMI: nope, the creation log seems fine.

[kalamoo]

Hi, I tested with c5.large, but I encountered the same situation as in c7i-flex.large and m7i-flex.large, that is, I can't find /usr/bin/nitro-tpm-attest installed, and tss dependencies are missing. This is super puzzling, cause I use exactly the same AMI for the instance of type t3.small, and for the c5.large, c7i-flex.large, m7i-flex.large.

[roshanrags]

The original issue comes from SIZE here. Most t3 instances seem to have a maximum size of 0x800 while the code tries to get 0x2000 (other larger instance families seem fine). You can check the size using the below command (look for TPM2_PT_NV_INDEX_MAX):

tpm2_getcap properties-fixed

@agraf I'm not sure if it's possible to make it work with smaller buffer sizes, but documenting which instance families are supported would be great

[jplock]

I just ran into this same issue when trying to use a t4g.nano. Here's a Claude-assisted summary:

Summary

nitro-tpm-attest hardcodes const SIZE: usize = 8192 for its NV message buffer. On smaller instance types (t3, t4g), the NitroTPM reports TPM2_PT_NV_INDEX_MAX = 0x800 (2048), so nv_define_space fails with TPM_RC_SIZE (0x2d5).

AWS docs list t3 and t4g as NitroTPM-supported, but attestation is non-functional on these instances.

Test results (us-east-1, 2026-02-12)

AMI: AL2023 arm64, registered with --tpm-support v2.0 --boot-mode uefi
Packages: aws-nitro-tpm-tools-1.1.0-1.amzn2023.aarch64, tpm2-tss-4.0.2-1.amzn2023.0.1.aarch64

Instance	Arch	NV_INDEX_MAX	Firmware	nitro-tpm-attest
t3.small	x86_64	0x800 (2048)	0x20191023	FAIL (0x2d5) (#7)
t4g.nano	arm64	0x800 (2048)	0x20191023	FAIL (0x2d5)
t4g.micro	arm64	0x800 (2048)	0x20191023	FAIL (0x2d5)
m5.large	x86_64	0x2000 (8192)	0x20191023	SUCCESS (5165 bytes)
c7g.medium	arm64	0x2000 (8192)	0x20191023	SUCCESS

All report AMZN NitroTPM v1.0 with identical firmware version. The NV_INDEX_MAX differs per instance family — burstable instances (t3, t4g) get 2048, non-burstable (m5, c7g) get 8192.

We also confirmed:

• /dev/tpmrm0 via TPM_DEVICE env var: same error (NV_INDEX_MAX is per-TPM, not per-device)
• Manually defining a 2048-byte NV index works — only the 8192-byte allocation fails
• The attestation response is ~5 KiB, so even a 2048-byte NV index wouldn't hold it

Error output

WARNING:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:345:Esys_NV_DefineSpace_Finish() Received TPM Error
ERROR:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:121:Esys_NV_DefineSpace() Esys Finish ErrorCode (0x000002d5)
Error: structure is the wrong size (associated with parameter number 2)

Caused by:
    0: structure is the wrong size (associated with parameter number 2)
    1: Response code value: 0x2d5

Root cause

MessageBuffer::from_request allocates 8192 bytes via NvPublic::builder().with_data_area_size(SIZE). The TPM rejects this because 8192 > NV_INDEX_MAX (2048 on Graviton2).

The vendor command (TPM2_VENDOR_AWS_NSM_REQUEST = 0x20000001) uses a single NV index as the sole IPC channel — the firmware reads the request from it and writes the ~5 KiB response back. There is no multi-index or chunking support, so this cannot be worked around externally.

Steps to reproduce

Stock AL2023 AMIs do not have TpmSupport set. Create a TPM-enabled AMI, then launch a t4g instance:

# 1. Create a TPM-enabled AMI from stock AL2023
REGION=us-east-1

AL2023_AMI=$(aws ssm get-parameter --region "$REGION" \
  --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-arm64 \
  --query 'Parameter.Value' --output text)

SNAP_ID=$(aws ec2 describe-images --region "$REGION" --image-ids "$AL2023_AMI" \
  --query 'Images[0].BlockDeviceMappings[0].Ebs.SnapshotId' --output text)

MY_SNAP=$(aws ec2 copy-snapshot --region "$REGION" \
  --source-region "$REGION" --source-snapshot-id "$SNAP_ID" \
  --description "AL2023 arm64 for TPM test" --query 'SnapshotId' --output text)

aws ec2 wait snapshot-completed --region "$REGION" --snapshot-ids "$MY_SNAP"

TPM_AMI=$(aws ec2 register-image --region "$REGION" \
  --name "al2023-arm64-tpm-test-$(date +%Y%m%d)" \
  --architecture arm64 \
  --root-device-name /dev/xvda \
  --block-device-mappings "[{\"DeviceName\":\"/dev/xvda\",\"Ebs\":{\"SnapshotId\":\"$MY_SNAP\",\"VolumeType\":\"gp3\",\"VolumeSize\":8,\"DeleteOnTermination\":true}}]" \
  --virtualization-type hvm --ena-support \
  --boot-mode uefi --tpm-support v2.0 \
  --query 'ImageId' --output text)

# 2. Launch a t4g instance with SSM access and packages pre-installed
aws ec2 run-instances --region "$REGION" \
  --image-id "$TPM_AMI" \
  --instance-type t4g.nano \
  --subnet-id <your-subnet> \
  --security-group-ids <your-sg> \
  --iam-instance-profile Name=<ssm-enabled-role> \
  --associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=tpm-nv-test}]' \
  --user-data '#!/bin/bash
set -ex
dnf install -y amazon-ssm-agent aws-nitro-tpm-tools tpm2-tools openssl
systemctl enable amazon-ssm-agent
systemctl start amazon-ssm-agent
'

# 3. Once SSM is connected, run via SSM or SSH:

# Confirm the NV limit
tpm2_getcap properties-fixed | grep -A1 NV_INDEX_MAX
# On t4g (Graviton2): raw: 0x800   (2048 — fails)
# On c7g (Graviton3): raw: 0x2000  (8192 — works)

# Generate a DER-encoded RSA-2048 public key
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -outform DER -out /tmp/key.der
openssl pkey -in /tmp/key.der -inform DER -pubout -outform DER -out /tmp/pub.der

# Attempt attestation
nitro-tpm-attest --public-key /tmp/pub.der
# On t4g: Esys_NV_DefineSpace() Esys Finish ErrorCode (0x000002d5)
# On c7g: outputs raw CBOR attestation document to stdout

Suggested fix

Since the firmware version is identical across affected and working instances, and only the NV_INDEX_MAX differs, increasing the NV_INDEX_MAX to 8192 on affected platforms (t3, t4g, etc.) would resolve this without any tool changes.

As a minimum improvement, the tool should query TPM2_PT_NV_INDEX_MAX before calling nv_define_space and produce a clear error instead of the raw ESAPI error.

Impact

NitroTPM attestation is non-functional on t3 and t4g instance families despite being listed as supported. This affects any workflow using nitro-tpm-attest, including KMS attested decryption with RecipientInfo.