There is an alternative way to read tpm nvram. You can use "tpmc read <index> <size>". Works only with trunksd daemon not running, so 'stop trunksd/start trunksd' around it. 
If stopping trunksd is not acceptable, will probably need to add this functionality to trunks_send. Right now can be done with 'trunks_send raw' but requires putting together a raw tpm command and then parsing the response.

we can't do "stop trunksd" since chrome will be running in parallel and stopping trunksd may crash chrome.

Actually, there is also "tpm_manager_client read_space --index=<index> --file=<file>". It only outputs the results to a file, though. Still, it may be easier changing "tpm_manager_client read_space" to allow output to stdout than adding "tpm_send --nvread".

But need to verify that it works with the authorization it uses.

Seems not working for me?

localhost ~ # tpm_manager_client read_space --index=0x1007 --file=/tmp/blah
[INFO:main.cc(460)] Message Reply: [tpm_manager.ReadSpaceReply] {
  result: NVRAM_RESULT_DEVICE_ERROR
  data:
}

localhost ~ # tpm_manager_client read_space --index=$((0x1007)) --file=/tmp/blah
[INFO:main.cc(460)] Message Reply: [tpm_manager.ReadSpaceReply] {
  result: NVRAM_RESULT_DEVICE_ERROR
  data:
}

Is trunksd running (it returns this error in such case also)?
If trunksd is running, what's in /var/log/messages? 

Also, if once trunksd is started it starts failing with auth errors, what does 'tpm_manager_client get_space_info --index=0x1007' say?

trunksd is running.

2017-04-01T00:00:40.907445-07:00 ERR trunksd[1785]: TPM: Error writing to TPM handle.: Connection timed out
2017-04-01T00:00:40.908248-07:00 ERR kernel: [75254.082568] i2c_designware i2c_designware.2: controller timed out
2017-04-01T00:00:40.908284-07:00 ERR kernel: [75254.082611] tpm tpm0: tpm_transmit: tpm_send: error -110
2017-04-01T00:00:40.908416-07:00 ERR tpm_managerd[1801]: GetCapability: TRUNKS_RC_WRITE_ERROR
2017-04-01T00:00:40.908465-07:00 ERR tpm_managerd[1801]: Failed to query TPM properties: TRUNKS_RC_WRITE_ERROR
2017-04-01T00:00:40.908504-07:00 WARNING tpm_managerd[1801]: Error initializing trunks tpm state: TRUNKS_RC_WRITE_ERROR
2017-04-01T00:00:42.940380-07:00 INFO kernel: [75256.115249] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

This is a snappy device.

localhost ~ # time tpm_manager_client get_space_info --index=0x1007
Message Reply: [tpm_manager.GetSpaceInfoReply] {
  result: NVRAM_RESULT_DEVICE_ERROR
  attributes: {}
}

real    0m2.029s
user    0m0.015s
sys     0m0.007s

Hm, something is wrong with communications to the tpm in general. Is
/dev/tpm0 there at all? Does the error persist after reboot?

Yes it's there.

usb_updater -f
open_device 18d1:5014
found interface 3 endpoint 4, chunk_len 64
READY
-------
start
target running protocol version 6
offsets: backup RO at 0x40000, backup RW at 0x4000
keyids: RO 0xaa66150f, RW 0xde88588d
Current versions:
RO 0.0.10
RW 0.0.16

But it's weird that I can run get_space_info after reboot, while read_space still fail.

2017-04-01T00:28:02.655053-07:00 ERR tpm_managerd[1465]: Error fetching salting key public info: Handle 1: TPM_RC_HANDLE
2017-04-01T00:28:02.655081-07:00 ERR tpm_managerd[1465]: Error encrypting salt: Handle 1: TPM_RC_HANDLE
2017-04-01T00:28:02.655099-07:00 ERR tpm_managerd[1465]: Error starting an authorization session: Handle 1: TPM_RC_HANDLE

localhost ~ # tpm_manager_client read_space --index=0x1007 --file=/tmp/blah
[INFO:main.cc(460)] Message Reply: [tpm_manager.ReadSpaceReply] {
  result: NVRAM_RESULT_DEVICE_ERROR
  data:
}

P.S: The TPM is not owned. Will that be a problem?

Ok, looks like there was some unrelated issue with the tpm before the reboot. Probably b/35648537, judging by the symptoms.

The TPM not being owned shouldn't be a problem. In my experiments I saw read_space failing with incorrect authorization (while get_space_info succeeded), but not NVRAM_RESULT_DEVICE_ERROR if trunksd is running. Any chance those "tpm tpm0: tpm_transmit: tpm_send: error -110" returned again after rebot by the time read_space is called?

Seems like we added wrong vadim :p

I'm not actively working on this - Shen-En, can you follow and work with apronin@ to see how we can enable tpm_nvread again on devices using Cr50?

Trying on another Eve, still get similar errors:

Case 1: When trunksd is running

localhost ~ # tpm_manager_client read_space --index=0x00001007 --file=/tmp/1                                                                                                                                      
[INFO:main.cc(460)] Message Reply: [tpm_manager.ReadSpaceReply] {
  result: NVRAM_RESULT_ACCESS_DENIED
  data: 
}


Case 2: trunksd is stopped
localhost ~ # stop trunksd
trunksd stop/waiting

localhost ~ # tpm_manager_client read_space --index=0x1007 --file=/tmp/tmp1                                                                                                                                       
[INFO:main.cc(460)] Message Reply: [tpm_manager.ReadSpaceReply] {
  result: NVRAM_RESULT_DEVICE_ERROR
  data: 
}


However, get_space_info works just fine:

localhost ~ # tpm_manager_client get_space_info --index=0x1007                                                                                                                                                    
Message Reply: [tpm_manager.GetSpaceInfoReply] {
  result: NVRAM_RESULT_SUCCESS
  size: 10 (0x0000000A)
  is_read_locked: false
  is_write_locked: true
  attributes: {NVRAM_BOOT_WRITE_LOCK, NVRAM_READ_AUTHORIZATION, NVRAM_PLATFORM_WRITE, NVRAM_PLATFORM_READ}
  policy: NVRAM_POLICY_NONE
}


This is my Cr50 version:
> version
Chip:    g cr50 B2-C
Board:   0
RO_A:  * 0.0.10/29d77172
RO_B:    0.0.10/c2a3f8f9
RW_A:    Error
RW_B:  * 0.0.21/DBG/cr50_v1.1.6811-0755dc40e+
BID A:   00000000:00000000:00000000 Yes
BID B:   00000000:00000000:00000000 Yes
Build:   0.0.21/DBG/cr50_v1.1.6811-0755dc40e+
         tpm2:v0.0.289-cb2de5a
         cryptoc:v0.0.8-6283eee
         2017-08-07 10:24:18 vbendeb@eskimo.mtv.corp.google.com
> 

And /dev/tmp0 is there:
localhost ~ # ls -al /dev/tpm0                                                                                                                                                                                    
crw-------. 1 root root 10, 224 Oct  7 06:10 /dev/tpm0


Any idea? Still sounds related to the bug b/35648537?

BTW, usb_updater -s -i works, so maybe not this bug?
localhost ~ # stop trunksd                                                                                                                                                                                        
trunksd stop/waiting
localhost ~ # usb_updater -s -i                                                                                                                                                                                   
Board ID space: 5a5a4146:a5a5beb9:0000ff7f

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/factory/+/cdc938c1958ddde6303fadfb02c7e989df03a9a7

commit cdc938c1958ddde6303fadfb02c7e989df03a9a7
Author: Shen-En Shih <petershih@chromium.org>
Date: Mon Oct 16 12:13:42 2017

device: Remove interface to read dev switch status from TPM

This interface currently does not work on devices with Cr50, we're
still investigating it on chromium:748435. However, the only usage of
this interface is removed in CL:344564, so maybe it's a better idea
to just remove it (at least for now). We can added it back if we really
need to read the virtual dev switch status from TPM at one day.

BUG= chromium:748435 
TEST=make test

Change-Id: I42d7d2ea4d47a028f1ebdfd3208bf53ce668e024
Reviewed-on: https://chromium-review.googlesource.com/720696
Commit-Ready: Shen-En Shih <petershih@chromium.org>
Tested-by: Shen-En Shih <petershih@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>

[modify] https://crrev.com/cdc938c1958ddde6303fadfb02c7e989df03a9a7/py/device/info.py

Re #15: yes, now it shows the same result that I got in #9. Looks like 'tpm_manager_client read_space' doesn't know how to read the space with NULL auth. I will work on that.

The space has It always attempts to establish a session - and that fails until the tpm is owned since it uses a salting key for sessions, which is created only during initialization. That's why before the tpm is owned we get:

localhost ~ # tpm_manager_client read_space --index=0x1007 --file=/tmp/1
[INFO:main.cc(460)] Message Reply: [tpm_manager.ReadSpaceReply] {
  result: NVRAM_RESULT_DEVICE_ERROR
  data: 
}
because of
2017-10-16T13:06:56.630739-07:00 ERR tpm_managerd[1810]: Error fetching salting key public info: Handle 1: TPM_RC_HANDLE
2017-10-16T13:06:56.630756-07:00 ERR tpm_managerd[1810]: Error encrypting salt: Handle 1: TPM_RC_HANDLE
2017-10-16T13:06:56.630765-07:00 ERR tpm_managerd[1810]: Error starting an authorization session: Handle 1: TPM_RC_HANDLE

Once the tpm is owned, the behavior changes:
# tpm_manager_client read_space --index=0x1007 --file=/tmp/1
[INFO:main.cc(460)] Message Reply: [tpm_manager.ReadSpaceReply] {
  result: NVRAM_RESULT_ACCESS_DENIED
  data: 
}
because of wrong authentication (it doesn't contain the auth value in its internal database):
2017-10-16T13:13:07.215631-07:00 ERR tpm_managerd[1810]: ReadNVSpace: Error reading from non-volatile space: Session 1: TPM_RC_AUTH_FAIL
2017-10-16T13:13:07.215661-07:00 ERR tpm_managerd[1810]: Error reading nvram space: Session 1: TPM_RC_AUTH_FAIL

There is a --password parameter, but I'm not sure it works right (esp for NULL passwords). It is likely possible to fix it by making tpm_manager_client treat '--password' in command-line + NVRAM_READ_AUTHORIZATION with empty policy differently (it now assumes there's a complicated policy attached, since this are the cases tpm_manager was written to deal with). Or I may add a simple password-based reading code to runks_send instead.

Raising prio since now needed for a different project.

Setting the right owner as Meng-Huan already works on it: https://crrev.com/c/1276025 and https://crrev.com/c/1278568. in addition to that makes sense creating in TPM 2.0 case a simple tpm_nvread script that calls tpm_manager_client.

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

commit 454ffd6a1dbe9453ae0bb195527c0c177de8f0f9
Author: Meng-Huan Yu <menghuan@chromium.org>
Date: Sat Oct 13 15:32:17 2018

tpm_manager: NV space commands support NULL password

Support using NULL password (zero length password) on
define/read/write/lock NV space commands.

The password is hashed and then sent to TPM as authorization value.
But for NULL password protected region, we need to send Empty Buffer
as the NULL password in the TPM 2.0 spec part-1 4.40.
So if the password parameter is not set or set to an empty string
(e.g. --password=). We will use empty string as the authorization
value instead of hashed one.

BUG= chromium:748435 
TEST=tpm_manager_client read_space --index=0x1007 --file=/tmp/bla
on testing image running on dev mode.
That space is NULL password protected and has been already
defined after booting.

Change-Id: I51b9978723b2d86a91cf579a1f2e0bff7d074a36
Reviewed-on: https://chromium-review.googlesource.com/1276025
Commit-Ready: Meng-Huan Yu <menghuan@chromium.org>
Tested-by: Meng-Huan Yu <menghuan@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>

[modify] https://crrev.com/454ffd6a1dbe9453ae0bb195527c0c177de8f0f9/tpm_manager/client/main.cc

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