| Message ID | 20220527173058.226210-1-stefanb@linux.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | backend/tpm: Resolve issue with TPM 2 DA lockout | expand |
Hi On Fri, May 27, 2022 at 7:36 PM Stefan Berger <stefanb@linux.ibm.com> wrote: > > This series of patches resolves an issue with a TPM 2's dictionary attack > lockout logic being triggered upon well-timed VM resets. Normally, the OS > TPM driver sends a TPM2_Shutdown to the TPM 2 upon reboot and before a VM > is reset. However, the OS driver cannot do this when the user resets a VM. > In this case QEMU must send the command because otherwise several well- > timed VM resets will trigger the TPM 2's dictionary attack (DA) logic and > it will then refuse to do certain key-related operations until the DA > logic has timed out. How does real hardware deal with that situation? Shouldn't this "shutdown"/reset logic be implemented on swtpm side instead, when CMD_INIT is received? (when the VM is restarted) > > Regards, > Stefan > > Stefan Berger (2): > backends/tpm: Record the last command sent to the TPM > backends/tpm: Send TPM2_Shutdown upon VM reset > > backends/tpm/tpm_emulator.c | 44 +++++++++++++++++++++++++++++++++++++ > backends/tpm/tpm_int.h | 3 +++ > backends/tpm/tpm_util.c | 9 ++++++++ > backends/tpm/trace-events | 1 + > include/sysemu/tpm_util.h | 3 +++ > 5 files changed, 60 insertions(+) > > -- > 2.35.3 >
On 5/27/22 15:24, Marc-André Lureau wrote: > Hi > > On Fri, May 27, 2022 at 7:36 PM Stefan Berger <stefanb@linux.ibm.com> wrote: >> >> This series of patches resolves an issue with a TPM 2's dictionary attack >> lockout logic being triggered upon well-timed VM resets. Normally, the OS >> TPM driver sends a TPM2_Shutdown to the TPM 2 upon reboot and before a VM >> is reset. However, the OS driver cannot do this when the user resets a VM. >> In this case QEMU must send the command because otherwise several well- >> timed VM resets will trigger the TPM 2's dictionary attack (DA) logic and >> it will then refuse to do certain key-related operations until the DA >> logic has timed out. > > How does real hardware deal with that situation? Shouldn't this > "shutdown"/reset logic be implemented on swtpm side instead, when > CMD_INIT is received? (when the VM is restarted) I don't know what real hardware can actually do when the machine is reset, presumably via some reset line, or the power is removed. Probably it has no way to react to this. Typically the OS driver has to send the command and since it cannot do this I would defer it to the TPM emulator reset handler code, so the next layer down. > >> >> Regards, >> Stefan >> >> Stefan Berger (2): >> backends/tpm: Record the last command sent to the TPM >> backends/tpm: Send TPM2_Shutdown upon VM reset >> >> backends/tpm/tpm_emulator.c | 44 +++++++++++++++++++++++++++++++++++++ >> backends/tpm/tpm_int.h | 3 +++ >> backends/tpm/tpm_util.c | 9 ++++++++ >> backends/tpm/trace-events | 1 + >> include/sysemu/tpm_util.h | 3 +++ >> 5 files changed, 60 insertions(+) >> >> -- >> 2.35.3 >> >
On 5/27/22 15:31, Stefan Berger wrote: > > > On 5/27/22 15:24, Marc-André Lureau wrote: >> Hi >> >> On Fri, May 27, 2022 at 7:36 PM Stefan Berger <stefanb@linux.ibm.com> >> wrote: >>> >>> This series of patches resolves an issue with a TPM 2's dictionary >>> attack >>> lockout logic being triggered upon well-timed VM resets. Normally, >>> the OS >>> TPM driver sends a TPM2_Shutdown to the TPM 2 upon reboot and before >>> a VM >>> is reset. However, the OS driver cannot do this when the user resets >>> a VM. >>> In this case QEMU must send the command because otherwise several well- >>> timed VM resets will trigger the TPM 2's dictionary attack (DA) logic >>> and >>> it will then refuse to do certain key-related operations until the DA >>> logic has timed out. >> >> How does real hardware deal with that situation? Shouldn't this >> "shutdown"/reset logic be implemented on swtpm side instead, when >> CMD_INIT is received? (when the VM is restarted) > I don't know what real hardware can actually do when the machine is > reset, presumably via some reset line, or the power is removed. Probably > it has no way to react to this. > > Typically the OS driver has to send the command and since it cannot do > this I would defer it to the TPM emulator reset handler code, so the > next layer down. Also, when this is done in QEMU we don't need to do a data channel operation (run TPM2_Shutdown) from within the control channel (upon CMD_INIT) inside of swtpm. This way we can deal with it properly. The usage model for the TPM 2 prescribes that a TPM2_Shutdown must be sent before a shutdown or reset of the system, so let's let QEMU do it if the OS cannot do it. > > > >> >>> >>> Regards, >>> Stefan >>> >>> Stefan Berger (2): >>> backends/tpm: Record the last command sent to the TPM >>> backends/tpm: Send TPM2_Shutdown upon VM reset >>> >>> backends/tpm/tpm_emulator.c | 44 +++++++++++++++++++++++++++++++++++++ >>> backends/tpm/tpm_int.h | 3 +++ >>> backends/tpm/tpm_util.c | 9 ++++++++ >>> backends/tpm/trace-events | 1 + >>> include/sysemu/tpm_util.h | 3 +++ >>> 5 files changed, 60 insertions(+) >>> >>> -- >>> 2.35.3 >>> >>
Hi On Sat, May 28, 2022 at 7:23 PM Stefan Berger <stefanb@linux.ibm.com> wrote: > > > > On 5/27/22 15:31, Stefan Berger wrote: > > > > > > On 5/27/22 15:24, Marc-André Lureau wrote: > >> Hi > >> > >> On Fri, May 27, 2022 at 7:36 PM Stefan Berger <stefanb@linux.ibm.com> > >> wrote: > >>> > >>> This series of patches resolves an issue with a TPM 2's dictionary > >>> attack > >>> lockout logic being triggered upon well-timed VM resets. Normally, > >>> the OS > >>> TPM driver sends a TPM2_Shutdown to the TPM 2 upon reboot and before > >>> a VM > >>> is reset. However, the OS driver cannot do this when the user resets > >>> a VM. > >>> In this case QEMU must send the command because otherwise several well- > >>> timed VM resets will trigger the TPM 2's dictionary attack (DA) logic > >>> and > >>> it will then refuse to do certain key-related operations until the DA > >>> logic has timed out. > >> > >> How does real hardware deal with that situation? Shouldn't this > >> "shutdown"/reset logic be implemented on swtpm side instead, when > >> CMD_INIT is received? (when the VM is restarted) > > I don't know what real hardware can actually do when the machine is > > reset, presumably via some reset line, or the power is removed. Probably > > it has no way to react to this. > > > > Typically the OS driver has to send the command and since it cannot do > > this I would defer it to the TPM emulator reset handler code, so the > > next layer down. > > Also, when this is done in QEMU we don't need to do a data channel > operation (run TPM2_Shutdown) from within the control channel (upon > CMD_INIT) inside of swtpm. This way we can deal with it properly. The > usage model for the TPM 2 prescribes that a TPM2_Shutdown must be sent > before a shutdown or reset of the system, so let's let QEMU do it if the > OS cannot do it. What if qemu is killed or crashed, and a new instance is connected to swtpm? Or more subtle, the VM reboots without qemu help (no reset handler). It feels like it would be more robust to handle the situation in swtpm. Why not have the same last operation tracking and shutdown logic there? If CMD_INIT is received and the last operation is not shutdown, I'd have a warning and do it (if this is compliant with the spec, I am trying to find relevant text). > > > > > > > > >> > >>> > >>> Regards, > >>> Stefan > >>> > >>> Stefan Berger (2): > >>> backends/tpm: Record the last command sent to the TPM > >>> backends/tpm: Send TPM2_Shutdown upon VM reset > >>> > >>> backends/tpm/tpm_emulator.c | 44 +++++++++++++++++++++++++++++++++++++ > >>> backends/tpm/tpm_int.h | 3 +++ > >>> backends/tpm/tpm_util.c | 9 ++++++++ > >>> backends/tpm/trace-events | 1 + > >>> include/sysemu/tpm_util.h | 3 +++ > >>> 5 files changed, 60 insertions(+) > >>> > >>> -- > >>> 2.35.3 > >>> > >> >
On 5/30/22 03:49, Marc-André Lureau wrote: > Hi > > On Sat, May 28, 2022 at 7:23 PM Stefan Berger <stefanb@linux.ibm.com> wrote: >> >> >> >> On 5/27/22 15:31, Stefan Berger wrote: >>> >>> >>> On 5/27/22 15:24, Marc-André Lureau wrote: >>>> Hi >>>> >>>> On Fri, May 27, 2022 at 7:36 PM Stefan Berger <stefanb@linux.ibm.com> >>>> wrote: >>>>> >>>>> This series of patches resolves an issue with a TPM 2's dictionary >>>>> attack >>>>> lockout logic being triggered upon well-timed VM resets. Normally, >>>>> the OS >>>>> TPM driver sends a TPM2_Shutdown to the TPM 2 upon reboot and before >>>>> a VM >>>>> is reset. However, the OS driver cannot do this when the user resets >>>>> a VM. >>>>> In this case QEMU must send the command because otherwise several well- >>>>> timed VM resets will trigger the TPM 2's dictionary attack (DA) logic >>>>> and >>>>> it will then refuse to do certain key-related operations until the DA >>>>> logic has timed out. >>>> >>>> How does real hardware deal with that situation? Shouldn't this >>>> "shutdown"/reset logic be implemented on swtpm side instead, when >>>> CMD_INIT is received? (when the VM is restarted) >>> I don't know what real hardware can actually do when the machine is >>> reset, presumably via some reset line, or the power is removed. Probably >>> it has no way to react to this. >>> >>> Typically the OS driver has to send the command and since it cannot do >>> this I would defer it to the TPM emulator reset handler code, so the >>> next layer down. >> >> Also, when this is done in QEMU we don't need to do a data channel >> operation (run TPM2_Shutdown) from within the control channel (upon >> CMD_INIT) inside of swtpm. This way we can deal with it properly. The >> usage model for the TPM 2 prescribes that a TPM2_Shutdown must be sent >> before a shutdown or reset of the system, so let's let QEMU do it if the >> OS cannot do it. > > What if qemu is killed or crashed, and a new instance is connected to > swtpm? Or more subtle, the VM reboots without qemu help (no reset > handler). It feels like it would be more robust to handle the > situation in swtpm. Why not have the same last operation tracking and > shutdown logic there? If CMD_INIT is received and the last operation > is not shutdown, I'd have a warning and do it (if this is compliant > with the spec, I am trying to find relevant text). Something to test with: https://github.com/stefanberger/swtpm/pull/701 > > >> >>> >>> >>> >>>> >>>>> >>>>> Regards, >>>>> Stefan >>>>> >>>>> Stefan Berger (2): >>>>> backends/tpm: Record the last command sent to the TPM >>>>> backends/tpm: Send TPM2_Shutdown upon VM reset >>>>> >>>>> backends/tpm/tpm_emulator.c | 44 +++++++++++++++++++++++++++++++++++++ >>>>> backends/tpm/tpm_int.h | 3 +++ >>>>> backends/tpm/tpm_util.c | 9 ++++++++ >>>>> backends/tpm/trace-events | 1 + >>>>> include/sysemu/tpm_util.h | 3 +++ >>>>> 5 files changed, 60 insertions(+) >>>>> >>>>> -- >>>>> 2.35.3 >>>>> >>>> >> >