swtpm_ioctl(8)

🌸 NAME 🌸

okay so bestie, welcome to swtpm_ioctl (manual section 8, she's fancy) — it's literally the utility for sending control commands to swtpm 🫶

---

✨ SYNOPSIS ✨

swtpm_ioctl [COMMAND] [<device>]

---

💖 DESCRIPTION 💖

So swtpm_ioctl is a whole client tool for controlling the swtpm_cuse and swtpm TPM software emulators — like, the actual management of them: initialization, shutdown, all that ✨. Once the TPM has been initialized, you can send TPM commands to it. Main character energy, honestly.

🎀 heads up, bestie: you can set the environment variable SWTPM_IOCTL_BUFFERSIZE to the size of the buffer used for state blob transfer. If it's not set, the ioctl() interface gets used for transferring the state. This env var is primarily used for testing purposes — iykyk 👑

The following commands are supported:

🦋 Pick your device / connection first 🦋

• --tpm-device device — use the given device. You gotta give the full path to the character device, like for example /dev/vtpm-200. This option can be used instead of providing the device as the last parameter 💅
• --tcp server:port — connect to the given server and port; if no server is given, 127.0.0.1 is used; if port is not given, the default port 6545 is used 🌈
• --unix path — connect to the given UnixIO path 🦋

🎀 The actual commands 🎀

• -c — get the capability flags indicating which commands are supported 👑
• -i — send a hardware initialization signal to the swtpm_cuse/swtpm. Volatile state previously written by the TPM will be read and the file automatically delete 😭 (yes, that's what it does, don't @ me)
• -s — initiate a graceful shut down 🫶
• --stop — stop the swtpm_cuse/swtpm. Note that this does not shut it down! The -i command can again be sent to it. After a stop it's also possible to load TPM stateblobs into the TPM using the --load command ✨
• -e — get the tpmEstablished bit ⭐
• -r locality — reset the tpmEstablished bit using the given locality. Only localities 3 and 4 work. This operation will not permanently change the locality that was previously set using the -l option 💀
• -l locality — set the locality for the subsequent TPM commands 🎀
• -v — have the TPM write the volatile state to a file. Upon a TPM_Init (-i) the TPM state will be read and the TPM can then resume operation without further initialization 🔥
• -C — cancel an ongoing TPM command, bye 👋
• -h data — reset and extend PCR 17 with the hash of the given data. If data is the single character '-', then all data are read from stdin 🍓
• --save TPM state blob name filename — save the TPM state blob into the given file. Valid TPM state blob names are 'permanent', 'volatile', and 'savestate' 💖

🧚 note that this command can be executed at any time. However, to retrieve the latest volatile state, the -v command should have been run immediately before running this command. The savestate blob will only be returned if a TPM_SaveState command was executed in the TPM (TPM 1.2).

• --load TPM state blob name filename — load the given TPM state blob from the given file. Valid TPM state blob names are 'permanent', 'volatile', and 'savestate' 💜

🙈 note that this command can only be executed on a TPM that is shut down. To then start the TPM with the uploaded state, the -i command must be issued.

• -g — get configuration flags that for example indicate which keys (file encryption or migration key) are in use by the TPM 🔑
• --info flags — get information about the TPM implementation and its configuration in JSON format 🌈. The following values can be provided. All of the values can be or'ed (or added) together to get information about all of them in one query:
  • 0x1: information about the specification the TPM implementation followed
  • 0x2: information about the manufacturer, model and version of the TPM
  • 0x4: lists supported RSA and Camellia key sizes
  • 0x8: describes supported and enabled algorithms
  • 0x10: describes supported and enabled commands
  • 0x20: describes the active profile
  • 0x40: lists all built-in profiles
  • 0x80: describes supported attributes
• --lock-storage retries — lock the storage and retry a given number of times with 10ms delay in between. Locking the storage may be necessary to do after the state of the TPM has been migrated out and the lock on the storage has been released when the 'savestate' blob was received and now the storage should be locked again 🔒

---

🌈 EXAMPLE 🌈

Start swtpm on port 10000 for the control port and emulate a TPM 1.2 — slay:

#> swtpm socket --tpmstate dir=/tmp/myvtpm1 --log level=4 --ctrl type=tcp,port=10000 --server type=tcp,port=10001 --flags not-need-init

Get information about the TPM implementation in JSON 🦋:

#> swtpm_ioctl --tcp :10000 --info 1
{"TPMSpecification":{"family":"1.2","level":2,"revision":116}}
#> swtpm_ioctl --tcp :10000 --info 2
{"TPMAttributes":{"manufacturer":"id:00001014","version":"id:00740001","model":"swtpm"}}

Shut down the swtpm, bye bestie 👋:

#> swtpm_ioctl --tcp :10000 -s

---

👑 SEE ALSO 👑

swtpm_cuse — go read that one too, fr fr 📚

---

that's the whole page, bestie 💅 this cutie came from swtpm (source/version), dated 2026-08-23, and it lives in manual section swtpm_ioctl(8) — periodt 🎀✨