This is forked from discussion in  issue 724527 .

Comment 19 by apronin@chromium.org, Jun 8

I feel it may be time to combine usb_updater (future cr50-tool) and trunks_send into a single app that decides if it talks directly to /dev/tpm0 or goes through trunksd based on a command-line switch.
This way we can avoid code duplication, and just switch between two simple transports that implement send-command-and-get-response functionality at the low level.

We can even auto-detect the transport (use trunksd if /dev/tpm0 is busy; or vice versa: go through /dev/tpm0 if trunksd is not on dbus), but that may be an overkill.

If, with all the package inter-dependencies, usb_updater can link to libtrunks.so from trunks package, it can also use TrunksDBusProxy::SendCommandAndWait() from there instead of calling "trunks_send --raw".

trunks_send itself does just that: https://chromium.googlesource.com/aosp/platform/system/tpm/+/master/trunks/trunks_send.cc#163
after a simple setup:
https://chromium.googlesource.com/aosp/platform/system/tpm/+/master/trunks/trunks_send.cc#633

Comment 23 by vbendeb@chromium.org, Jun 8

Maybe modifying usb_updater to use trunks_send --raw interface instead of /dev/tpm0 based on command flag is an option, but again, I would rather limit the ability of cr50_tool running on a prod system.

ok, I will add a mode to use trunks_send --raw as a TPM driver option in usb_updater. This is not going to look pretty, but will do the trick.

I'll look into using trunks_send as a tpm driver interface option (in
addition to USB and /dev/tpm0) in the meanwhile