Hi On Tue, Dec 23, 2014 at 9:49 PM, Jeremy White <jwhite@xxxxxxxxxxxxxxx> wrote: > Hi folks, > > I've been working a lot with smartcards for Xspice. > > As I've done this, I've come to understand that the Spice client doesn't > actually send the physical smartcard data across; instead it sends > virtualized smartcard apdus, using PK11 information it gets from libnss. > > After some discussion on irc, I decided to explore expanding libcacard to > support sending the apdus directly to the card, using the PC/SC (aka > pcsclite) library. > > I've attached a proof of concept set of patches - one for the client, and > the substantial one for qemu/libcacard. > > The basic approach is to add a parallel to the vcard_emul_nss.c stack, where > we add and remove readers and cards in response to pcsclite events. > > Note that I don't consider the code submission quality; it has quite a few > rough edges. It does work for me in some limited test cases, though, and it > I think largely illustrates my proposed path. > > I am hoping to ask: > > 1. Does this basic approach seem reasonable? I think VCardEmulType VCARD_EMUL_PASSTHRU was supposed to be used for this case, although the current code doesn't make it straightforward to add that, as it initializes nss in vcard_emul_init. It should be possible to change that though. It probably doesn't make much sense to push this in libcacard if you don't reuse any of the cacard framework. > 2. Anyone know what the origin of the VCARD_DIRECT code path was? I use > it here. git-blame pins it back to the original libcacard commit; not sure > where it came from before then. I was trying to find an alternate consumer > of that code to make sure I was aligned with it. No idea, it's probably the way some cards operates but it's not used by CAC afaik > I believe that, with this change, a system that was not otherwise using a > smart card could relay that smart card on to a distant Spice server. I'm > uncertain what would happen in the case where the smart card was in use by > the local system. That's something I'll need to probe yet. I imagine that > it won't work, but have no real hard evidence for that :-/. It could be that pcscd can actually lock concurrent requests and reply from overlaping each others, but I don't think it can handle context switch and apparently there is no context lock when connecting with pc/sc api. So it will likely go wrong in some cases. -- Marc-André Lureau _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel