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

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

On Mon, Jan 17, 2011 at 01:12:28PM -0700, Eric Blake wrote:
> 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

You meant ccid-card-emulated, right? usb-ccid doesn't have backends. Looking
into existing devices, this doesn't look that difficult, It can be printed like so:

I'll just make sure the names I use don't contains any '/' chars :)

Actually, supplying a list of possible backends is easy. Actually testing
which are available at runtime - right now it should be identical, since if you
can't find the NSS so qemu won't pass the loading stage. But that still means
I will report nss-emulated even if there are no hardware devices. Is that

> 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 redhat com    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org

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