Re: adding smartcard support to libvirt

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

 



On Mon, Jan 03, 2011 at 11:50:18AM -0700, Eric Blake wrote:
> [adding the public list for feedback on new XML. Background: Alon is
> working on adding some new command line arguments to qemu to make it
> possible to share smartcard access between a host and its virtual
> guests; while this is not upstream yet, libvirt should be prepared to
> handle the new command line options]
> 
> [lengthy email; skip to the tail end for a high-level summary of
> proposed XML changes]
> 

So my own summary: it's all good, you just mixed the name and id for the
spicevmc. More about the spicevmc below.

> On 12/22/2010 03:00 AM, Alon Levy wrote:
> > On Mon, Dec 20, 2010 at 12:19:42PM -0700, Eric Blake wrote:
> >> I also found the following which also served as a good overview for what
> >> you are proposing to add to qemu:
> >>
> >> http://cgit.freedesktop.org/~alon/qemu/commit/?h=usb_ccid.v9&id=d5484a05
> > 
> > Of course, sorry, should have pointed you to that initially. I wrote the
> > ccid.txt one, the other is Robert Relyea's (the author of the libcacard
> > library).
> > 
> >>
> >> Right now, I'm thinking of adding a new <smartcard> element under
> >> <devices>.  Let me know if this makes sense or needs tweaking; once the
> >> XML is in place, I can then figure out how to map to qemu command lines
> >> pretty easily.
> 
> > 
> > Ok, so to make a little order: There are three devices being added to qemu,
> > they are:
> >  * usb-ccid - this is both a usb device and a ccid bus. The rest of the devices
> >   attach to this bus (so they don't care that the bus is actually a usb device
> >   itself, same as a PCI device exposing an IDE bus).
> >  * ccid-card-emulated - this device uses NSS directly, so it can work in two modes:
> >   * no arguments at all - in this case it will look for whatever hardware NSS can
> >    access by default. This will depend on the specific host setup, and on the user
> >    credentials qemu is running under.
> >   * cert1, cert2, cert3 arguments - in this case NSS will look for three certs
> >    with the names supplied, and use them instead of any physical hardware. In this case qemu
> >    just needs to have those certificates available, and no physical hardware is required.
> >  * ccid-card-passthru - this device doesn't rely on NSS at all. Instead it uses a chardevice,
> >   and implements the VSCard protocol over it, which is just a simple protocol for remoting
> >   the CCID requests (actually it works in the APDU level, so it doesn't care for CCID specifically,
> >   but then again if you read the CCID you'll notice the main messages are XferBlock which just passes
> >   an APDU along too).
> >   Here there are also two basic options, depending on which char device we want to use. Of course you
> >   are not limited to these two, you can use any chardevice, but I've been using only these two and
> >   I can't think of a use for any other right now:
> >   * tcp socket char device - in this case you can use the accompanying libcacard/vscclient program
> >    running on another (or the same) machine, it uses NSS in exactly the same ways (certs/hw) as described
> >    above for the emulated card (which is of course natural since it is using the same library to do
> >    that, libcacard).
> >   * spice chardevice - this is a chardevice that uses libspice, which is linked with qemu. spice in
> >    turn will use a channel to the client which links with libcacard. This device is available here:
> >     http://lists.gnu.org/archive/html/qemu-devel/2010-12/msg01442.html
> >    as you can see from that thread, it isn't accepted yet, but anthony told me he wants to schedule
> >    vdagent (and by extension, spice chardevice, i.e. spicevmc chardev) talk to qemu community meeting
> >    after new years.
> > 
> >
> > So I hope you understand that you do in fact need some device, in this
> case
> > the usb-ccid device, it's only the card emulated that uses the
> certificates,
> > not the bus device. The bus device remains the same for all of the various
> > configurations.
> >
> 
> Just to restate (to make sure I'm understanding you correctly),
> smartcard support in qemu requires that you enable two things: the
> usb-ccid device, and your choice of the ccid-card-emulated device or the
> ccid-card-passthru device.  The ccid-card-emulated device operates in
> two modes, and the ccid-card-passthru device uses a protocol to talk
> through a required associated chardev (where the other end of the
> chardev can operate in two modes, but that's outside of what the guest
> can see; and where two particular chardevs make the most sense).
> 

Exactly.

> > So after this lengthy summary, you see that actually the mode tag is good, I guess also the names
> > you set are good.
> 
> Picking the right mode names is probably the hardest part of writing new
> XML in a way that can be reused across other hypervisor technologies if
> similar approaches are adopted there, as well as allowing reasonable XML
> additions in the future, which is why I'm opening the feedback to make
> sure it all looks good.
> 
> >>>  * passthrough from a host attached smartcard reader. (despite
> passthrough in the use
> >>>   case name, this is actually done using the ccid-card-emulated device)
> >>
> >> <domain...>
> >>   <devices>
> >>     <smartcard mode='host'>
> >>        <source path='usb-ccid'/>
> >>     </smartcard>
> >>   </devices>
> >> </domain>
> >>
> >> maps to qemu -usb -device usb-ccid -device ccid-card-emulated
> 
> > I don't really grok the "source path='usb-ccid'", unless you just want
> to ensure
> > that this can be replaced with other devices in the future, which in
> this case sounds good to me.
> >
> 
> Then <source> isn't quite the right terminology for this.  If we ever do
> come up with a future qemu device that can replace usb-ccid while still
> providing everything needed for the ccid-card-emulated device to work,
> then we can augment the XML at that point for choosing how to replace
> the usb-ccid device, but I don't think we need to tie it to <source> for
> the current proposal.
> 
> So, this mode can be simplified.  In other words, requesting mode='host'
> implies turning on anything in the hypervisor necessary to let the
> hypervisor use NSS access to the host's smartcard support (in qemu's
> case, turning on both the usb-ccid device and the ccid-card-emulated
> device with no arguments).  Therefore, mode='host' wouldn't need any
> sub-elements for now.
> 
> <domain...>
>   <devices>
>     <smartcard mode='host'/>
>   </devices>
> </domain>
> 

Looks good.

> >>>  * passthrough from a client via vscclient program (this is done using ccid-card-passthrough
> >>>   but with a standard tcp chardevice)
> >>
> >> <domain...>
> >>   <devices>
> >>     <smartcard mode='certificates'>
> >>       <source path='usb-ccid'/>
> >>       <certificate id='1' path='cert1'/>
> >>       <certificate id='2' path='cert2'/>
> >>       <certificate id='3' path='cert3'/>
> >>     </smartcard>
> >>  </devices>
> >> </domain>
> >>
> >> maps to qemu -usb -device usb-ccid -device
> >>
> ccid-card-emulated,backend=certificates,cert1=cert1,cert2=cert2,cert3=cert3
> >>
> >> Libvirt will have to ensure that the qemu user has access rights to read
> >> the three certificate files on the host.  My idea here is that
> >> mode='certificates' requires an element for the host source, as well as
> >> paths to the three host certificates.
> 
> > Also, maybe call certificates mode host-certificates, just to make it
> obvious?
> 
> So, here's the updated proposal (again, dropping a <source> element, and
> picking a better mode name):
> 
> <domain...>
>   <devices>
>     <smartcard mode='host-certificates'>
>       <certificate id='1' path='cert1'/>
>       <certificate id='2' path='cert2'/>
>       <certificate id='3' path='cert3'/>
>     </smartcard>
>  </devices>
> </domain>
> 

Looks good.

> >>>  * passthrough with spice ('my' use case, -chardev spicevmc,id=smartcard,name=smartcard -device ccid-card-passthru,chardev=smartcard)
> >>
> >> <domain...>
> >>   <devices>
> >>     <smartcard mode='passthrough' name='smartcard'>
> >>       <serial type='smartcard'>
> >>         <source path='spicevmc'/>
> >>       </serial>
> >>     </smartcard>
> >>   </devices>
> >> </domain
> >>
> >> maps to qemu -chardev spicevmc,id=smartcard,name=smartcard -device
> >> ccid-card-passthru,chardev=smartcard
> 
> >> My idea here is that mode='passthrough' requires a name, which then gets
> >> used to create both the smartcard passthrough device and the backing
> >> chardev device.  Then, as a child element, <smartcard> contains any
> >> other valid element that could serve as a top-level device, such as
> >> <serial type='tcp'>.
> 
> >>
> > 
> > Ok, so this is wrong - there are actually two source paths, if I understand
> > the idea - you would still want to explicitly specify usb-ccid (again, assuming this
> > is a future proofing for changing the underlying device), and the other would be
> > the spicevmc, and it would translate to the following command line:
> > 
> > qemu -chardev spicevmc,id=smartcard,name=smartcard -usb -device usb-ccid
> > -device ccud-card-passthru,chardev=smartcard
> > 
> > I guess something like:
> > 
> > <smartcard mode='passthrough' name='smartcard'>
> >  <source path='usb-ccid'/>
> >  <serial type='smartcard'>
> >   <source path='spicevmc'/>
> >  </serial>
> > </smartcard>
> 
> So the key point here is that use of the ccid-card-passthru device
> requires a chardev=xyz argument that maps to another existing -chardev
> device.  And given that the chardev device in use is essential to the
> smartcard support, I'm proposing that the <smartcard> element require
> the paired chardev device as a sub-element, rather than as a sibling
> element.
> 
> Right now, the XML for <devices> allows the following <serial> types:
> dev, file, pipe, unix, tcp, udp, null, stdio, vc, pty
> 
> so there's no notion of a type='smartcard'.  It looks more like the new
> serial type is 'spicevmc'.  And back to my idea of omitting mention of
> usb-ccid in the XML, and refactoring things to avoid dupicate use of
> strings (to make it a bit more obvious which XML aspects impact which
> command-line aspects), that leaves us with:
> 
> <domain...>
>   <devices>
>     <smartcard mode='passthrough' name='xyz'>
>       <serial type='spicevmc'/>
>     </smartcard>
>   </devices>
> </domain>
> 
> maps to qemu -chardev spicevmc,id=smartcard,name=xyz -usb -device
> usb-ccid -device ccid-card-passthru,chardev=xyz
> 

ok, here you just mixed the id and name. I admit name is a bad, well, name,
but it was already available as a parameter to chardev's (used as the filename
for a file chardev). In the context of a spicevmc chardev the name is actually
what I internally call a subtype. There are two subtypes/names that are valid
currently: vdagent and smartcard. The id attribute is a global qemu tag that
identifies a particular instance, so what needs to match is the chardev id
and the chardev value given to the ccid-card-passthru device:

qemu -chardev spicevmc,name=smartcard,id=xyz -usb -device usb-ccid
-device ccid-card-passthru,chardev=xyz

Which is just what you have above, just name and id interchanged.

> Am I correct that a spicevmc -chardev has to use a fixed id=smartcard
Fixed name, yes.

> but an arbitrary name, and that ccid-card-passthru has to have a
arbitrary id.

> chardev=name that maps to the same name= used for a -chardev?  Or is it
To the same id.

> that ccid-card-passthru has to have a chardev=name that maps to the same
> name as a -chardev id=name?
> 
Same id. With these corrections - yes.

> And, given the goal that <smartcard mode='passthrough'> then has a child
> element that describes the passthrough device, it also means that I
> would be adding support for a top-level spicevmc chardev device,
> unrelated to smartcards; would this need any additional XML parameters?
> 

Right, again sorry for introducing it this way - exactly correct, the spicevmc
is a separate entity. It is a new chardev, this is the chardev suggested last
time I talked to libvirt when I tried to introduce a similarly named device
called spicevmc. So instead of a superficial wrapper around virtio-serial I
am introducing a chardev that can be used to connect to the spice server that
is linked to the qemu process. The parameters for spicevmc are:
id - this is the normal identifier that all chardev's must have.
name - this distinguishes between the use of this chardev internal to spice, it
 can be of two values right now as I mentioned, 'vdagent' for use as the vdagent
 connection, and 'smartcard' for use by the smartcard channel.

> <domain...>
>   <devices>
>     <serial type='spicevmc'>
>       <!-- anything else needed for a top-level spicevmc chardev? -->
>     </serial>
>   </devices>
> </domain>
> 

<serial type='spicevmc' id='xyz' name='vdagent'/>
<serial type='spicevmc' id='xyz' name='smartcard'/>
?

> > 
> >> <domain...>
> >>   <devices>
> >>     <smartcard mode='passthrough' name='ccid'>
> >>       <serial type='tcp'>
> >>         <source host='0.0.0.0' port='2001'/>
> >>         <protocol type='tcp'/>
> >>       </serial>
> >>     </smartcard>
> >>   </devices>
> >> </domain>
> >>
> >> maps to qemu -chardev
> >> socket,server,host=0.0.0.0,port=2001,id=ccid,nowait -usb -device
> >> usb-ccid -device ccid-card-passthru,chardev=ccid
> >>
> > 
> > So actually here you got the command line correctly (again, no difference
> > between both ccid-card-passthru uses except for the -chardev created), and
> > I guess I would just add the same usb-ccid specification to your element:
> > 
> > <smartcard mode='passthrough' name='ccid'>
> >   <source path='usb-ccid'/>
> >   <serial type='tcp'>
> >     <source host='0.0.0.0' port='2001'/>
> >     <protocol type='tcp'/>
> >   </serial>
> > </smartcard>
> > 
> > btw, I'm guessing the name attribute on the top level (smartcard) element is
> > just a descriptor, like id? or is it something else? does libvirt have
> > id and name, or just name?
> 
> My thoughts were that the name attribute of the <smartcard> element
> becomes the string that get reused twice in the qemu command line (once
> in the -chardev name, once I figure out whether that is by the id= or
> the name= field, and once in the -ccid-card-passthru chardev= field).
> This one is a bit easier, since top-level <serial type='tcp'> already
> exists, so I think this one remains:
> 
> <domain...>
>   <devices>
>     <smartcard mode='passthrough' name='ccid'>
>       <serial type='tcp'>
>         <source host='0.0.0.0' port='2001'/>
>         <protocol type='tcp'/>
>       </serial>
>     </smartcard>
>   </devices>
> </domain>
> 

So just s/name/id/ there (i.e. id='ccid') and it's good.

> 
> >>
> > 
> > Ok, so I don't understand exactly what you wanted the name to mean. Unless
> > you meant for it to do exactly what I thought adding a source element side by
> > side with the serial element would do, namely specifying the device (devices)
> > to use, what I called future proofing.
> > 
> >>>  * emulated with certificates (ccid-card-emulated with proper parameters to use user provided file certificates)
> >>
> >> Since the certificates live in the guest and do not pass through the
> >> qemu command line, my understanding is that libvirt does not see this as
> >> any different from mode='passthrough' above.
> > 
> > Yes, I just specified this for completness sake.
> > 
> 
> In summary, this is my proposal for the new XML; feedback welcome to
> correct anything:
> 
> <devices> modifies one existing sub-element (<serial> learns a new
> type='spicevmc' to match qemu's new spicevmc chardev), and adds a new
> sub-element <smartcard>.  The new <smartcard> element has a required
> mode attribute, that takes on one of three strings:
> 
> <smartcard mode='host'/>
> no other attributes, no sub-elements. Implies that the hypervisor
> exposes whatever devices necessary to the guest to see a smartcard, and
> feeds the smartcard implementation by communicating natively with the
> host smartcard for all needed information (maps to qemu -usb -device
> usb-ccid -device ccid-card-emulated)
> 
> <smartcard mode='host-certificates'>
>   <certificate id='1' path='cert1'/>
>   <certificate id='2' path='cert2'/>
>   <certificate id='3' path='cert3'/>
> </smartcard>
> no other attributes, but requires three <certificate> sub-elements.
> Implies that the hypervisor exposes whatever devices necessary to the
> guest to see a smartcard, and that it feeds the smartcard implementation
> with three certificate files living in the host rather than trying to
> talk to a host smartcard (maps to qemu -usb -device usb-ccid -device
> ccid-card-emulated,backend=certificates,cert1=cert1,cert2=cert2,cert3=cert3)
> 
> <smartcard mode='passthrough' name='xyz'>
>   <serial .../>
> </smartcard>
> name attribute is optional but recommended (assuming libvirt can create
> a unique name if none is provided).  <serial> sub-element is required,
> with the same form as a normal <serial> sub-element of <devices>, but
> the common uses will be <serial type='tcp'> (existing) or <serial
> type='spicevmc'> (new).  Implies that the hypervisor exposes whatever
> devices necessary to the guest to see a smartcard, and that it feeds the
> smartcard implementation via the associated char device (maps to qemu
> -chardev ...,name=xyz -usb -device usb-ccid -device
> ccid-card-passthru,chardev-xyz)
just s/name/id/.

> 
> -- 
> Eric Blake   eblake@xxxxxxxxxx    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
> 


--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]