[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon, Nov 19, 2012 at 12:27:04PM +0000, Ian Campbell wrote:
> 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.
> 

Hmm.. I can only remember one or two people asking for vtpm stuff during past 
couple of years.
So based on that I don't think it's actively used out there..

Or then it works very well and people don't need to ask about it ;)

-- Pasi


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.