tpm_buf_append_name(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ NAME πŸŽ€

okay so bestie, this page is tpm_buf_append_name(9) from the Kernel API Manual, and it is literally about adding a handle area to the buffer ✨

tpm_buf_append_name β€” add a handle area to the buffer πŸ’…


🌸 SYNOPSIS 🌸

int tpm_buf_append_name (struct tpm_chip *chip , struct tpm_buf *buf ,
       u32 handle , u8 *name );

πŸ’… ARGUMENTS πŸ’…

  • chip β€” the TPM chip structure 🫢
  • buf β€” the buffer to be appended πŸŽ€
  • handle β€” the handle to be appended πŸ”₯
  • name β€” the name of the handle (may be NULL) 🌸

πŸ¦‹ DESCRIPTION πŸ¦‹

So, to compute session HMACs, we literally need to know the names of the objects that the handles point at πŸ‘‘

For most objects, this is simply the actual 4 byte handle or an empty buf β€” and in those cases name should be NULL πŸ’–

But for volatile objects, permanent objects, and NV areas, the name is defined as the hash β€” using the name algorithm, which should be set to sha256 β€” of the public area with the two byte algorithm id appended to it ✨ For those objects, the name pointer should point to this 🎯

If a name is required but name is NULL, then TPM2_ReadPublic gets called on the handle to obtain the name πŸ‘€

Like most tpm_buf operations, success is assumed β€” failure comes from an incorrect programming model and gets indicated by a kernel message πŸ’€

🚨 Heads up bestie: it ends the authorization session on failure 😭

🌈 SEE ALSO 🌈


mwah πŸ’‹ this iconic little page comes from ./drivers/char/tpm, dated October 2026, and it is still tpm_buf_append_name(9) β€” bye bestie, go slay those handles πŸ«ΆπŸ’–

πŸ“¦ where this page comes from