(In reply to John Ferlan from comment #0)
> Let's "officially" drop 1.2 support, for some more details/context see:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1967919#c11 
> 
> should just require adding --without-tpm12

Reading that bug doesn't give me confidence that dropping TPM 1.2 support has been fully thought through or is reasonable.

IIUC, the bug is triggered by RHEL OS team wanting to remove TPM 1.2 support from RHEL-9. 

This is fine, but in terms of implications for virtualization, this is *guest OS* context, so it doesn't follow that we should automatically remove TPM 1.2 from the virtualization *host* context.

ie it merely means that when running a RHEL-9 guest on KVM, we do not need to expose TPM 1.2 to it. 

RHEL virtualization, however, supports many guest OS including RHEL-6, RHEL-7, RHEL-8, Windows and those can't be assumed to have TPM 2 support. eg from what I can tell RHEL-7 did not initially ship with TPM 2 support, and later enablement was tech preview:

  https://access.redhat.com/solutions/253363

But vTPM 1.2 has never been officially supported on RHEL (only the CRB+2.0+uefi combo on x86, TIS+2.0+uefi on aarch, tpm-spapr for ppc).

The big reason to remove TPM 1.2 is that it is inherently and tightly connected to SHA-1. You can't provide TPM 1.2 without supporting SHA-1, and you can't use any other hash function even if you wanted.

Given that SHA-1 is insecure, it is not possible to provide a TPM 1.2 module that's still trustworthy. So a TPM 1.2 provided to the guest context does not provide additional security.

(In reply to Hubert Kario from comment #3)
> The big reason to remove TPM 1.2 is that it is inherently and tightly
> connected to SHA-1. You can't provide TPM 1.2 without supporting SHA-1, and
> you can't use any other hash function even if you wanted.
> 
> Given that SHA-1 is insecure, it is not possible to provide a TPM 1.2 module
> that's still trustworthy. So a TPM 1.2 provided to the guest context does
> not provide additional security.

The situation appears to be rather more nuanced than just "SHA-1 is insecure". According to this document:

  https://trustedcomputinggroup.org/wp-content/uploads/SHA1-Impact_V2.0.pdf

only the RSA signature feature has its security compromised by the use of SHA1, while other features are claimed to not be susceptible to collision attacks due to lack of user controllable inputs.

"To currently published attacks" is a key phrase here, and attacks only get better.

*** Bug 1991494 has been marked as a duplicate of this bug. ***

IIUC,  EDK2 also has TPM support of some kind and we appear to enable that in our RHEL builds. So we should also consider whether this bug implies corresponding work in EDK2

About edk2, it would make sense too, to get rid of "dead" code.

Regarding libtpms & swtpm, I would rather have them rebased to the upcoming releases, since there is no reliable way to figure out which version is supported before we introduced the new capabilities in 0.7.

Current version would --print-capabilities:
{ "type": "swtpm", "features": [ "cap-x", ... ] }

(no indication about what TPM versions are supported, it will fail at run time eventually)

And upcoming 0.7:
{ "type": "swtpm", "features": [ "tpm-1.2", "tpm-2.0", "cap-x", ... ], "version": "0.7.0" }

Verify with:
swtpm-0.7.0-1.20211109gitb79fd91.el9.x86_64
libtpms-0.9.0-0.20211004gitdc4e3f6313.el9.x86_64
libvirt-7.9.0-1.el9.x86_64
qemu-kvm-6.1.0-6.el9.x86_64
edk2-ovmf-20210527gite1999b264f1f-7.el9.noarch
kernel-5.14.0-15.el9.x86_64

Steps:
1.Start guest with tpm1.2, same steps and result as bz1990152#c12.

2.Capabilities, no tpm-1.2:
# swtpm_setup --print-capabilities
{ "type": "swtpm_setup", "features": [ "tpm-2.0", "cmdarg-keyfile-fd", "cmdarg-pwdfile-fd", "tpm12-not-need-root", "cmdarg-write-ek-cert-files", "cmdarg-create-config-files", "cmdarg-reconfigure-pcr-banks", "tpm2-rsa-keysize-2048", "tpm2-rsa-keysize-3072" ], "version": "0.7.0" }
# swtpm socket --print-capabilities
{ "type": "swtpm", "features": [ "tpm-2.0", "tpm-send-command-header", "flags-opt-startup", "cmdarg-seccomp", "cmdarg-key-fd", "cmdarg-pwd-fd", "cmdarg-print-states", "nvram-backend-dir", "nvram-backend-file" ], "version": "0.7.0" }

3.Help and man page:
(a)swtpm_setup
# swtpm_setup --help|grep tpm
--tpm2           : Setup a TPM 2; by default a TPM 1.2 is setup.
man swtpm_setup
       --tpm2
           Do setup on a TPM 2; by default a TPM 1.2 is setup.
(b)swtpm socket
Swtpm socket --help
--tpm2           : choose TPM2 functionality
man swtpm socket
       --tpm2
           Choose TPM 2 functionality; by default a TPM 1.2 is chosen.

4. Try to run cmds with tpm1.2( by not specifying the version, use default)
# swtpm_setup  --tpmstate /tmp/mytpm --create-ek-cert --create-platform-cert --overwrite
swtpm at /usr/bin/swtpm does not support TPM 1.2

# /usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/tmp/guest-swtpm.sock,mode=0600 --tpmstate dir=/tmp/mytpm,mode=0600 
swtpm: Error: Could not choose TPM version.



Reproduce and comparison:
(Downgrade to  libtpms-0.8.2-0.20210301git729fc6a4ca.el9.7.x86_64)
Steps:
1.capabilities, has tpm-1.2 support:
# swtpm_setup --print-capabilities
{ "type": "swtpm_setup", "features": [ "tpm-1.2", "tpm-2.0", "cmdarg-keyfile-fd", "cmdarg-pwdfile-fd", "tpm12-not-need-root", "cmdarg-write-ek-cert-files", "cmdarg-create-config-files", "cmdarg-reconfigure-pcr-banks", "tpm2-rsa-keysize-2048", "tpm2-rsa-keysize-3072" ], "version": "0.7.0" }
# swtpm socket --print-capabilities
{ "type": "swtpm", "features": [ "tpm-1.2", "tpm-2.0", "tpm-send-command-header", "flags-opt-startup", "cmdarg-seccomp", "cmdarg-key-fd", "cmdarg-pwd-fd", "cmdarg-print-states", "nvram-backend-dir", "nvram-backend-file" ], "version": "0.7.0" }

2.Run cmds with tpm1.2 succeed:
(a)swtpm_setup
# swtpm_setup  --tpmstate /tmp/mytpm --create-ek-cert --create-platform-cert --overwrite
Starting vTPM manufacturing as root:root @ Thu 18 Nov 2021 03:24:07 AM EST
TPM is listening on Unix socket.
…
… -tpm-spec-family 1.2 …
...
Ending vTPM manufacturing @ Thu 18 Nov 2021 03:24:08 AM EST
(b)swtpm socket
 /usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/tmp/guest-swtpm.sock,mode=0600 --tpmstate dir=/tmp/mytpm,mode=0600 
# echo $?
0
# ps aux|grep swtpm
root       11114  0.0  0.0  10288  2000 ?        S    03:33   0:00 /usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/tmp/guest-swtpm.sock,mode=0600 --tpmstate dir=/tmp/mytpm,mode=0600

Hi Marc-Andre,

I met some issues when verify in comment13, could you help check please?
1. From the verify steps3-4, tpm1.2 is still the default version. Need it be changed?
2. In step4, could the error msg of 'swtpm socket' be improved to indicate tpm1.2 is not supported? Since its man page says it uses tpm1.2 as default. Or it's another error due to no version used?
3. In swtpm logs there're process output, swtpm cmds are not logged. If I use libvirt to start a vm instead of directly run swtpm cmds, I can not know what cmds and options are used in vm-swtpm.log. Is there anywhere you know to find this info please?

Thank you!

(In reply to yanqzhan from comment #14)
> Hi Marc-Andre,
> 
> I met some issues when verify in comment13, could you help check please?
> 1. From the verify steps3-4, tpm1.2 is still the default version. Need it be
> changed?

No, that would change the default behavior.

> 2. In step4, could the error msg of 'swtpm socket' be improved to indicate
> tpm1.2 is not supported? Since its man page says it uses tpm1.2 as default.
> Or it's another error due to no version used?

Yes, the error message could be improved to state which version was requested and unsupported. Would you open a bug for upstream?

> 3. In swtpm logs there're process output, swtpm cmds are not logged. If I
> use libvirt to start a vm instead of directly run swtpm cmds, I can not know
> what cmds and options are used in vm-swtpm.log. Is there anywhere you know
> to find this info please?

The daemon command is logged with the VM log.

The swtpm_setup is logged with libvirtd log. You need to enable debug logging:
2021-11-18 10:51:35.605+0000: 295091: debug : virCommandRunAsync:2625 : About to run /usr/local/bin/swtpm_setup --tpm2 --tpm-state /var/lib/libvirt/swtpm/9919ddaa-e7da-4002-bc37-dbc7cb20bec3/tpm2 --vmid vm1:9919ddaa-e7da-4002-bc37-dbc7cb20bec3 --logfile /var/log/swtpm/libvirt/qemu/vm1-swtpm.log --createek --create-ek-cert --create-platform-cert --lock-nvram --not-overwrite
2021-11-18 10:51:35.606+0000: 295091: debug : virCommandRunAsync:2627 : Command result 0, with PID 295341
2021-11-18 10:51:35.693+0000: 295091: debug : virCommandRun:2471 : Result exit status 0, stdout: 'TPM is listening on Unix socket.

(In reply to Marc-Andre Lureau from comment #15)
Ok. Thank you !

1. Ok.

2. I can not reproduce on fc35, so I filed one against rhel9: bz2024583.
Seems fc35 still support tpm12:
# rpm -q swtpm libtpms
swtpm-0.7.0-1.20211109gitb79fd91.fc35.x86_64
libtpms-0.9.0-0.20211004gitdc4e3f6313.fc35.0.x86_64
# swtpm socket --print-capabilities
{ "type": "swtpm", "features": [ "tpm-1.2", "tpm-2.0", "tpm-send-command-header", "flags-opt-startup", "cmdarg-seccomp", "cmdarg-key-fd", "cmdarg-pwd-fd", "cmdarg-print-states", "nvram-backend-dir", "nvram-backend-file" ], "version": "0.7.0" }
# /usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/tmp/guest-swtpm.sock,mode=0600 --tpmstate dir=/tmp/mytpm,mode=0600 
# echo $?
0

3. Yes, sorry I forgot it.



Then mark this bug as verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: swtpm), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:2436