yahoo-eng-team team mailing list archive

[sean mooney <2118888@xxxxxxxxxxxxxxxxxx>]

** Also affects: nova/2025.1
   Importance: Undecided
       Status: New

** Also affects: nova/2024.1
   Importance: Undecided
       Status: New

** Also affects: nova/2024.2
   Importance: Undecided
       Status: New

** Also affects: nova/2025.2
   Importance: Undecided
       Status: In Progress

** Changed in: nova/2025.2
   Importance: Undecided => High

** Changed in: nova/2024.2
   Importance: Undecided => High

** Changed in: nova/2024.1
   Importance: Undecided => High

** Changed in: nova/2025.1
   Importance: Undecided => High

** Changed in: nova/2025.2
     Assignee: (unassigned) => Jonas Schäfer (ch-jssfr)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2118888

Title:
  vTPM data is silently lost on instance stop/start and other operations

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) 2024.1 series:
  New
Status in OpenStack Compute (nova) 2024.2 series:
  New
Status in OpenStack Compute (nova) 2025.1 series:
  New
Status in OpenStack Compute (nova) 2025.2 series:
  In Progress

Bug description:
  Description
  ===========
  VMs with vTPM have been supported for a while ([1] mentions the
  Victoria release). Upon enabling it recently for a customer, we
  noticed that on stop/start of a VM, the vTPM state got deleted.

  This was particularly painful because it involved the loss of
  Windows Bitlocker keys :-). While recovery is possible in this
  particular scenario using recovery keys, it is certainly unexpected.

     [1]: https://docs.openstack.org/nova/latest/admin/emulated-tpm.html

  Steps to reproduce
  ==================

  1. Set up vTPM according to [1].
  2. Spawn a Debian 12 VM
  3. log into the VM, then as root:
     a. apt-get install tpm2-tools
     b. echo "hello world" > data
     c. tpm2_nvdefine (should print: "nv-index: 0x1000000";
        adapt the next command if the index differs)
     d. tpm2_nvwrite 0x1000000 --input=data
     e. tpm2_nvread 0x1000000
        (this should print "hello world",
         followed by lots of NUL bytes)
     f. systemctl poweroff
  4. Restart the VM using openstack server start
  5. log in, then as root: tpm2_nvread 0x1000000

  Expected result
  ===============

  "hello world", followed by lots of NUL bytes.

  Actual result
  =============

  WARN: Reading full size of the NV index
  WARNING:esys:src/tss2-esys/api/Esys_NV_ReadPublic.c:309:Esys_NV_ReadPublic_Finish() Received TPM Error
  ERROR:esys:src/tss2-esys/esys_tr.c:243:Esys_TR_FromTPMPublic_Finish() Error NV_ReadPublic ErrorCode (0x0000018b)
  ERROR:esys:src/tss2-esys/esys_tr.c:398:Esys_TR_FromTPMPublic() Error TR FromTPMPublic ErrorCode (0x0000018b)
  ERROR: Esys_TR_FromTPMPublic(0x18B) - tpm:handle(1):the handle is not correct for the use
  ERROR: Invalid handle authorization.
  ERROR: Unable to run tpm2_nvread

  Environment
  ===========

  - This was tested on Nova from 2023.1 and 2024.1.
  - Code path via manual analysis confirmed in 2024.1

  Further notes
  =============

  A draft patch has already been submitted:
  https://review.opendev.org/c/openstack/nova/+/955657?usp=email

  Filing a bug report was requested there, so here we go.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/2118888/+subscriptions