12:50 p.m.
[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]
On 12/22/2010 03:00 AM, Alon Levy wrote:
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
>>> * 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.
<devices <smartcard mode='host-certificates' <certificate id='1' path='cert1'/ <certificate id='2' path='cert2'/ <certificate id='3' path='cert3'/ </smartcard
</devices </domain
>>> * 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
>
> 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
Am I correct that a spicevmc -chardev has to use a fixed id=smartcard
but an arbitrary name, and that ccid-card-passthru has to have a
chardev=name that maps to the same name= used for a -chardev? Or is it
that ccid-card-passthru has to have a chardev=name that maps to the same
name as a -chardev id=name?
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?
<domain... <devices <serial type='spicevmc' <!-- anything else needed for a top-level spicevmc
chardev? -- </serial </devices
</domain
>
>> <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
> >
> 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)
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
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).
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.
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...> 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'>.
>
3:17 a.m.
New subject: [libvirt] adding smartcard support to libvirt
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
1:25 p.m.
New subject: [libvirt] adding smartcard support to libvirt
On 01/04/2011 02:17 AM, Alon Levy wrote:
[focusing on the spicevmc chardev aspect]
>
> <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:
> 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'/>
According to our existing XML:
http://libvirt.org/formatdomain.html#elementsConsole
there are four categories of chardevs: <serial>, <parallel>, <console>,
and <channel>. Within each chardev, there are two optional
sub-elements: <source> describing the host's view of the chardev, and a
<target> describing the guest's view (the chardev type dictates whether
<source> must exist, and the chardev category dictates what <target>
must look like).
It sounds to me like spicevmc is best described as a <channel>, since it
is exposing a spice channel for host communications rather than an
actual character device on the host.
The chardev type of spicevmc (the type attribute under
<serial|parallel|console|channel>) does not fit in with any of the
existing channel types of 'stdio', 'file', 'vc', 'null',
'pty', 'dev',
'pipe', 'tcp', 'udp', or 'unix', so it would be a new type
'spicevmc'.
It probably only makes sense to use type='spicevmc' with <channel>, so
the other three chardev types should probably reject it.
When the chardev type is 'spicevmc', the <source> sub-element seems like
it is optional (since the spice connection has sane defaults), but if
provided, will provide the extra information that can also be provided
through the existing <graphics type='spice'> element, such as
port='5903'.
Meanwhile, since spicevmc is a <channel>, the <target> element must
specify a type (right now, the only types expected for <channel> are
'guestfwd' and 'virtio'), so we're effectively adding two new types
('vdagent' and 'smartcard').
So, I'm thinking that this XML representation matches the spicevmc chardev:
<devices>
<channel type='spicevmc'/>
<source port='5903' tlsPort='5904' autoport='no'
listen='127.0.0.1'/>
<target type='smartcard'/>
</channel>
</devices>
In looking more at libvirt XML, I don't see any fields that match id
assignments; rather, libvirt auto-assigns unique ids in the form %s%d,
category, count, where category matches <channel> and count matches how
many <channel> devices are present. That is, the above xml would map to:
qemu -chardev spicevmc,id=smartcard,name=channel1
Hmm; getting spicevmc to work seems independent enough of getting
<smartcard> implemented by using existing <channel type='tcp'/>, so
I'll
try to split my libvirt XML improvements into two batches. Should I
focus on <channel type='spicevmc'> or on <smartcard> first?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
3:09 p.m.
New subject: [libvirt] adding smartcard support to libvirt
On Wed, Jan 05, 2011 at 12:25:58PM -0700, Eric Blake wrote:
On 01/04/2011 02:17 AM, Alon Levy wrote:
[focusing on the spicevmc chardev aspect]
>>
>> <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:
>
>> 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'/>
According to our existing XML:
http://libvirt.org/formatdomain.html#elementsConsole
there are four categories of chardevs: <serial>, <parallel>,
<console>,
and <channel>. Within each chardev, there are two optional
sub-elements: <source> describing the host's view of the chardev, and a
<target> describing the guest's view (the chardev type dictates whether
<source> must exist, and the chardev category dictates what <target>
must look like).
It sounds to me like spicevmc is best described as a <channel>, since it
is exposing a spice channel for host communications rather than an
actual character device on the host.
The chardev type of spicevmc (the type attribute under
<serial|parallel|console|channel>) does not fit in with any of the
existing channel types of 'stdio', 'file', 'vc', 'null',
'pty', 'dev',
'pipe', 'tcp', 'udp', or 'unix', so it would be a new
type 'spicevmc'.
It probably only makes sense to use type='spicevmc' with <channel>, so
the other three chardev types should probably reject it.
When the chardev type is 'spicevmc', the <source> sub-element seems like
it is optional (since the spice connection has sane defaults), but if
provided, will provide the extra information that can also be provided
through the existing <graphics type='spice'> element, such as
port='5903'.
Meanwhile, since spicevmc is a <channel>, the <target> element must
specify a type (right now, the only types expected for <channel> are
'guestfwd' and 'virtio'), so we're effectively adding two new types
('vdagent' and 'smartcard').
So, I'm thinking that this XML representation matches the spicevmc chardev:
<devices>
<channel type='spicevmc'/>
<source port='5903' tlsPort='5904' autoport='no'
listen='127.0.0.1'/>
I got you until now - but what's with the port/tlsPort - all of that stuff belongs
to the spice flag, and I'm pretty sure is already taken care of by some other
tag (I guess <spice> probably?). This chardev is totally separate (sure, you need
to be using spice for it to make sense, but there is not overlap in parameters, for
instance you don't give a port nor a tlsPort to the spicevmc chardev).
<target type='smartcard'/>
This looks right.
</channel>
</devices>
In looking more at libvirt XML, I don't see any fields that match id
assignments; rather, libvirt auto-assigns unique ids in the form %s%d,
category, count, where category matches <channel> and count matches how
many <channel> devices are present. That is, the above xml would map to:
qemu -chardev spicevmc,id=smartcard,name=channel1
I hope you meant id=channel1,name=smartcard ? the id needs to be the same
as the ccid-passthru uses. But I guess we determined that it's easiest to
let the <smartcard mode="passthru"/> already add the spicevmc chardev
itself? the usage of "-chardev spicevmc,id=xyz,type=smartcard" is only
for a "-device ccid-card-passthru,chardev=xyz", so one won't appear without
the other.
The usage of "-chardev spicevmc,id=xyz,type=vdagent" is also just with the
usage of spice, I'm guessing the existing <spice> tag (sorry, not familiar
with it - I use qemu from shell scripts.. :/ ) should just always create
this chardev, and libvirt will make sure it's id doesn't conflict with any other,
i.e. for spice usage a spicevmc chardev used by a virtioserialport device:
-chardev spicevmc,id=chardev1,name=vdagent -device
virtserialport,chardev=chardev1,name=com.redhat.spice.0
This creates the virtioserialport device with the name the in-guest agent looks for, and
ties it
to the correct spice server interface via the spicevmc chardev.
Hmm; getting spicevmc to work seems independent enough of getting
<smartcard> implemented by using existing <channel type='tcp'/>, so
I'll
try to split my libvirt XML improvements into two batches. Should I
focus on <channel type='spicevmc'> or on <smartcard> first?
I guess start with the smartcard first? Implement it without dealing
with the spicevmc side - i.e. don't implement the passthru type first,
or propose it but don't implement it. Then do the spicevmc part.
I'm not particular on the order - both are required for RHEL 6.1 anyhow,
and each is testable without the other (spicevmc with vdagent usage outlined
above, and smartcard without spice by using it locally through libvirt).
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
3:55 p.m.
New subject: [libvirt] adding smartcard support to libvirt
On 01/05/2011 02:09 PM, Alon Levy wrote:
> So, I'm thinking that this XML representation matches the
spicevmc chardev:
>
> <devices>
> <channel type='spicevmc'/>
> <source port='5903' tlsPort='5904' autoport='no'
> listen='127.0.0.1'/>
I got you until now - but what's with the port/tlsPort - all of that stuff belongs
to the spice flag, and I'm pretty sure is already taken care of by some other
tag (I guess <spice> probably?).
Hmm, right now, the only use of spice in XML is under <graphics
type='spice'>, and it is the <graphics> element that contains port,
tlsPort, autoport, and listen arguments. So we may need to revisit
that, and have some way to use a single location for spice parameters
shared among all spice-related devices, and a way for both <graphics
type='spice'> and <smartcard type='passthrough'> to reference
that
rather than repeating it. Meaning that spicevmc support just got more
difficult, if it involves tweaking <graphics> rather than just adding a
new <channel type='spicevmc'> element.
This chardev is totally separate (sure, you need
to be using spice for it to make sense, but there is not overlap in parameters, for
instance you don't give a port nor a tlsPort to the spicevmc chardev).
Okay, looking more at existing devices, I agree that <channel
type='spicevmc'> should only need additional attributes/sub-elements
corresponding to parameters appearing directly in the -chardev/-device
argument pair handed to qemu. So I'm not sure if <source> makes sense
any more, or if <source> would be what ends up pointing to common
details about the spice server as shared with the <graphics> element.
> <target type='smartcard'/>
This looks right.
> </channel>
> </devices>
>
> In looking more at libvirt XML, I don't see any fields that match id
> assignments; rather, libvirt auto-assigns unique ids in the form %s%d,
> category, count, where category matches <channel> and count matches how
> many <channel> devices are present. That is, the above xml would map to:
>
> qemu -chardev spicevmc,id=smartcard,name=channel1
>
I hope you meant id=channel1,name=smartcard ? the id needs to be the same
as the ccid-passthru uses.
Arrgh - yes, more fallout from me swapping id= and name=, and copying
and pasting from the wrong email. You already made it clear that id= is
the unique name referenced in some other -device chardev=id location,
and that for spicevmc, name= is one of two fixed values (vdagent or
smartcard).
But I guess we determined that it's easiest to
let the <smartcard mode="passthru"/> already add the spicevmc chardev
itself? the usage of "-chardev spicevmc,id=xyz,type=smartcard" is only
for a "-device ccid-card-passthru,chardev=xyz", so one won't appear
without
the other.
Looking even more at existing examples (can you tell that I'm trying to
learn more about existing <devices> at the same time as implementing a
new one?), I see this good example from
qemuxml2argvdata/qemuxml2argv-serial-tcp-chardev:
<serial type='tcp'>
<source mode='connect' host='127.0.0.1'
service='9999'/>
<protocol type='raw'/>
<target port='0'/>
</serial>
maps to:
-chardev socket,id=serial0,host=127.0.0.1,port=9999 -device
isa-serial,chardev=serial0
It looks like -chardev was added in qemu 0.12, and that earlier versions
used just -device without having to map things back to a chardev; but
since smartcard is post-0.12, I only need to worry about the -chardev
side of things.
> Hmm; getting spicevmc to work seems independent enough of
getting
> <smartcard> implemented by using existing <channel type='tcp'/>,
so I'll
> try to split my libvirt XML improvements into two batches. Should I
> focus on <channel type='spicevmc'> or on <smartcard> first?
I guess start with the smartcard first? Implement it without dealing
with the spicevmc side - i.e. don't implement the passthru type first,
or propose it but don't implement it. Then do the spicevmc part.
Yep, that's pretty much what I'm settling on right now - figure out how
to map <smartcard> to existing 'tcp' mapping first, then figure out
about adding spicevmc support including expanding <smartcard> to handle
spicevmc.
I'm not particular on the order - both are required for RHEL 6.1
anyhow,
and each is testable without the other (spicevmc with vdagent usage outlined
above, and smartcard without spice by using it locally through libvirt).
So, back to thinking about the new <smartcard> element. The <smartcard
mode='host'> and <smartcard mode='host-certificates'> modes are
simple,
since -device ccid-card-emulated has no associated -chardev argument.
But if we go with the ideas that <smartcard mode='passthrough'> implies
-device ccid-card-passthru and an associated -chardev, and that the only
-chardev's worth pairing with a <smartcard> are tcp and spicevmc, then
it's simpler to just add a type attribute, and make <smartcard
mode='passthrough' type='tcp'> look a lot like <serial
type='tcp'> (no
<serial> sub-element, but instead have a <source> sub-element directly
resembling the <source> sub-element of serial). Meanwhile, <serial>
allows a <target> sub-element (which virtual serial port the guest will
access as the chardev), whereas <smartcard> would not (the guest sees
the smartcard via the emulated card from the usb-ccid bus, and not as a
raw serial port). Thus,
<devices>
<smartcard mode='passthrough' type='tcp'>
<source host='0.0.0.0' port='2001'/>
<protocol type='raw'/>
</smartcard>
</devices>
maps to:
-usb -device usb-ccid -chardev
socket,server,host=0.0.0.0,port=2001,id=smartcard1,nowait -device
ccid-card-passthru,chardev=smartcard1
and I think it leaves the door open for:
<devices>
<channel type='spicevmc'>
<target type='vdagent'/>
</channel>
<smartcard mode='passthrough' type='spicevmc'>
<target type='smartcard'/>
</smartcard>
</devices>
to map to:
-chardev spicevmc,id=channel1,name=vdagent -device vdagent,... -usb
-device usb-ccid -chardev spicevmc,id=smartcard1,name=smartcard -device
ccid-card-passthru,chardev=smartcard1
Hopefully this will make more sense once I actually finish coding up the
RelaxNG schema validation, and propose a first round patch that
documents the proposed XML with examples.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
5:33 a.m.
New subject: [libvirt] adding smartcard support to libvirt
On Wed, Jan 05, 2011 at 02:55:55PM -0700, Eric Blake wrote:
On 01/05/2011 02:09 PM, Alon Levy wrote:
>> So, I'm thinking that this XML representation matches the spicevmc chardev:
>>
>> <devices>
>> <channel type='spicevmc'/>
>> <source port='5903' tlsPort='5904' autoport='no'
>> listen='127.0.0.1'/>
>
> I got you until now - but what's with the port/tlsPort - all of that stuff
belongs
> to the spice flag, and I'm pretty sure is already taken care of by some other
> tag (I guess <spice> probably?).
Hmm, right now, the only use of spice in XML is under <graphics
type='spice'>, and it is the <graphics> element that contains port,
tlsPort, autoport, and listen arguments. So we may need to revisit
that, and have some way to use a single location for spice parameters
shared among all spice-related devices, and a way for both <graphics
type='spice'> and <smartcard type='passthrough'> to reference
that
rather than repeating it. Meaning that spicevmc support just got more
difficult, if it involves tweaking <graphics> rather than just adding a
new <channel type='spicevmc'> element.
Are you saying that for correctness you want to tie the two elements together?
I mean, that's the only possible reason I see. If you want to tie them
together to prevent an instance of spicevmc without an instance of graphics
of type spice, I understand. I guess (after seeing the patch you sent) there
is a verifier to the xml inputs to libvirt that would be able to deduce invalidity
in that case?
Of course the alternative is to have logic elsewhere, but I see the point in
trying to verify the xml input only at one place.
> This chardev is totally separate (sure, you need
> to be using spice for it to make sense, but there is not overlap in parameters, for
> instance you don't give a port nor a tlsPort to the spicevmc chardev).
Okay, looking more at existing devices, I agree that <channel
type='spicevmc'> should only need additional attributes/sub-elements
corresponding to parameters appearing directly in the -chardev/-device
argument pair handed to qemu. So I'm not sure if <source> makes sense
any more, or if <source> would be what ends up pointing to common
details about the spice server as shared with the <graphics> element.
>
>> <target type='smartcard'/>
> This looks right.
>
>> </channel>
>> </devices>
>>
>> In looking more at libvirt XML, I don't see any fields that match id
>> assignments; rather, libvirt auto-assigns unique ids in the form %s%d,
>> category, count, where category matches <channel> and count matches how
>> many <channel> devices are present. That is, the above xml would map to:
>>
>> qemu -chardev spicevmc,id=smartcard,name=channel1
>>
> I hope you meant id=channel1,name=smartcard ? the id needs to be the same
> as the ccid-passthru uses.
Arrgh - yes, more fallout from me swapping id= and name=, and copying
and pasting from the wrong email. You already made it clear that id= is
the unique name referenced in some other -device chardev=id location,
and that for spicevmc, name= is one of two fixed values (vdagent or
smartcard).
> But I guess we determined that it's easiest to
> let the <smartcard mode="passthru"/> already add the spicevmc
chardev
> itself? the usage of "-chardev spicevmc,id=xyz,type=smartcard" is only
> for a "-device ccid-card-passthru,chardev=xyz", so one won't appear
without
> the other.
Looking even more at existing examples (can you tell that I'm trying to
learn more about existing <devices> at the same time as implementing a
new one?), I see this good example from
qemuxml2argvdata/qemuxml2argv-serial-tcp-chardev:
<serial type='tcp'>
<source mode='connect' host='127.0.0.1'
service='9999'/>
<protocol type='raw'/>
<target port='0'/>
</serial>
maps to:
-chardev socket,id=serial0,host=127.0.0.1,port=9999 -device
isa-serial,chardev=serial0
It looks like -chardev was added in qemu 0.12, and that earlier versions
used just -device without having to map things back to a chardev; but
since smartcard is post-0.12, I only need to worry about the -chardev
side of things.
>> Hmm; getting spicevmc to work seems independent enough of getting
>> <smartcard> implemented by using existing <channel
type='tcp'/>, so I'll
>> try to split my libvirt XML improvements into two batches. Should I
>> focus on <channel type='spicevmc'> or on <smartcard> first?
>
> I guess start with the smartcard first? Implement it without dealing
> with the spicevmc side - i.e. don't implement the passthru type first,
> or propose it but don't implement it. Then do the spicevmc part.
Yep, that's pretty much what I'm settling on right now - figure out how
to map <smartcard> to existing 'tcp' mapping first, then figure out
about adding spicevmc support including expanding <smartcard> to handle
spicevmc.
> I'm not particular on the order - both are required for RHEL 6.1 anyhow,
> and each is testable without the other (spicevmc with vdagent usage outlined
> above, and smartcard without spice by using it locally through libvirt).
So, back to thinking about the new <smartcard> element. The <smartcard
mode='host'> and <smartcard mode='host-certificates'> modes are
simple,
since -device ccid-card-emulated has no associated -chardev argument.
But if we go with the ideas that <smartcard mode='passthrough'> implies
-device ccid-card-passthru and an associated -chardev, and that the only
-chardev's worth pairing with a <smartcard> are tcp and spicevmc, then
it's simpler to just add a type attribute, and make <smartcard
mode='passthrough' type='tcp'> look a lot like <serial
type='tcp'> (no
<serial> sub-element, but instead have a <source> sub-element directly
resembling the <source> sub-element of serial). Meanwhile, <serial>
allows a <target> sub-element (which virtual serial port the guest will
access as the chardev), whereas <smartcard> would not (the guest sees
the smartcard via the emulated card from the usb-ccid bus, and not as a
raw serial port). Thus,
<devices>
<smartcard mode='passthrough' type='tcp'>
<source host='0.0.0.0' port='2001'/>
<protocol type='raw'/>
</smartcard>
</devices>
maps to:
-usb -device usb-ccid -chardev
socket,server,host=0.0.0.0,port=2001,id=smartcard1,nowait -device
ccid-card-passthru,chardev=smartcard1
and I think it leaves the door open for:
<devices>
<channel type='spicevmc'>
<target type='vdagent'/>
</channel>
<smartcard mode='passthrough' type='spicevmc'>
<target type='smartcard'/>
</smartcard>
</devices>
to map to:
-chardev spicevmc,id=channel1,name=vdagent -device vdagent,... -usb
-device usb-ccid -chardev spicevmc,id=smartcard1,name=smartcard -device
ccid-card-passthru,chardev=smartcard1
Hopefully this will make more sense once I actually finish coding up the
RelaxNG schema validation, and propose a first round patch that
documents the proposed XML with examples.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
9:05 a.m.
New subject: [libvirt] adding smartcard support to libvirt
On 01/06/2011 04:33 AM, Alon Levy wrote:
> Hmm, right now, the only use of spice in XML is under
<graphics
> type='spice'>, and it is the <graphics> element that contains port,
> tlsPort, autoport, and listen arguments. So we may need to revisit
> that, and have some way to use a single location for spice parameters
> shared among all spice-related devices, and a way for both <graphics
> type='spice'> and <smartcard type='passthrough'> to
reference that
> rather than repeating it. Meaning that spicevmc support just got more
> difficult, if it involves tweaking <graphics> rather than just adding a
> new <channel type='spicevmc'> element.
Are you saying that for correctness you want to tie the two elements together?
I mean, that's the only possible reason I see. If you want to tie them
together to prevent an instance of spicevmc without an instance of graphics
of type spice, I understand. I guess (after seeing the patch you sent) there
is a verifier to the xml inputs to libvirt that would be able to deduce invalidity
in that case?
Of course the alternative is to have logic elsewhere, but I see the point in
trying to verify the xml input only at one place.
I'm thinking more along the lines that the spice parameters (port,
tlsport, autoPort, listen, passwd, and child <channel> elements main,
display, inputs, cursor, playback, and record) _might_ need to be
specified independently from their current position under <graphics>,
since we are likely adding new channels. That is, I think it should be
possible to use a spicevmc agent for _just_ a smartcard channel, while
still using older vnc or other graphics, in which case specifying spice
parameters living under <graphics> doesn't make sense, but neither
should the spice parameters live under <smartcard>. For that reason, it
does seem to argue that creating a top-level <spice> element would make
sense.
However, it's a tricky proposition, because we have to maintain
backwards compatibility; so _if_ we decide that making a higher-level
<spice> element for fine-tuning spice parameters (rather than the
current approach of sticking spice parameters under <graphics>), then
yes, the XML parser will have to do consistency checks that either spice
parameters are only provided in one location, or that the multiple
locations are consistent.
At any rate, I'm not going to give spicevmc much further thought until I
first get <smartcard> with tcp passthru working, so it may be a few more
days before I reply any further on this portion of the thread.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
9:19 a.m.
New subject: [libvirt] adding smartcard support to libvirt
On Thu, Jan 06, 2011 at 08:05:55AM -0700, Eric Blake wrote:
On 01/06/2011 04:33 AM, Alon Levy wrote:
>> Hmm, right now, the only use of spice in XML is under <graphics
>> type='spice'>, and it is the <graphics> element that contains
port,
>> tlsPort, autoport, and listen arguments. So we may need to revisit
>> that, and have some way to use a single location for spice parameters
>> shared among all spice-related devices, and a way for both <graphics
>> type='spice'> and <smartcard type='passthrough'> to
reference that
>> rather than repeating it. Meaning that spicevmc support just got more
>> difficult, if it involves tweaking <graphics> rather than just adding a
>> new <channel type='spicevmc'> element.
>
> Are you saying that for correctness you want to tie the two elements together?
> I mean, that's the only possible reason I see. If you want to tie them
> together to prevent an instance of spicevmc without an instance of graphics
> of type spice, I understand. I guess (after seeing the patch you sent) there
> is a verifier to the xml inputs to libvirt that would be able to deduce invalidity
> in that case?
> Of course the alternative is to have logic elsewhere, but I see the point in
> trying to verify the xml input only at one place.
I'm thinking more along the lines that the spice parameters (port,
tlsport, autoPort, listen, passwd, and child <channel> elements main,
display, inputs, cursor, playback, and record) _might_ need to be
specified independently from their current position under <graphics>,
since we are likely adding new channels. That is, I think it should be
possible to use a spicevmc agent for _just_ a smartcard channel, while
still using older vnc or other graphics, in which case specifying spice
parameters living under <graphics> doesn't make sense, but neither
should the spice parameters live under <smartcard>. For that reason, it
does seem to argue that creating a top-level <spice> element would make
sense.
The primary reason for the tunnelling, is that it directly associates
the smartcard with your current remote desktop client. If you're not
using SPICE for the remote desktop, then there's no value in using
it for the smartcard.
NB, it is possible to configured multiple display protocols at the
same time (eg multiple <graphics> elements) but we've not supported
that in the QEMU driver yet. This would let you configure both VNC
and SPICE at the same time.
However, it's a tricky proposition, because we have to maintain
backwards compatibility; so _if_ we decide that making a higher-level
<spice> element for fine-tuning spice parameters (rather than the
current approach of sticking spice parameters under <graphics>), then
yes, the XML parser will have to do consistency checks that either spice
parameters are only provided in one location, or that the multiple
locations are consistent.
As above, I don't think a <spice> element makes sense. The use of a
<graphics type=spice> element is the primary enabler. Only once you
have that, does it make sense to want to associate further devices
with that mechanism
Regards,
Daniel
5:59 p.m.
New subject: [libvirt] adding smartcard support to libvirt
On 01/03/2011 11:50 AM, Eric Blake wrote:
<domain...>
<devices>
<smartcard mode='host-certificates'>
<certificate id='1' path='cert1'/>
<certificate id='2' path='cert2'/>
<certificate id='3' path='cert3'/>
</smartcard>
</devices>
</domain>
Slight tweak - filenames can be arbitrary, so they have to be nested
text rather than attributes. Also, we know there are exactly three, and
can use them in listed order, without having to require an extra id
attribute. And absolute paths may make more sense (since a libvirt user
can't be sure what a relative path is relative to). Leading to:
<domain...>
<devices>
<smartcard mode='host-certificates'>
<certificate>path='/path/to/cert1'</certificate>
<certificate>path='/path/to/cert2'</certificate>
<certificate>path='/path/to/cert3'</certificate>
</smartcard>
</devices>
</domain>
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
6 p.m.
New subject: [libvirt] adding smartcard support to libvirt
On 01/05/2011 04:59 PM, Eric Blake wrote:
On 01/03/2011 11:50 AM, Eric Blake wrote:
> <domain...>
> <devices>
> <smartcard mode='host-certificates'>
> <certificate id='1' path='cert1'/>
> <certificate id='2' path='cert2'/>
> <certificate id='3' path='cert3'/>
> </smartcard>
> </devices>
> </domain>
Slight tweak - filenames can be arbitrary, so they have to be nested
text rather than attributes. Also, we know there are exactly three, and
can use them in listed order, without having to require an extra id
attribute. And absolute paths may make more sense (since a libvirt user
can't be sure what a relative path is relative to). Leading to:
<certificate>path='/path/to/cert1'</certificate>
Hit send too soon; I meant to strip the path=' and ' portions.
<domain...>
<devices>
<smartcard mode='host-certificates'>
<certificate>/path/to/cert1</certificate>
<certificate>/path/to/cert2</certificate>
<certificate>/path/to/cert3</certificate>
</smartcard>
</devices>
</domain>
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
7:12 p.m.
New subject: [libvirt] [RFC: PATCH 1/n] smartcard: add XML support for <smartcard> device
Assuming a hypervisor that supports multiple smartcard devices in the
guest, this would be a valid XML description:
<devices>
<smartcard mode='host'/>
<smartcard mode='host-certificates'>
<certificate>/path/to/cert1</certificate>
<certificate>/path/to/cert2</certificate>
<certificate>/path/to/cert3</certificate>
</smartcard>
<smartcard mode='passthrough' type='tcp'>
<source mode='connect' host='127.0.0.1'
service='2001'/>
<protocol type='raw'/>
</smartcard>
</devices>
* docs/formatdomain.html.in (Smartcard devices): New section.
* docs/schemas/domain.rng (smartcard): New define, used in
devices.
* tests/qemuxml2argvdata/qemuxml2argv-smartcard-host.xml: New file
to test schema.
* tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.xml:
Likewise.
* tests/qemuxml2argvdata/qemuxml2argv-smartcard-passthrough-tcp.xml:
Likewise.
---
Figuring it's easier to discuss alternatives with a documentation
patch in hand, here's what I've got so far. My next task is to
update conf/domain_conf.c to parse the new XML, then to teach
qemu/qemu_command.c how to represent it on the command line.
After that, I'll revisit figuring out how to support spicevmc
chardevs, for both vdagent and smartcard.
It looks like 'virsh domxml-from-native qemu-argv file' has
suffered some bit-rot, as it doesn't know how to parse existing
-chardev/-device pairings from valid qemu 0.12+ command lines;
so for now I will focus on the XML->native direction, and leave
improvements to the native->XML direction for another day.
docs/formatdomain.html.in | 72 ++++++++++++++++++++
docs/schemas/domain.rng | 35 ++++++++++
.../qemuxml2argv-smartcard-host-certificates.xml | 20 ++++++
.../qemuxml2argv-smartcard-host.xml | 16 +++++
.../qemuxml2argv-smartcard-passthrough-tcp.xml | 19 +++++
5 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-host.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-passthrough-tcp.xml
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index e9fcea1..bf46106 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -799,6 +799,78 @@
not used by qemu.</dd>
</dl>
+ <h4><a name="elementsSmartcard">Smartcard
devices</a></h4>
+
+ <p>
+ A virtual smartcard device can be supplied to the guest via the
+ <code>smartcard</code> element. A USB smartcard reader device on
+ the host cannot be used on a guest with simple device
+ passthrough, since it will then not be available on the host,
+ possibly locking the host computer when it is "removed".
+ Therefore, some hypervisors provide a specialized virtual device
+ that can present a smartcard interface to the guest, with
+ several modes for describing how credentials are obtained from
+ the host or even a from a channel created to a third-party
+ smartcard provider. <span class="since">Since 0.8.8</span>
+ </p>
+
+<pre>
+ ...
+ <devices>
+ <smartcard mode='host'/>
+ <smartcard mode='host-certificates'>
+ <certificate>/path/to/cert1</certificate>
+ <certificate>/path/to/cert2</certificate>
+ <certificate>/path/to/cert3</certificate>
+ </smartcard>
+ <smartcard mode='passthrough' type='tcp'>
+ <source mode='connect' host='127.0.0.1'
service='2001'/>
+ <protocol type='raw'/>
+ </smartcard>
+ </devices>
+ ...
+</pre>
+
+ <p>
+ The <code><smartcard></code> element has a mandatory
+ attribute <code>mode</code>. The following modes are supported;
+ in each mode, the guest sees a device on its USB bus that
+ behaves like a physical USB CCID (Chip/Smart Card Interface
+ Device) card.
+ </p>
+
+ <ul>
+ <li><code>mode='host'</code> — the simplest
operation,
+ where the hypervisor relays all requests from the guest into
+ direct access to the host's smartcard via NSS. No other
+ attributes or sub-elements are required.</li>
+
+ <li><code>mode='host-certificates'</code> —
rather than
+ requiring a smartcard to be plugged into the host, it is
+ possible to provide three files residing on the host and
+ containing NSS certificates. These certificates can be
+ generated via the command <code>certutil -d /etc/pki/nssdb -x -t
+ CT,CT,CT -S -s CN=cert1 -n cert1</code>, and the resulting three
+ files must be supplied as the content of each of
+ three <code><certificate></code>
sub-elements.</li>
+
+ <li><code>mode='passthrough'</code> — rather
than having
+ the hypervisor directly communicate with the host, it is
+ possible to tunnel all requests through a secondary character
+ device to a third-party provider (which may in turn be talking
+ to a smartcard or using three certificate files). In this mode
+ of operation, an additional attribute <code>type</code> is
+ required, which matches the types of one of the
+ supported <a href="#elementsConsole">serial devices</a>.
+ Further sub-elements, such as <code><source></code> are
+ required according to the given type, although
+ a <code><target></code> sub-element is not required
(since
+ the consumer of the character device is the hypervisor itself,
+ rather than a device visible in the guest). Use
+ of <code>type='tcp'</code> is most common.</li>
+ </ul>
+
+
<h4><a name="elementsNICS">Network
interfaces</a></h4>
<pre>
diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
index a524e4b..385d1b6 100644
--- a/docs/schemas/domain.rng
+++ b/docs/schemas/domain.rng
@@ -1579,6 +1579,40 @@
</interleave>
</element>
</define>
+ <define name="smartcard">
+ <element name="smartcard">
+ <choice>
+ <attribute name="mode">
+ <value>host</value>
+ </attribute>
+ <group>
+ <attribute name="mode">
+ <value>host-certificates</value>
+ </attribute>
+ <ref name='certificate'/>
+ <ref name='certificate'/>
+ <ref name='certificate'/>
+ </group>
+ <group>
+ <attribute name="mode">
+ <value>passthrough</value>
+ </attribute>
+ <ref name="qemucdevSrcType"/>
+ <interleave>
+ <ref name="qemucdevSrcDef"/>
+ <optional>
+ <ref name="qemucdevTgtDef"/>
+ </optional>
+ </interleave>
+ </group>
+ </choice>
+ </element>
+ </define>
+ <define name="certificate">
+ <element name="certificate">
+ <ref name="absFilePath"/>
+ </element>
+ </define>
<define name="input">
<element name="input">
<attribute name="type">
@@ -1736,6 +1770,7 @@
<ref name="parallel"/>
<ref name="serial"/>
<ref name="channel"/>
+ <ref name="smartcard"/>
</choice>
</zeroOrMore>
<optional>
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.xml
b/tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.xml
new file mode 100644
index 0000000..f70395d
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.xml
@@ -0,0 +1,20 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory>219200</memory>
+ <currentMemory>219200</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='i686' machine='pc'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <devices>
+ <emulator>/usr/bin/qemu</emulator>
+ <smartcard mode='host-certificates'>
+ <certificate>/etc/pki/cert1</certificate>
+ <certificate>/etc/pki/cert2</certificate>
+ <certificate>/etc/pki/cert3</certificate>
+ </smartcard>
+ <memballoon model='virtio'/>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-smartcard-host.xml
b/tests/qemuxml2argvdata/qemuxml2argv-smartcard-host.xml
new file mode 100644
index 0000000..faa2231
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-smartcard-host.xml
@@ -0,0 +1,16 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory>219200</memory>
+ <currentMemory>219200</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='i686' machine='pc'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <devices>
+ <emulator>/usr/bin/qemu</emulator>
+ <smartcard mode='host'/>
+ <memballoon model='virtio'/>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-smartcard-passthrough-tcp.xml
b/tests/qemuxml2argvdata/qemuxml2argv-smartcard-passthrough-tcp.xml
new file mode 100644
index 0000000..8e2fa52
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-smartcard-passthrough-tcp.xml
@@ -0,0 +1,19 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory>219200</memory>
+ <currentMemory>219200</currentMemory>
+ <vcpu>1</vcpu>
+ <os>
+ <type arch='i686' machine='pc'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <devices>
+ <emulator>/usr/bin/qemu</emulator>
+ <smartcard mode='passthrough' type='tcp'>
+ <source mode='connect' host='127.0.0.1'
service='2001'/>
+ <protocol type='raw'/>
+ </smartcard>
+ <memballoon model='virtio'/>
+ </devices>
+</domain>
--
1.7.3.4
5069
days inactive
5072
days old
10 comments
3 participants
participants (3)
-
Alon Levy -
Daniel P. Berrange -
Eric Blake