[libvirt] [RFC PATCHv2 5/5] WIP: smartcard: turn on qemu support

[Eric Blake]

On 01/17/2011 11:42 AM, Alon Levy wrote:
>>>               dev: ccid-card-emulated, id ""
>>>                 dev-prop: backend = "nss-emulated"
>>>                 dev-prop: cert1 = <null>
>>>                 dev-prop: cert2 = <null>
>>>                 dev-prop: cert3 = <null>
>>>                 dev-prop: db = <null>
>>
>> Hmm - in the hosts-certificates mode, it looks like I need to support an
>> optional <database> sub-element to populate the ccid-card-emulated.db
>> field when desired.  Is that field a pathname, a generic arbitrary
>> string, or something else altogether?
> 
> Pathname is the only thing I've tested, so let's limit it to this. It's
> NSS specific right now too - but as you see from the arguments it will probably
> be orthogonal, for instance under windows there might be a cryptoapi-emulated
> backend and db argument will be reused.

I think it is pretty easy to add one <smartcard mode=''> per new
backend.  The toughest part would be how to query whether a given
backend is available in a given qemu binary, but if you can please make
sure that 'qemu -device usb-ccid,?' lists all valid backends for a given
qemu binary, then we're set (the first two backends of nss-emulated and
certificates can be assumed if device usb-ccid exists in the first
place).  That is:

<smartcard mode='hosts'> gives backend=nss-emulated

<smartcard mode='hosts-certificates'> gives backend=certificates,
cert1-3 are mandatory, and db is optional

and a hypothetical
<smartcard mode='cryptoapi-emulated'> (or some other appropriate name),
along with any appropriate sub-elements, is added later if qemu ever
adds a third valid backend=cryptoapi-emulated

>>> Tell me if this needs to be changed - for instance I could just
>>> reuse the id as the bus name, so it will lose the ".0" suffix.
>>
>> I think keeping the .0 suffix allows you the future ability to support
>> multiple cards on a single bus.
> 
> The question was about changing my behavior, since right now I rely on
> the default qemu behavior of appending that ".0". So I understand you
> will supply that as a string bus=<id>.0, and since I actually ignore that
> but qemu computes the same bus id, it will just work.

Sounds reasonable - it should just work for the given setup of limiting
qemu to at most one smartcard (easier to match your current
implementation and expand later), without locking us into place once you
ever do start supporting multiple smartcards.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110117/90b7d676/attachment-0001.sig>