All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Berger <stefanb@linux.vnet.ibm.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH V2 4/9] Add tpm_tis driver to build process
Date: Tue, 05 Apr 2011 20:12:58 -0400	[thread overview]
Message-ID: <4D9BB00A.5040808@linux.vnet.ibm.com> (raw)
In-Reply-To: <BANLkTi=cpwmdYnF1cSuF2sGj930zAELF=A@mail.gmail.com>

On 04/05/2011 02:55 PM, Blue Swirl wrote:
> On Tue, Apr 5, 2011 at 9:33 PM, Stefan Berger
> <stefanb@linux.vnet.ibm.com>  wrote:
>> On 04/05/2011 01:45 PM, Blue Swirl wrote:
>>> On Tue, Apr 5, 2011 at 5:08 AM, Stefan Berger
>>> <stefanb@linux.vnet.ibm.com>    wrote:
>>>> On 04/03/2011 05:20 AM, Blue Swirl wrote:
>>>>> On Fri, Apr 1, 2011 at 10:57 PM, Stefan Berger
>>>>> <stefanb@linux.vnet.ibm.com>      wrote:
>>>>>> On 04/01/2011 02:14 PM, Blue Swirl wrote:
>>>>>>
>>>>>> At this point there is no compile test needed since all code is
>>>>>> 'there'.
>>>>>> It's merely adding the front-end,i.e., the TPM TIS emulation to be
>>>>>> compiled.
>>>>> If the basic device (without the tpms-devel library) can be built on
>>>>> any OS, the flag should go to default-configs/*86*-softmmu.mak.
>>>>>
>>>> It can be built on any OS, but it is of no use since the backend
>>>> (libtpms)
>>>> is only available on Linux and we don't support it on another OS. Unless
>>>> someone else wants to port it to other OSes, I'd say that the test for
>>>> Linux
>>>> is useful.
>>>> I'd actually also only compile the TIS if libtpms could be found, and
>>>> terminate with an error message otherwise. I would add this restriction
>>>> only
>>>> in the last patch, so that in patch 4 at least for now the TIS can be
>>>> built.
>>>> Does that sound reasonable?
>>> It should be possible to emulate the device (to some degree) without
>>> relying on backend. See for example the recently committed smart card
>>> device.
>>>
>> In case of a TPM, the specs are huge and translate into multiple 10k lines
>> of code. If there was to be a dummy backend, all it could send back would be
>> error messages...
> Then how about emulating the library instead so that all calls return failure?
That device would be of no use for a user and only serve the purpose of 
test-compiling it if it was for detecting bit rot.
> If a device is built only in special circumstances, it will be more
> prone to bit rot. We have a few such devices though, so it's not so
> big deal.
>
I'll be following the project and there is interest to keep this device 
working.

    Stefan

  reply	other threads:[~2011-04-06  0:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-30 19:42 [Qemu-devel] [PATCH V2 0/9] Qemu Trusted Platform Module (TPM) integration Stefan Berger
2011-03-30 19:42 ` [Qemu-devel] [PATCH V2 1/9] Support for TPM command line options Stefan Berger
2011-03-30 19:42 ` [Qemu-devel] [PATCH V2 2/9] Add TPM (frontend) hardware interface (TPM TIS) to Qemu Stefan Berger
2011-03-30 19:42 ` [Qemu-devel] [PATCH V2 3/9] Add persistent state handling to TPM TIS frontend driver Stefan Berger
2011-03-30 19:42 ` [Qemu-devel] [PATCH V2 4/9] Add tpm_tis driver to build process Stefan Berger
2011-04-01 18:14   ` Blue Swirl
2011-04-01 19:57     ` Stefan Berger
2011-04-03  9:20       ` Blue Swirl
2011-04-05  2:08         ` Stefan Berger
2011-04-05 17:45           ` Blue Swirl
2011-04-05 18:33             ` Stefan Berger
2011-04-05 18:55               ` Blue Swirl
2011-04-06  0:12                 ` Stefan Berger [this message]
2011-03-30 19:42 ` [Qemu-devel] [PATCH V2 5/9] Add a debug register Stefan Berger
2011-03-30 19:42 ` [Qemu-devel] [PATCH V2 6/9] Implement qemu_thread_join function Stefan Berger
2011-03-30 19:42 ` [Qemu-devel] [PATCH V2 7/9] Add a TPM backend skeleton implementation Stefan Berger
2011-03-30 19:42 ` [Qemu-devel] [PATCH V2 8/9] Implementation of the libtpms-based backend Stefan Berger
2011-03-30 19:42 ` [Qemu-devel] [PATCH V2 9/9] Add block storage support for libtpms based TPM backend Stefan Berger

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=4D9BB00A.5040808@linux.vnet.ibm.com \
    --to=stefanb@linux.vnet.ibm.com \
    --cc=blauwirbel@gmail.com \
    --cc=qemu-devel@nongnu.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.