How to make changes in /etc/efi-measured-boot/config after installation

[rdmitry0911]

Hi guys, I've just installed efi-measured-boot on a proxmox vm with tpm2 enabled. Everything works fine, however, after installtion I noticed, that I made a mistake in /etc/efi-measured-boot/config file. I tried to fix it and start over, but I got this error

root@vps:~/efi-measured-boot# make step2
root...SUCCESS
arch...SUCCESS
no_separate_boot...SUCCESS
mounted_efi...SUCCESS
root_luks...SUCCESS
systemd_stub...SUCCESS
tpm...SUCCESS
tpm_futurepcr...SUCCESS
packages...SUCCESS
binaries...SUCCESS
cryptsetup_version...SUCCESS
Safety checks passed
0x1926001:
  name: 000b9636a06ec05a7c56aeea783e019cc5a3968d4cd433fd6bea808d415b67432753
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly: ownerwrite|nt=0x1|ownerread|no_da|written
    value: 0x12000222
  size: 8

Conflicting counter with invalid attributes at NV index 0x1926001 (value=0x12000222)
make: *** [Makefile:16: step2] Error 1

and it turned out I have to reset tpm database first. I tried to make a reset from inside the system, with tpm2_clear and tpm2_hierarchycontrol but it doesn't work. Only replacing a tpm2 state disk to a clear one helped. Is there any way to overcome this error and make changes in /etc/efi-measured-boot/config file without tpm state disk replacement? This would also provide a possibility to have several protected systems on one host.

Thank you -- dmitry

[squarooticus]

Did you try tpm2_nvundefine 0x1926001? That will evict the counter with that handle. I'm more curious why the given attributes differ from mine:

0x1926001:
  name: 000b9636a06ec05a7c56aeea783e019cc5a3968d4cd433fd6bea808d415b67432753
  hash algorithm:
    friendly: sha256
    value: 0xB
  attributes:
    friendly: ownerwrite|nt=0x1|ownerread|no_da|written
    value: 0x22020012
  size: 8

While the friendly attributes appear identical, the value is different. It's the value the code is looking for. It's possible that is not stable across implementations, but I thought the mapping from attributes to values was given by https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-Structures-01.38.pdf.

[squarooticus]

Anyway, I would just comment out the attribute check (which is there just to make sure someone didn't create a non-monotonic counter, which would defeat the downgrade protection) for now until we have a resolution to this.

[squarooticus]

Looking at the standard I referenced, bits 7-4 of the attribute should be equal to the NV type, which means the second to last hex digit should always be 1 (TPM_NT_COUNTER). The value of your counter's attribute has 2 (TPM_NV_BITS, a bit field) in that position. There are other problems, as well; when I try to define a counter with the hex representation of your attribute, I get this error:

~ > sudo tpm2_nvdefine 0x1926002 -C o -s 8 -a 0x12000222                                                                             09:06:47
WARNING:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:344:Esys_NV_DefineSpace_Finish() Received TPM Error
ERROR:esys:src/tss2-esys/api/Esys_NV_DefineSpace.c:122:Esys_NV_DefineSpace() Esys Finish ErrorCode (0x000002e1)
ERROR: Failed to define NV area at index 0x1926002
ERROR: Esys_NV_DefineSpace(0x2E1) - tpm:parameter(2):reserved bits not set to zero as required
ERROR: Failed to create NV index 0x1926002.
ERROR: Unable to run tpm2_nvdefine

I think something is wrong with the vTPM you're using to test.

[squarooticus]

Github should understand what "partially resolves" means. ;-)

[rdmitry0911]

I think something is wrong with the vTPM you're using to test.

I've got the same errors after tpm2_nvundefine 0x1926001 and make step2. There isn't much I can do with vTPM from proxmox. May be it is possible to do something from inside linux itself? However, in spite of the errors, the major functionality is not damaged. The system boots with automatic luks decryption from generated emboot.efi and asks for a password if I make any changes in emboot.efi Thank you for the glue. This is a kind of workaround that I can live with :)

[squarooticus]

Can't believe I didn't see this before: 0x12000222 is 0x22020012 in the wrong byte order. A quick web search brings up this ancient commit to tpm2-tools for an older command (tpm2_nvlist). I wonder if there was a regression somewhere along the line? I'm not sure what to do about this other than maybe check the friendly attributes rather than the value. Suggestions?

[rdmitry0911]

Suggestions?

I would also go along checking the friendly attributes way. And may be ask a question in tpm mail list and/or github

[squarooticus]

What version of tpm-tools do you have? Use tpm2_nvreadpublic -v.

[rdmitry0911]

What version of tpm-tools do you have? Use tpm2_nvreadpublic -v.

tool="tpm2_nvreadpublic" version="5.0" tctis="libtss2-tctildr" tcti-default=tcti-device