[tpm2] Re: tpm2_flushcontext stuck

Han <keepsimple at gmail.com>
Newsgroups dev.linux.lists.tpm2
Message-ID <CAEjGaqecH0q-wFbQbNNPAS_R-bh0BqXFFWhweT4VA-gESe5qVw@mail.gmail.com>
Thanks for your responses. They are really helpful to me. Such a fix will
also help me understand how TPM works.

And as a newbie, I felt that the fact TPM exposes two devices (/dev/tpm0
and /dev/tpmrm0) under Linux is confusing and is making
things more complicated.  The architecture diagram (
https://github.com/tpm2-software/tpm2-tss) shows all calls go through the
Resource Manager but that is not the case in reality.  I was wondering what
is the benefit to have 2 devices instead of just one device in linux?

Thanks.


On Mon, Dec 20, 2021 at 10:57 AM Tadeusz Struk <tstruk(a)gmail.com> wrote:

> On 12/19/21 04:17, Juergen Repp wrote:
> > Am 18.12.21 um 20:34 schrieb Han:
> >> I probably missed it,  how can I specify to make sure /dev/tpm0 is
> used, and not /dev/tpmrm0 ?  Is it in some configurations?
> >>
> > You can use the TPM without resource manager with:
> >
> > tpm2_createprimary  -Tdevice:/dev/tpm0 -C o -g sha256 -G ecc -c
> primary.ctx
> > tpm2_getcap handles-transient -Tdevice:/dev/tpm0
> > tpm2_flushcontext -Tdevice:/dev/tpm0 0x80000000
>
> The problem is that when /dev/tpm0 is used it just sends a request
> straight to
> the tpm and the tpm responds with a valid error message, which it then
> passed
> back to tcti. In case of /dev/tpmrm0 the RM tries to first load the none
> existing object 0x80000000 from its cash, but since it cannot find it just
> returns an error code -22 (EINVAL) and nothing gets send to the tpm.
> The tpm_dev_async_work() handler needs to be modified to handle such error
> cases
> as well. I will send a fix for this.
>
> Thanks,
> --
> Tadeusz
>
attachment.htm (text/html, 2 KB)
<div dir="ltr">Thanks for your responses. They are really helpful to me. Such a fix will also help me understand how TPM works. <div><br></div><div>And as a newbie, I felt that the fact TPM exposes two devices (/dev/tpm0 and /dev/tpmrm0) under Linux is confusing and is making things more complicated.  The architecture diagram (<a href="https://github.com/tpm2-software/tpm2-tss">https://github.com/tpm2-software/tpm2-tss</a>) shows all calls go through the Resource Manager but that is not the case in reality.  I was wondering what is the benefit to have 2 devices instead of just one device in linux? </div><div><br></div><div>Thanks.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 20, 2021 at 10:57 AM Tadeusz Struk &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/19/21 04:17, Juergen Repp wrote:<br>
&gt; Am 18.12.21 um 20:34 schrieb Han:<br>
&gt;&gt; I probably missed it,  how can I specify to make sure /dev/tpm0 is used, and not /dev/tpmrm0 ?  Is it in some configurations?<br>
&gt;&gt;<br>
&gt; You can use the TPM without resource manager with:<br>
&gt; <br>
&gt; tpm2_createprimary  -Tdevice:/dev/tpm0 -C o -g sha256 -G ecc -c primary.ctx<br>
&gt; tpm2_getcap handles-transient -Tdevice:/dev/tpm0<br>
&gt; tpm2_flushcontext -Tdevice:/dev/tpm0 0x80000000<br>
<br>
The problem is that when /dev/tpm0 is used it just sends a request straight to<br>
the tpm and the tpm responds with a valid error message, which it then passed <br>
back to tcti. In case of /dev/tpmrm0 the RM tries to first load the none <br>
existing object 0x80000000 from its cash, but since it cannot find it just<br>
returns an error code -22 (EINVAL) and nothing gets send to the tpm.<br>
The tpm_dev_async_work() handler needs to be modified to handle such error cases<br>
as well. I will send a fix for this.<br>
<br>
Thanks,<br>
--<br>
Tadeusz<br>
</blockquote></div>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.