This bug has an owner, thus, it's been triaged. Changing status to "assigned".

I start to look into this bug today. Leave some notes and process here.

After some investigate, we can use
  tpm-manager verify_endorsement
or
  attestation_client verify_attestation --ek-only
to call AttestationService::VerifyTask [1].
However, it seems attestation use a protobuf db as cache which is located at
/mnt/stateful_partition/unencrypted/preserve/attestation.epb. I can not use VerifyEK to trigger TpmUtilityV2::GetEndorsementCertificate. If I deleted that db, attestation will refetched the EK cert and public key from tpm_managerd after restart it.

Then we can got log as following (I added some customized log and willing to create the other CL after this bug is fixed),

2018-10-11T11:32:12.210050+00:00 DEBUG attestationd[20640]: Get RSA EK certificate...
2018-10-11T11:32:12.210070+00:00 DEBUG attestationd[20640]: GetEndorsementCertificate
2018-10-11T11:32:12.212087+00:00 DEBUG tpm_managerd[11291]: Received method call request: org.chromium.TpmNvram.ReadSpace(ay)
2018-10-11T11:32:12.212112+00:00 DEBUG tpm_managerd[11291]: Dispatching DBus method call: ReadSpace
2018-10-11T11:32:12.212223+00:00 DEBUG tpm_managerd[11291]: ReadSpaceTask
2018-10-11T11:32:12.212331+00:00 DEBUG tpm_managerd[11291]: ReadPublicSync
2018-10-11T11:32:12.212366+00:00 DEBUG tpm_managerd[11291]: Command: ...ignored...
2018-10-11T11:32:12.247528+00:00 DEBUG tpm_managerd[11291]: Response: ...ignored...
2018-10-11T11:32:12.247853+00:00 DEBUG tpm_managerd[11291]: StartAuthSessionSync
2018-10-11T11:32:12.247917+00:00 DEBUG tpm_managerd[11291]: Command: ...ignored...
2018-10-11T11:32:12.996920+00:00 DEBUG tpm_managerd[11291]: Response: ...ignored...
2018-10-11T11:32:12.997064+00:00 DEBUG tpm_managerd[11291]: NV_ReadSync
2018-10-11T11:32:12.997120+00:00 DEBUG tpm_managerd[11291]: Command: ...ignored...
2018-10-11T11:32:13.077970+00:00 DEBUG tpm_managerd[11291]: Response: ...ignored...
2018-10-11T11:32:13.078357+00:00 DEBUG tpm_managerd[11291]: FlushContextSync
2018-10-11T11:32:13.078378+00:00 DEBUG tpm_managerd[11291]: Command: ...ignored...
2018-10-11T11:32:13.095530+00:00 DEBUG tpm_managerd[11291]: Response: ...ignored...


It seems that tpm_managerd really setup a AuthSession to fetch NVRAM. If I use tpm_manager_client and setup with empty password, I can fetch it successfully.

The next step I think I will investigate more about ReadSpaceTask implementation.

[1] https://cs.corp.google.com/chromeos_public/src/platform2/attestation/server/attestation_service.cc?type=cs&l=2171

Propose a CL here. https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1278568

For crbug/748435, we need to get the TPM ownership status for making read_space/write_space works under unowned status, so it have to issue a GetCapability command. The sent commands will be changed to the following after applying this CL.

2018-10-12T13:57:06.310388+00:00 DEBUG tpm_managerd[5605]: ReadSpaceTask
2018-10-12T13:57:06.310411+00:00 DEBUG tpm_managerd[5605]: NV_ReadPublicSync
2018-10-12T13:57:06.310427+00:00 DEBUG tpm_managerd[5605]: Command: ...ignored...
2018-10-12T13:57:06.339996+00:00 DEBUG tpm_managerd[5605]: Response: ...ignored...
2018-10-12T13:57:06.340057+00:00 DEBUG tpm_managerd[5605]: GetCapabilitySync
2018-10-12T13:57:06.340078+00:00 DEBUG tpm_managerd[5605]: Command: ...ignored...
2018-10-12T13:57:06.362686+00:00 DEBUG tpm_managerd[5605]: Response: ...ignored...
2018-10-12T13:57:06.363051+00:00 DEBUG tpm_managerd[5605]: NV_ReadSync
2018-10-12T13:57:06.363075+00:00 DEBUG tpm_managerd[5605]: Command: ...ignored...
2018-10-12T13:57:06.418759+00:00 DEBUG tpm_managerd[5605]: Response: ...ignored...

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/aa9faf2a7874224d38200925ab0076e02a4e08e2

commit aa9faf2a7874224d38200925ab0076e02a4e08e2
Author: Meng-Huan Yu <menghuan@google.com>
Date: Wed Oct 24 23:45:03 2018

tpm_manager: Allow read/write space with password auth session

In chromium:748435#c18, they can't use read/write when TPM is unowned
since the HMAC session can not be used at that time. Change to use
password auth session in that situation.

In chromium:819323, NULL password is well known and it's ok to use
password auth session.

In this CL, I re-write the flow of initialize HMAC session, and
make read/write_space command to use password auth session when
1. TPM is unowned or pre-owned
2. using NULL password as authorization value

BUG= chromium:748435 , chromium:819323 
TEST=unit tests; and following test when TPM is unowned
 # restart tpm_managerd with argument --v=2
 tpm_manager_client read_space --index=0x00C00000 --file=/tmp/bla

It can read EK cert successfully in unowned mode (chromium:748435)
and can see the log that tpm_managerd doesn't send StartAuthSession
(chromium:8193230)

Change-Id: I72ee9698a4f6033ecc841ca53393dda539dc860f
Reviewed-on: https://chromium-review.googlesource.com/1278568
Commit-Ready: Meng-Huan Yu <menghuan@chromium.org>
Tested-by: Meng-Huan Yu <menghuan@chromium.org>
Reviewed-by: Meng-Huan Yu <menghuan@chromium.org>

[add] https://crrev.com/aa9faf2a7874224d38200925ab0076e02a4e08e2/tpm_manager/server/nv_index_authenticator.h
[modify] https://crrev.com/aa9faf2a7874224d38200925ab0076e02a4e08e2/tpm_manager/server/tpm2_nvram_test.cc
[modify] https://crrev.com/aa9faf2a7874224d38200925ab0076e02a4e08e2/tpm_manager/server/tpm2_nvram_impl.cc
[modify] https://crrev.com/aa9faf2a7874224d38200925ab0076e02a4e08e2/tpm_manager/server/tpm2_nvram_impl.h

The CL is landed. Mark this bug as fixed.

Just move back the owner. Not sure about the who should be the owner in Fixed state, any convention in our group?