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

[Matthew Fioravante <matthew.fioravante@xxxxxxxxxx>]

Well I think you could keep the original removal patch and just not 
apply this one if you don't want to mess with xm and xend. The original 
patch doesn't touch xm or xend and just removes the vtpm and 
vtpm_manager code. The only reason I'm more inclined to remove all of 
the old vtpm stuff is because its going to be confusing for users 
grepping through the tree trying to figure out how to use vtpm.
On 11/19/2012 07:27 AM, 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.
>
> 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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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