aboutsummaryrefslogtreecommitdiff
path: root/hw/ccid-card-passthru.c
AgeCommit message (Collapse)Author
2012-02-03qdev: register all types natively through QEMU Object ModelAnthony Liguori
This was done in a mostly automated fashion. I did it in three steps and then rebased it into a single step which avoids repeatedly touching every file in the tree. The first step was a sed-based addition of the parent type to the subclass registration functions. The second step was another sed-based removal of subclass registration functions while also adding virtual functions from the base class into a class_init function as appropriate. Finally, a python script was used to convert the DeviceInfo structures and qdev_register_subclass functions to TypeInfo structures, class_init functions, and type_register_static calls. We are almost fully converted to QOM after this commit. Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-01-27ccid: convert to QEMU Object ModelAnthony Liguori
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-28ccid: Fix buffer overrun in handling of VSC_ATR messageMarkus Armbruster
ATR size exceeding the limit is diagnosed, but then we merrily use it anyway, overrunning card->atr[]. The message is read from a character device. Obvious security implications unless the other end of the character device is trusted. Spotted by Coverity. CVE-2011-4111. Signed-off-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-08-22char: rename qemu_chr_close() -> qemu_chr_delete()Anthony Liguori
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-08-22char: rename qemu_chr_write() -> qemu_chr_fe_write()Anthony Liguori
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-04-04w32: Fix compilation (wrong include file)Stefan Weil
arpa/inet.h is not available for w32, so commit edbb21363fbfe40e050f583df921484cbc31c79d breaks w32 compilations. This is fixed by using qemu_socket.h. Signed-off-by: Stefan Weil <weil@mail.berlios.de> Reviewed-by: Alon Levy <alevy@redhat.com> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2011-04-01ccid: add passthru card deviceAlon Levy
The passthru ccid card is a device sitting on the usb-ccid bus and using a chardevice to communicate with a remote device using the VSCard protocol defined in libcacard/vscard_common.h Usage docs available in following patch in docs/ccid.txt Signed-off-by: Alon Levy <alevy@redhat.com> --- Changes from v23->v24: * fixed double license line in header. Changes from v20->v21: (Jes Sorensen review) * add reference to COPYING in header * long comment reformatting Changes from v19->v20: * checkpatch.pl Changes from v18->v19: * add qdev.desc * remove .qdev.unplug (no hot unplug support for ccid bus) Changes from v16->v17: * fix wrong cast when receiving VSC_Error * ccid-card-passthru: force chardev user wakeup by sending Init see lengthy comment below. Changes from v15->v16: Behavioral changes: * return correct size * return error instead of assert if client sent too large ATR * don't assert if client sent too large a size, but add asserts for indices to buffer * reset vscard_in indices on chardev disconnect * handle init from client * error if no chardev supplied * use ntoh, hton * eradicate reader_id_t * remove Reconnect usage (removed from VSCARD protocol) * send VSC_SUCCESS on card insert/remove and reader add/remove Style fixes: * width of line fix * update copyright * remove old TODO's * update file header comment * use macros for debug levels * c++ style comment replacement * update copyright license * fix ATR size comment * fix whitespace in struct def * fix DPRINTF prefix * line width fix ccid-card-passthru: force chardev user wakeup by sending Init The problem: how to wakeup the user of the smartcard when the smartcard device is initialized? Long term solution: have a callback interface. This was done via the deprecated so called chardev ioctl interface. Short term solution: do a write. Specifically we write an Init message. And we change the client to send it's own Init message regardless of receiving this one. Additional Init messages will be regarded as acceptable, the first one received after connection establishment is the determining one wrt capabilities.