papr_phy_at...reate_handle(9)

💅 papr_phy_attest_create_handle — the Kernel API Manual, but make it make sense 🎀

okay so bestie, we're in the Kernel API Manual, and today's main character is papr_phy_attest_create_handle. no cap, this one's a lil niche but it eats.

✨ NAME ✨

papr_phy_attest_create_handle — creates a fd-based handle so you can read the response for a given attestation command 🦋

🌸 SYNOPSIS 🌸

long papr_phy_attest_create_handle (struct papr_phy_attest_io_block
__user *ulc );

💖 ARGUMENTS 💖

• ulc — the attestation command, living in user memory 🫶. it literally defines the scope of data for the attestation command to retrieve. that's its whole job.

👑 DESCRIPTION 👑

so this is the handler for the PAPR_PHYSICAL_ATTESTATION_IOC_CREATE_HANDLE ioctl command. iconic behavior only.

it validates ulc and instantiates an immutable response "blob" for the attestation command ✨. that blob gets attached to a file descriptor for reading by user space, and the memory backing the blob is freed when the file is released. clean. no leaks. we love to see it 💅

and here's the part where it gets highkey smart: the entire requested response buffer for the attestation command retrieved by this call — plus all the necessary RTAS interactions — is performed before returning the fd to user space 🫡. this keeps the read handler simple, and it ensures the kernel can prevent interleaving ibm,physical-attestation call sequences. like, no interleaving. not on her watch. periodt.

🔥 RETURN 🔥

the installed fd number if it slays (successful), or -ve errno otherwise 😭

🌈 SEE ALSO 🌈

• the kernel file ./arch/powerpc/platforms/pseries/papr-phy-attest.c
• struct rtas_phy_attest_params(9)
• rtas_physical_attestation(9)
• phy_attest_sequence_begin(9)
• phy_attest_sequence_end(9)

and that's the whole vibe check 🧚💜 this one lives in ./arch/powerpc/platforms/pseries, dated October 2026 — see u at the next papr_phy_at...reate_handle(9) reading, bestie 🍓⭐