qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] usb-ccid notes for today's meeting


From: Alon Levy
Subject: [Qemu-devel] usb-ccid notes for today's meeting
Date: Tue, 23 Nov 2010 16:39:13 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,

 I've compiled the list of objections from the previous round of talks between 
Anthony and {Robert and I}, with our answers, for reference in todays talk 
(sorry about late send).

Notes for KVM meeting.

Points raised by anthony:
 1. How does the smart card state get migrated?
 2. How do you benefit from tracing and debugging qemu infrastructure?
 3. Device creation is difficult, you need to launch and configure the external 
daemon.
 4. Why not: use in qemu emulated card, and develop a protocol for connecting 
to the remote card.
 5. I think a remote passthrough protocol who's sole purpose is to allow
 external device emulation is a bad idea for QEMU.
 6. Security concert: possible guest breaking into spice client.

Answers:
 1. in emulated: isn't, there will be a different card on the new host anyway.
    in passthru: no need, only usb-ccid state needs migration (and that is 
trivial). the rest has never moved, since it is in the client.
    Other important notes on migration:
     1. This is just like passthrough, only with the remote side staying put 
during migration (as noted by anthony himself).
     2. We do emulate on the client side, but that is not required to 
participate in qemu features, it is not expected to migrate for instance, and 
is there to provide the locking (to allow multiple card users, qemu being one 
of them).

 2. we don't for the passthru, we do for the usb-ccid and emulated cards. We 
can test usb-ccid using the emulated card. So far the only problems that were 
not elementary to fix were with usb layer.

 3. for passthrough we already have a daemon, called spicec, which we will 
reuse. For emulated card this is not a problem.

 4. Two protocols seems overkill, although it is doable. A second protocol not 
based on smart card spec may impede our future flexibility wrt new smart cards.

 5. The passthrough usage for spice is to allow locking, and that requires a 
remote emulator. But it can be used by itself with vscclient in passthrough 
mode (vscclient is part of cac_card repository) and then there is no external 
emulation.

 6. We already have an existing daemon, which needs to live with these security 
concerns. 


Alon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]