[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



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

 


Rackspace

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