What slightly puzzles me is the empty /var/lib/swtpm-localca dir
I created a new guest to see if that behaves different than the one used before.
Indeed it behaves differently.
swtpm log on guest that existed before:
Starting vTPM manufacturing as tss:tss @ Mon 15 Nov 2021 01:38:53 PM UTC
Successfully created RSA 2048 EK with handle 0x81010001.
Invoking /usr/lib/x86_64-linux-gnu/swtpm/swtpm-localca --type ek --ek df06f941e4c58e2c043407c1eb2a5afa6825ee93362ebe33e8ada87986bd04bb356ee64d02625f9cb234bf13afbd4d5e93456ad24dccd1b3083b063d4098573045dd1f8c73ee1ca8860f2f5f211ccd6336774388202099dd6117e38ebe162a34e7af024f6eac15c9683979ef4f4fbe5bda39284d209bfe32897ad87df062382e3ce6a070cfbc325223d6e12f366bb115fbadf78e66790d6e04f5d8f27f6e8ca431bb779fe8b67e6707ceb36de8540838f2acab6535fcf1739e7b51f22d4d774c17c1e56d86d64e52319d5303ab7c8e47303c359858ace7b282d6ff696930a595db20202884417fe19b00d2272966979bedc7c36e678fbaf26be84fdfa7059ddf --dir /var/lib/libvirt/swtpm/65113265-34d6-4358-b562-4d7508d6ff17/tpm2 --logfile /var/log/swtpm/libvirt/qemu/f-tpm-swtpm.log --vmid f-tpm:65113265-34d6-4358-b562-4d7508d6ff17 --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
Need read/write rights on statedir /var/lib/swtpm-localca for user tss.
swtpm-localca exit with status 256:
An error occurred. Authoring the TPM state failed.
Ending vTPM manufacturing @ Mon 15 Nov 2021 01:38:53 PM UTC
New guest:
$ sudo tail -f /var/log/swtpm/libvirt/qemu/f-tpm2-swtpm.log
Successfully created platform certificate locally.
Successfully created NVRAM area 0x1c00002 for RSA 2048 EK certificate.
Successfully created NVRAM area 0x1c08000 for platform certificate.
Successfully created ECC EK with handle 0x81010016.
Invoking /usr/lib/x86_64-linux-gnu/swtpm/swtpm-localca --type ek --ek x=58624b50e848bbf1f3797c4ef32343a7ddea7535a7b845276b0810e46e713b671fab5179d3c2a5ef9eb135f18384358b,y=f82f41b8299442346ffe62a9d7b2ea61768aeb9fba3427f7566978ce66618797a9a42ec14451555b1838a820d1e9cbae,id=secp384r1 --dir /var/lib/libvirt/swtpm/87cdb40d-cc2d-4389-b998-95f5e9084954/tpm2 --logfile /var/log/swtpm/libvirt/qemu/f-tpm2-swtpm.log --vmid f-tpm2:87cdb40d-cc2d-4389-b998-95f5e9084954 --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
Successfully created EK certificate locally.
Successfully created NVRAM area 0x1c00016 for ECC EK certificate.
Successfully activated PCR banks sha1,sha256 among sha1,sha256,sha384,sha512.
Successfully authored TPM state.
Ending vTPM manufacturing @ Mon 15 Nov 2021 02:12:48 PM UTC
And with the new guest now also localca is populated and all owned by swtpm.
/var/lib/swtpm-localca:
total 56
drwxr-x--- 2 swtpm root 4096 Nov 15 14:12 ./
drwxr-xr-x 49 root root 4096 Nov 15 14:05 ../
-rwxr-xr-x 1 swtpm swtpm 0 Nov 15 14:12 .lock.swtpm-localca*
-rw-r--r-- 1 swtpm swtpm 5531 Nov 15 14:12 01.pem
-rw-r--r-- 1 swtpm swtpm 1 Nov 15 14:12 certserial
-rw-r--r-- 1 swtpm swtpm 48 Nov 15 14:12 index.txt
-rw-r--r-- 1 swtpm swtpm 21 Nov 15 14:12 index.txt.attr
-rw-r--r-- 1 swtpm swtpm 0 Nov 15 14:12 index.txt.old
-rw-r--r-- 1 swtpm swtpm 5531 Nov 15 14:12 issuercert.pem
-rw-r--r-- 1 swtpm swtpm 3 Nov 15 14:12 serial
-rw-r--r-- 1 swtpm swtpm 3 Nov 15 14:12 serial.old
-rw-r----- 1 swtpm swtpm 2459 Nov 15 14:12 signkey.pem
-rw-r--r-- 1 swtpm swtpm 1468 Nov 15 14:12 swtpm-localca-rootca-cert.pem
-rw-r----- 1 swtpm swtpm 2459 Nov 15 14:12 swtpm-localca-rootca-privkey.pem
Again for 22.04 that seems all fine, swtpm didn't exist before and we release it
with swtpm as the default.
But for potential SRUs we need to be careful to not break things.
But that said the old guest still worked, just the log entires and
/var/lib/swtpm-localca was odd.
And the former content would have been from an unsupported source where we have
no guarantees how it worked anyway.
#3 Fresh install of the new version
This now has /var/lib/ swtpm-localca set to swtpm.
$ sudo ls -laF /var/lib/ swtpm-localca
total 8
drwxr-x--- 2 swtpm root 4096 Nov 15 14:05 ./
drwxr-xr-x 49 root root 4096 Nov 15 14:05 ../
Starting the guest works and ownership is correct:
$ sudo ls -laFR /var/log/ swtpm/libvirt/ qemu /run/libvirt/ qemu/swtpm /var/lib/ libvirt/ swtpm /var/lib/ swtpm-localca qemu/swtpm:
/run/libvirt/
total 4
drwxrwx--- 2 libvirt-qemu swtpm 80 Nov 15 14:06 ./
drwxr-xr-x 5 root root 180 Nov 15 14:06 ../
-rw-r--r-- 1 swtpm swtpm 5 Nov 15 14:06 6-f-tpm-swtpm.pid
srw------- 1 libvirt-qemu kvm 0 Nov 15 14:06 6-f-tpm-swtpm.sock=
/var/lib/ libvirt/ swtpm: 34d6-4358- b562-4d7508d6ff 17/
total 12
drwx--x--x 3 root root 4096 Nov 15 13:43 ./
drwxr-xr-x 8 root root 4096 Nov 15 13:38 ../
drwx--x--x 3 root root 4096 Nov 15 13:43 65113265-
/var/lib/ libvirt/ swtpm/65113265- 34d6-4358- b562-4d7508d6ff 17:
total 12
drwx--x--x 3 root root 4096 Nov 15 13:43 ./
drwx--x--x 3 root root 4096 Nov 15 13:43 ../
drwx------ 2 swtpm swtpm 4096 Nov 15 14:06 tpm2/
/var/lib/ libvirt/ swtpm/65113265- 34d6-4358- b562-4d7508d6ff 17/tpm2:
total 16
drwx------ 2 swtpm swtpm 4096 Nov 15 14:06 ./
drwx--x--x 3 root root 4096 Nov 15 13:43 ../
-rw-r----- 1 swtpm swtpm 0 Nov 15 14:06 .lock
-rw------- 1 swtpm swtpm 6098 Nov 15 14:06 tpm2-00.permall
/var/lib/ swtpm-localca:
total 8
drwxr-x--- 2 swtpm root 4096 Nov 15 14:05 ./
drwxr-xr-x 49 root root 4096 Nov 15 14:05 ../
/var/log/ swtpm/libvirt/ qemu:
total 16
drwx-wx--- 2 swtpm swtpm 4096 Nov 15 13:38 ./
drwx--x--x 3 root root 4096 Nov 15 13:38 ../
-rw-r--r-- 1 swtpm swtpm 4744 Nov 15 13:43 f-tpm-swtpm.log
Process as well
1 116 16253 1 20 0 7492 3776 - Ss ? 0:00 path=/run/ libvirt/ qemu/swtpm/ swtpm.sock, mode=0600 --tpmstate dir=/var/ lib/libvirt/ swtpm/65113265- b562-4d7508d6ff 17/tpm2, mode=0600 --log file=/var/ log/swtpm/ libvirt tpm-swtpm. log --tpm2 --pid file=/run/ libvirt/ qemu/swtpm/ 6-f-tpm- swtpm.pid
/usr/bin/swtpm socket --daemon --ctrl type=unixio,
6-f-tpm-
34d6-4358-
/qemu/f-
What slightly puzzles me is the empty /var/lib/ swtpm-localca dir
I created a new guest to see if that behaves different than the one used before.
Indeed it behaves differently.
swtpm log on guest that existed before:
Starting vTPM manufacturing as tss:tss @ Mon 15 Nov 2021 01:38:53 PM UTC x86_64- linux-gnu/ swtpm/swtpm- localca --type ek --ek df06f941e4c58e2 c043407c1eb2a5a fa6825ee93362eb e33e8ada87986bd 04bb356ee64d026 25f9cb234bf13af bd4d5e93456ad24 dccd1b3083b063d 4098573045dd1f8 c73ee1ca8860f2f 5f211ccd6336774 388202099dd6117 e38ebe162a34e7a f024f6eac15c968 3979ef4f4fbe5bd a39284d209bfe32 897ad87df062382 e3ce6a070cfbc32 5223d6e12f366bb 115fbadf78e6679 0d6e04f5d8f27f6 e8ca431bb779fe8 b67e6707ceb36de 8540838f2acab65 35fcf1739e7b51f 22d4d774c17c1e5 6d86d64e52319d5 303ab7c8e47303c 359858ace7b282d 6ff696930a595db 20202884417fe19 b00d2272966979b edc7c36e678fbaf 26be84fdfa7059d df --dir /var/lib/ libvirt/ swtpm/65113265- 34d6-4358- b562-4d7508d6ff 17/tpm2 --logfile /var/log/ swtpm/libvirt/ qemu/f- tpm-swtpm. log --vmid f-tpm:65113265- 34d6-4358- b562-4d7508d6ff 17 --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm- localca. conf --optsfile /etc/swtpm- localca. options swtpm-localca for user tss.
Successfully created RSA 2048 EK with handle 0x81010001.
Invoking /usr/lib/
Need read/write rights on statedir /var/lib/
swtpm-localca exit with status 256:
An error occurred. Authoring the TPM state failed.
Ending vTPM manufacturing @ Mon 15 Nov 2021 01:38:53 PM UTC
New guest:
$ sudo tail -f /var/log/ swtpm/libvirt/ qemu/f- tpm2-swtpm. log x86_64- linux-gnu/ swtpm/swtpm- localca --type ek --ek x=58624b50e848b bf1f3797c4ef323 43a7ddea7535a7b 845276b0810e46e 713b671fab5179d 3c2a5ef9eb135f1 8384358b, y=f82f41b829944 2346ffe62a9d7b2 ea61768aeb9fba3 427f7566978ce66 618797a9a42ec14 451555b1838a820 d1e9cbae, id=secp384r1 --dir /var/lib/ libvirt/ swtpm/87cdb40d- cc2d-4389- b998-95f5e90849 54/tpm2 --logfile /var/log/ swtpm/libvirt/ qemu/f- tpm2-swtpm. log --vmid f-tpm2: 87cdb40d- cc2d-4389- b998-95f5e90849 54 --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm- localca. conf --optsfile /etc/swtpm- localca. options sha384, sha512.
Successfully created platform certificate locally.
Successfully created NVRAM area 0x1c00002 for RSA 2048 EK certificate.
Successfully created NVRAM area 0x1c08000 for platform certificate.
Successfully created ECC EK with handle 0x81010016.
Invoking /usr/lib/
Successfully created EK certificate locally.
Successfully created NVRAM area 0x1c00016 for ECC EK certificate.
Successfully activated PCR banks sha1,sha256 among sha1,sha256,
Successfully authored TPM state.
Ending vTPM manufacturing @ Mon 15 Nov 2021 02:12:48 PM UTC
And with the new guest now also localca is populated and all owned by swtpm.
/var/lib/ swtpm-localca: localca* rootca- cert.pem rootca- privkey. pem
total 56
drwxr-x--- 2 swtpm root 4096 Nov 15 14:12 ./
drwxr-xr-x 49 root root 4096 Nov 15 14:05 ../
-rwxr-xr-x 1 swtpm swtpm 0 Nov 15 14:12 .lock.swtpm-
-rw-r--r-- 1 swtpm swtpm 5531 Nov 15 14:12 01.pem
-rw-r--r-- 1 swtpm swtpm 1 Nov 15 14:12 certserial
-rw-r--r-- 1 swtpm swtpm 48 Nov 15 14:12 index.txt
-rw-r--r-- 1 swtpm swtpm 21 Nov 15 14:12 index.txt.attr
-rw-r--r-- 1 swtpm swtpm 0 Nov 15 14:12 index.txt.old
-rw-r--r-- 1 swtpm swtpm 5531 Nov 15 14:12 issuercert.pem
-rw-r--r-- 1 swtpm swtpm 3 Nov 15 14:12 serial
-rw-r--r-- 1 swtpm swtpm 3 Nov 15 14:12 serial.old
-rw-r----- 1 swtpm swtpm 2459 Nov 15 14:12 signkey.pem
-rw-r--r-- 1 swtpm swtpm 1468 Nov 15 14:12 swtpm-localca-
-rw-r----- 1 swtpm swtpm 2459 Nov 15 14:12 swtpm-localca-
Again for 22.04 that seems all fine, swtpm didn't exist before and we release it swtpm-localca was odd.
with swtpm as the default.
But for potential SRUs we need to be careful to not break things.
But that said the old guest still worked, just the log entires and
/var/lib/
And the former content would have been from an unsupported source where we have
no guarantees how it worked anyway.