Re: [Xen-devel] [PATCH VTPM v3 03/10] Remove old vtpm support from xm

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-11-15 at 15:17 +0000, Matthew Fioravante wrote:
> Signed-off-by: Matthew Fioravante <matthew.fioravante@xxxxxxxxxx>
> ---
>  docs/man/xm.pod.1                           |   11 ---
>  tools/python/README.XendConfig              |    2 -
>  tools/python/README.sxpcfg                  |    4 -
>  tools/python/scripts/xapi.py                |   20 ----
>  tools/python/xen/xend/XendAPI.py            |  128 ------------------------
>  tools/python/xen/xend/XendConfig.py         |   19 +---
>  tools/python/xen/xend/XendConstants.py      |    8 +-
>  tools/python/xen/xend/XendDevices.py        |    4 +-
>  tools/python/xen/xend/XendDomainInfo.py     |   29 ------
>  tools/python/xen/xend/XendError.py          |    1 -
>  tools/python/xen/xend/XendOptions.py        |    4 -
>  tools/python/xen/xend/server/tpmif.py       |  141 
> ---------------------------
>  tools/python/xen/xend/tests/xend-config.sxp |    2 -
>  tools/python/xen/xm/create.dtd              |    4 -
>  tools/python/xen/xm/create.py               |   69 -------------
>  tools/python/xen/xm/main.py                 |   37 -------
>  tools/python/xen/xm/xenapi_create.py        |   39 --------
>  17 files changed, 4 insertions(+), 518 deletions(-)
>  delete mode 100644 tools/python/xen/xend/server/tpmif.py

I know I guided you down this path in the first place but I'm starting
to wonder if removing the process model is/was the right thing to do for
xend. It's one thing for xend to be deprecated and unmaintained, but
actively removing features is a bit more than that.

Looking back at 26144:170d45f7a2eb I see in the commit message:
        Remove the old vtpm process model. It doesn't work very well and
        is no longer supported.

Also looking back in the previous mail threads I see:
        The vtpm_manager code is full of bugs and actually needs a
        complete rewrite. The amount of careless memory leaks and other
        bugs I found when trying to use it were pretty astounding. The
        first manager patch fixes most of the ones I could find to get
        the manager to work properly.
        
        The managers current form in the xen tree is actually pretty
        unusable. I don't have time to rewrite the manager, but what I'm
        offering here is at least a huge improvement over the old code.
        
and also:
        I don't know if there is anyone who would want to still use
        vtpms as
        processes when the stub domains are now available. Security
        research
        people like the domain model because it guarantees a better
        separation of components guaranteed by the hypervisor and
        doesn't have to trust the dom0 OS.

Which suggests that the number of people using the process model stuff
with xend is likely to be indistinguishable from zero. Do you have any
idea if there is anyone actually using it?

In any case it does seem like anyone who is using the vtpm with xend is
playing with fire since it is unmaintained and full of bugs, which isn't
a good thing in a component which is supposed to be *increasing*
security.

Daniel/Pasi, I've CCd you since I thought you might have some insights
into how much use the process model vtpm stuff in xend is getting in the
field etc.

BTW I'm not suggesting that we (or you) maintain or even update the
process model stuff or xm/xend, just that we leave it as it was (i.e. in
a poor state + lagging behind the libxl based stubdom stuff) until xend
fully goes away.

Anyhow, since we need to revert 26144:170d45f7a2eb if we decide to go
back on this decision I'm going to apply this anyway, what's one more
revert ;-). Same applies to a bunch of the following patches which build
on this removal.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel