From: Patrick Ohly <patrick.ohly at intel.com>
To: tpm2@lists.01.org
Subject: Re: [tpm2] using TPM2 NVRAM for storing LUKS password
Date: Fri, 10 Nov 2017 13:44:46 +0100 [thread overview]
Message-ID: <1510317886.22094.47.camel@intel.com> (raw)
In-Reply-To: 49a9b739-63be-3b12-2eae-54e6af0daa20@linux.vnet.ibm.com
[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]
On Fri, 2017-11-10 at 06:53 -0500, Stefan Berger wrote:
> Other possibilities, you have an old libtpms library that's being
> picked up that may have had a bug?
I indeed didn't have the latest code, but for other reasons - see my
other email. It's working now :-)
> > BTW, should the swtpm instance above really terminate when qemu
> > disconnects? It currently does, although -terminate is not given.
>
> It is terminated by QEMU issuing a shutdown on it. I think it's
> better than leaving stale swtpm processes running.
That it explains it. I was just wondering.
Having swtpm spawned by QEMU avoids exactly this issue with lingering
processes, even when QEMU itself gets killed and doesn't get around to
shut down the TPM properly. Unfortunately the QEMU developers didn't
buy that argument :-/
> > How can I enable more debug logging inside swtpm? Increasing the
> > level
> > does not really provide much useful information.
> >
>
> There's not much debugging output inside the TPM 2 code. Some fatal
> errors, such as not swtpm not being able to write the TPM2 state
> file should show up, though.
Just to close on this, --enable-debug also enables additional output,
doesn't it? I haven't actually used it, though, because it leads to an
assertion in swtpm when using TPM2 (https://github.com/stefanberger/swt
pm/issues/54).
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next reply other threads:[~2017-11-10 12:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 12:44 Patrick Ohly [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-11-27 11:50 [tpm2] using TPM2 NVRAM for storing LUKS password Stefan Berger
2017-11-27 10:03 Patrick Ohly
2017-11-10 15:27 Stefan Berger
2017-11-10 12:53 Patrick Ohly
2017-11-10 12:04 Stefan Berger
2017-11-10 11:53 Stefan Berger
2017-11-10 9:07 Patrick Ohly
2017-11-09 20:43 Patrick Ohly
2017-11-09 20:40 Patrick Ohly
2017-11-09 19:51 Patrick Ohly
2017-11-09 15:25 flihp
2017-11-09 15:17 Stefan Berger
2017-11-09 15:10 Patrick Ohly
2017-11-09 14:12 Javier Martinez Canillas
2017-11-09 12:53 Patrick Ohly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1510317886.22094.47.camel@intel.com \
--to=tpm2@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.