swtpm_setup use block device as it's state file

[liyang2018]

hello,everyone, swtpm_setup has already support block device as tpm state file. if so, how to use block device as tpm state file? thanks

[stefanberger]

swtpm_setup says this in the man page:

       --tpm-state <dir> or --tpmstate <dir>
           Path  where the TPM’s state will be written to; this is a mandatory argument.  Prefix with dir:// to use directory
           backend, or file:// to use linear file.

swtpm man page say this:

       --tpmstate dir=<dir>[,mode=<0...>]|backend-uri=<uri>
           Use the given path rather than using the environment variable TPM_PATH.

           If dir is specified, the TPM state files will be written to the dir with the given file mode bits. This value must
           be given as an octal number starting with a ’0’.  The default value is 0640.

           If   backend‐uri   is   specified,   the   TPM   state   data   will   be   stored   to   the   URI.     Currently
           backend-uri=dir://<path_to_dir>  and  backend-uri=file://<path_to_dir> are available. For ’dir://’, the URI should
           specify the path to the directory where files are stored. If path_to_dir starts  with  a  ’/’  then  the  path  is
           interpreted as an absolute path, otherwise it is a path relative to the current directory.  For ’file://’, the URI
           should  specify a single file or block device where TPM state will be stored. A blockdevice must exist already and
           be big enough to store all state. (since v0.7)

If you used file:// with swtpm_setup you have to use backend-uri=file:// with swtpm later on.

[liyang2018]

Thank you for your answer! according swtpm man page, i create a linear lv:

[root@localhost cloud]# lvcreate -L 2G lytest WARNING: ext3 signature detected on /dev/lytest/lvol0 at offset 1080. Wipe it? [y/n]: y Wiping ext3 signature on /dev/lytest/lvol0. Logical volume "lvol0" created.

but when i use swtpm_setup to initialize this lv as a tpmstate file, i get an error:

[root@localhost cloud]# swtpm_setup --tpmstate file:///dev/lytest/lvol0 --tpm2 --create-ek-cert --overwrite --create-platform-cert Error: file:///dev/lytest/lvol0 is not a directory that user root could access.

am I missing something? please help me.

[stefanberger]

What version of swtpm & swtpm_setup are you using?

[liyang2018]

sorry, it's my mistakes, swtpm* version: [root@localhost cloud]# swtpm_setup --version TPM emulator setup tool version 0.3.3

[root@localhost cloud]# swtpm --version TPM emulator version 0.3.3, Copyright (c) 2014 IBM Corp.

[root@localhost cloud]# rpm -qa|grep swtpm swtpm-0.3.3-7.oe2203sp3.x86_64 swtpm-libs-0.3.3-7.oe2203sp3.x86_64 swtpm-tools-0.3.3-7.oe2203sp3.x86_64

From the code point of view, block device are only supported after 0.7, and I make one based on the stable-0.8 branch. then it works:

[root@localhost x86_64]# swtpm_setup --version TPM emulator setup tool version 0.8.0

[root@localhost x86_64]# swtpm_setup --tpmstate file:///dev/lytest/lvol0 --tpm2 --create-ek-cert --overwrite --create-platform-cert

Starting vTPM manufacturing as root:root @ Thu 05 Sep 2024 11:06:22 AM CST
swtpm: Formatting 'file:///dev/lytest/lvol0' as new linear NVRAM store
TPM is listening on Unix socket.
Successfully created RSA 2048 EK with handle 0x81010001.
  Invoking /usr/bin/swtpm_localca --type ek --ek acdf542e81e576aa8db9e7223ae1e3b19294713425c3122bb5ecdbc81f5f50de3030b2a9b297e17b75d5589a476c3699109bb1a90ff980799470b3f067cd29e35c97d9f766dfe5714716d3ac5111a4cae32edeeb7b73e240f96c0aa380c201eb54e26ae85a48a0c33b733896b988bdc155ab2b80bbb5ffff1d17654696a348297c3bb07562a99761e9eab77049b5316a191e6357677d5ba19b0336ad019f07e6e835a9b0ece3db6630e9cd0aabe613cb76de630853541dd23e366eb1cecb42f2a9869bf3355b096257197c6e6f9e3cb866cc72d80f60fad9a950a01d8758df53cf1f98def341a4136075c7d7e25fe0ef767c80bd6a649a4b2d20820e74424eab --dir /tmp/swtpm_setup.certs.ORNHT2 --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: Creating root CA and a local CA's signing key and issuer cert.
swtpm_localca: Successfully created EK certificate locally.
  Invoking /usr/bin/swtpm_localca --type platform --ek acdf542e81e576aa8db9e7223ae1e3b19294713425c3122bb5ecdbc81f5f50de3030b2a9b297e17b75d5589a476c3699109bb1a90ff980799470b3f067cd29e35c97d9f766dfe5714716d3ac5111a4cae32edeeb7b73e240f96c0aa380c201eb54e26ae85a48a0c33b733896b988bdc155ab2b80bbb5ffff1d17654696a348297c3bb07562a99761e9eab77049b5316a191e6357677d5ba19b0336ad019f07e6e835a9b0ece3db6630e9cd0aabe613cb76de630853541dd23e366eb1cecb42f2a9869bf3355b096257197c6e6f9e3cb866cc72d80f60fad9a950a01d8758df53cf1f98def341a4136075c7d7e25fe0ef767c80bd6a649a4b2d20820e74424eab --dir /tmp/swtpm_setup.certs.ORNHT2 --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: 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/bin/swtpm_localca --type ek --ek x=6db89a76b0d8b65b62132fd884c00ac2a185b634992d922e7208c23b3045245c03063a69cc0433ddbf9854712488fa57,y=a69e0f5ea5bddbb052e52f060dd69b524267ca25804c73ac06101e89f8bb4579a70df66ebd07f715e0242edfa46acc17,id=secp384r1 --dir /tmp/swtpm_setup.certs.ORNHT2 --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: Successfully created EK certificate locally.
Successfully created NVRAM area 0x1c00016 for ECC EK certificate.
Successfully activated PCR banks sha256 among sha1,sha256,sha384,sha512.
Successfully authored TPM state.
Ending vTPM manufacturing @ Thu 05 Sep 2024 11:06:23 AM CST

Thanks you very much!

[stefanberger]

Thanks you very much!

You're welcome. We can probably close this issue now.