The VFIO PCI ABI has been extended to require userspace PF driver to set 
a VF token to a known value. The VF drivers are then required to provide
this token to access the VF device. The vf-token is set by the PF driver
before VF drivers can access the device. The kernel provides no means to
retrieve the token in use; but there is no specification describing the 
distribution or level of confidentiality of the token.  Qemu has been 
extended to require the vf-token when vf device is used. An important 
point to note is that the vf-token is required only when both the PF and
VF are used in userspace. 

This patch series adds support to provide the vf-token (uuid format) in the
domain XML and to generate the qemu commandline including the vf-token.

To support vf-token the new element will be used as follows:
   <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x0' slot='0x00' function='0x1'>
        <vf-token uuid='00112233-4455-6677-8899-aabbccddeeff'/>
        </address>
      </source>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </hostdev>

The generated commandline will include the following:

-device {"driver":"vfio-pci","host":"0000:00:0.1",
         "vf-token":"00112233-4455-6677-8899-aabbccddeeff",
         "id":"hostdev0","bus":"pci.0","addr":"0x1"}

Changes since initial RFC based on review comments received:
1. Added documentation
2. Added test cases and ran successful test suite after each patch commit
3. fixed spaces, coding sytle, and uuid string format 
4. Used S:vftoken in virJSONValueObjectAdd instead of a conditional

Vivek Kashyap (8):
  Define the vf-token extension for PCI device
  Introduce the vf-token qemu capability
  This patch introduces the PCI address extension flag for vf-token
  This patch introduces new XML parser/formatter functions for parsing
    the vf-token
  Introduce a validation function for vf-token support in qemu and
    generate vf-token device attribute in qemu command line
  Provide information about the vf-token flag
  Add tests for the vf-token flag to the qemuxml2argv and qemuxml2xml
    test suites
  Update news about vf-token

 NEWS.rst                                      |  8 +++
 docs/formatdomain.rst                         |  3 ++
 src/conf/device_conf.c                        | 49 ++++++++++++++++---
 src/conf/domain_addr.h                        |  1 +
 src/conf/domain_conf.c                        |  8 +++
 src/conf/schemas/basictypes.rng               |  7 +++
 src/libvirt_private.syms                      |  1 +
 src/qemu/qemu_capabilities.c                  |  3 ++
 src/qemu/qemu_capabilities.h                  |  1 +
 src/qemu/qemu_command.c                       |  8 +++
 src/qemu/qemu_domain_address.c                |  3 ++
 src/qemu/qemu_validate.c                      | 20 ++++++++
 src/util/virpci.c                             |  7 +++
 src/util/virpci.h                             | 10 ++++
 .../qemucapabilitiesdata/caps_8.1.0_s390x.xml |  1 +
 .../caps_8.1.0_x86_64.xml                     |  1 +
 .../caps_8.2.0_x86_64.xml                     |  1 +
 .../hostdev-vfio-vf-token.x86_64-latest.args  | 34 +++++++++++++
 .../hostdev-vfio-vf-token.xml                 | 22 +++++++++
 tests/qemuxml2argvtest.c                      |  1 +
 .../hostdev-vfio-vf-token.x86_64-latest.xml   | 40 +++++++++++++++
 tests/qemuxml2xmltest.c                       |  1 +
 22 files changed, 223 insertions(+), 7 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml
 create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-vf-token.x86_64-latest.xml

-- 
2.33.8
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Tue,  2 Jan 2024 18:55:10 +0530
Vivek Kashyap <vivek.kashyap@linux.intel.com> wrote:

> The VFIO PCI ABI has been extended to require userspace PF driver to set 
> a VF token to a known value. The VF drivers are then required to provide
> this token to access the VF device. The vf-token is set by the PF driver
> before VF drivers can access the device. The kernel provides no means to
> retrieve the token in use; but there is no specification describing the 
> distribution or level of confidentiality of the token.

At the same time, both the kernel and this series indicate the token is
a shared secret, which is the reason the kernel provides no means to
access the token.  Is it reasonable to have a secret shared token in
xml, logs, and QEMU command line?  The token is shared between all VFs
associated to a PF, so as this support more formally moves from a QEMU
one-off hack to libvirt support, are we revealing a secret by promoting
this model?

Furthermore, libvirt has always been able to consider the vfio-pci
device trusted, at least so far as it's provided by a kernel driver.
With VF token support, the VF driver itself may still be a kernel
driver, but the PF is managed via a userspace driver with unknown
capabilities relative to the integrity of the VF device.  I don't know
if we need to or how we take into account that lack of device
authentication.  Certainly without some degree of attestation of the PF
driver and VF token, or potentially a mechanism for a more
cryptographic statement of trust, such a device ought not to be
involved with a confidential VM.

I'm not sure what needs to be done here, maybe the device level trust
is a problem for a higher level management tool, but I'd like to take a
more thoughtful look at the implications of VF token support as we move
up the stack rather than position this as simply filling a gap in QEMU
vfio-pci support.  Thanks,

Alex

> Qemu has been 
> extended to require the vf-token when vf device is used. An important 
> point to note is that the vf-token is required only when both the PF and
> VF are used in userspace. 
> 
> This patch series adds support to provide the vf-token (uuid format) in the
> domain XML and to generate the qemu commandline including the vf-token.
> 
> To support vf-token the new element will be used as follows:
>    <hostdev mode='subsystem' type='pci' managed='yes'>
>       <driver name='vfio'/>
>       <source>
>         <address domain='0x0000' bus='0x0' slot='0x00' function='0x1'>
>         <vf-token uuid='00112233-4455-6677-8899-aabbccddeeff'/>
>         </address>
>       </source>
>      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
>     </hostdev>
> 
> The generated commandline will include the following:
> 
> -device {"driver":"vfio-pci","host":"0000:00:0.1",
>          "vf-token":"00112233-4455-6677-8899-aabbccddeeff",
>          "id":"hostdev0","bus":"pci.0","addr":"0x1"}
> 
> Changes since initial RFC based on review comments received:
> 1. Added documentation
> 2. Added test cases and ran successful test suite after each patch commit
> 3. fixed spaces, coding sytle, and uuid string format 
> 4. Used S:vftoken in virJSONValueObjectAdd instead of a conditional
> 
> Vivek Kashyap (8):
>   Define the vf-token extension for PCI device
>   Introduce the vf-token qemu capability
>   This patch introduces the PCI address extension flag for vf-token
>   This patch introduces new XML parser/formatter functions for parsing
>     the vf-token
>   Introduce a validation function for vf-token support in qemu and
>     generate vf-token device attribute in qemu command line
>   Provide information about the vf-token flag
>   Add tests for the vf-token flag to the qemuxml2argv and qemuxml2xml
>     test suites
>   Update news about vf-token
> 
>  NEWS.rst                                      |  8 +++
>  docs/formatdomain.rst                         |  3 ++
>  src/conf/device_conf.c                        | 49 ++++++++++++++++---
>  src/conf/domain_addr.h                        |  1 +
>  src/conf/domain_conf.c                        |  8 +++
>  src/conf/schemas/basictypes.rng               |  7 +++
>  src/libvirt_private.syms                      |  1 +
>  src/qemu/qemu_capabilities.c                  |  3 ++
>  src/qemu/qemu_capabilities.h                  |  1 +
>  src/qemu/qemu_command.c                       |  8 +++
>  src/qemu/qemu_domain_address.c                |  3 ++
>  src/qemu/qemu_validate.c                      | 20 ++++++++
>  src/util/virpci.c                             |  7 +++
>  src/util/virpci.h                             | 10 ++++
>  .../qemucapabilitiesdata/caps_8.1.0_s390x.xml |  1 +
>  .../caps_8.1.0_x86_64.xml                     |  1 +
>  .../caps_8.2.0_x86_64.xml                     |  1 +
>  .../hostdev-vfio-vf-token.x86_64-latest.args  | 34 +++++++++++++
>  .../hostdev-vfio-vf-token.xml                 | 22 +++++++++
>  tests/qemuxml2argvtest.c                      |  1 +
>  .../hostdev-vfio-vf-token.x86_64-latest.xml   | 40 +++++++++++++++
>  tests/qemuxml2xmltest.c                       |  1 +
>  22 files changed, 223 insertions(+), 7 deletions(-)
>  create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args
>  create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml
>  create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-vf-token.x86_64-latest.xml
> 
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Tue, 2 Jan 2024, Alex Williamson wrote:

> On Tue,  2 Jan 2024 18:55:10 +0530
> Vivek Kashyap <vivek.kashyap@linux.intel.com> wrote:
>
>> The VFIO PCI ABI has been extended to require userspace PF driver to set
>> a VF token to a known value. The VF drivers are then required to provide
>> this token to access the VF device. The vf-token is set by the PF driver
>> before VF drivers can access the device. The kernel provides no means to
>> retrieve the token in use; but there is no specification describing the
>> distribution or level of confidentiality of the token.
>
> At the same time, both the kernel and this series indicate the token is
> a shared secret, which is the reason the kernel provides no means to
> access the token.  Is it reasonable to have a secret shared token in
> xml, logs, and QEMU command line?  The token is shared between all VFs
> associated to a PF, so as this support more formally moves from a QEMU
> one-off hack to libvirt support, are we revealing a secret by promoting
> this model?

The level of confidentiality has been left open in the vf-token 
implementation across kernel and qemu. Perhaps we need to find a way to 
allow a higher level solution to restrict/tighten it further based on 
a policy. I don't immediately have a suggestion on how.

Until then the problem is that we are unable to launch the VMs when the PF 
is in the uesrspace. For now this patch is only bridging the gap to qemu 
commandline.

-vk

>
> Furthermore, libvirt has always been able to consider the vfio-pci
> device trusted, at least so far as it's provided by a kernel driver.
> With VF token support, the VF driver itself may still be a kernel
> driver, but the PF is managed via a userspace driver with unknown
> capabilities relative to the integrity of the VF device.  I don't know
> if we need to or how we take into account that lack of device
> authentication.  Certainly without some degree of attestation of the PF
> driver and VF token, or potentially a mechanism for a more
> cryptographic statement of trust, such a device ought not to be
> involved with a confidential VM.
>
> I'm not sure what needs to be done here, maybe the device level trust
> is a problem for a higher level management tool, but I'd like to take a
> more thoughtful look at the implications of VF token support as we move
> up the stack rather than position this as simply filling a gap in QEMU
> vfio-pci support.  Thanks,
>
> Alex
>
>> Qemu has been
>> extended to require the vf-token when vf device is used. An important
>> point to note is that the vf-token is required only when both the PF and
>> VF are used in userspace.
>>
>> This patch series adds support to provide the vf-token (uuid format) in the
>> domain XML and to generate the qemu commandline including the vf-token.
>>
>> To support vf-token the new element will be used as follows:
>>    <hostdev mode='subsystem' type='pci' managed='yes'>
>>       <driver name='vfio'/>
>>       <source>
>>         <address domain='0x0000' bus='0x0' slot='0x00' function='0x1'>
>>         <vf-token uuid='00112233-4455-6677-8899-aabbccddeeff'/>
>>         </address>
>>       </source>
>>      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
>>     </hostdev>
>>
>> The generated commandline will include the following:
>>
>> -device {"driver":"vfio-pci","host":"0000:00:0.1",
>>          "vf-token":"00112233-4455-6677-8899-aabbccddeeff",
>>          "id":"hostdev0","bus":"pci.0","addr":"0x1"}
>>
>> Changes since initial RFC based on review comments received:
>> 1. Added documentation
>> 2. Added test cases and ran successful test suite after each patch commit
>> 3. fixed spaces, coding sytle, and uuid string format
>> 4. Used S:vftoken in virJSONValueObjectAdd instead of a conditional
>>
>> Vivek Kashyap (8):
>>   Define the vf-token extension for PCI device
>>   Introduce the vf-token qemu capability
>>   This patch introduces the PCI address extension flag for vf-token
>>   This patch introduces new XML parser/formatter functions for parsing
>>     the vf-token
>>   Introduce a validation function for vf-token support in qemu and
>>     generate vf-token device attribute in qemu command line
>>   Provide information about the vf-token flag
>>   Add tests for the vf-token flag to the qemuxml2argv and qemuxml2xml
>>     test suites
>>   Update news about vf-token
>>
>>  NEWS.rst                                      |  8 +++
>>  docs/formatdomain.rst                         |  3 ++
>>  src/conf/device_conf.c                        | 49 ++++++++++++++++---
>>  src/conf/domain_addr.h                        |  1 +
>>  src/conf/domain_conf.c                        |  8 +++
>>  src/conf/schemas/basictypes.rng               |  7 +++
>>  src/libvirt_private.syms                      |  1 +
>>  src/qemu/qemu_capabilities.c                  |  3 ++
>>  src/qemu/qemu_capabilities.h                  |  1 +
>>  src/qemu/qemu_command.c                       |  8 +++
>>  src/qemu/qemu_domain_address.c                |  3 ++
>>  src/qemu/qemu_validate.c                      | 20 ++++++++
>>  src/util/virpci.c                             |  7 +++
>>  src/util/virpci.h                             | 10 ++++
>>  .../qemucapabilitiesdata/caps_8.1.0_s390x.xml |  1 +
>>  .../caps_8.1.0_x86_64.xml                     |  1 +
>>  .../caps_8.2.0_x86_64.xml                     |  1 +
>>  .../hostdev-vfio-vf-token.x86_64-latest.args  | 34 +++++++++++++
>>  .../hostdev-vfio-vf-token.xml                 | 22 +++++++++
>>  tests/qemuxml2argvtest.c                      |  1 +
>>  .../hostdev-vfio-vf-token.x86_64-latest.xml   | 40 +++++++++++++++
>>  tests/qemuxml2xmltest.c                       |  1 +
>>  22 files changed, 223 insertions(+), 7 deletions(-)
>>  create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args
>>  create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml
>>  create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-vf-token.x86_64-latest.xml
>>
>
>
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Wed, Jan 03, 2024 at 22:42:41 +0530, Vivek Kashyap wrote:
> 
> 
> On Tue, 2 Jan 2024, Alex Williamson wrote:
> 
> > On Tue,  2 Jan 2024 18:55:10 +0530
> > Vivek Kashyap <vivek.kashyap@linux.intel.com> wrote:
> > 
> > > The VFIO PCI ABI has been extended to require userspace PF driver to set
> > > a VF token to a known value. The VF drivers are then required to provide
> > > this token to access the VF device. The vf-token is set by the PF driver
> > > before VF drivers can access the device. The kernel provides no means to
> > > retrieve the token in use; but there is no specification describing the
> > > distribution or level of confidentiality of the token.
> > 
> > At the same time, both the kernel and this series indicate the token is
> > a shared secret, which is the reason the kernel provides no means to
> > access the token.  Is it reasonable to have a secret shared token in
> > xml, logs, and QEMU command line?  The token is shared between all VFs
> > associated to a PF, so as this support more formally moves from a QEMU
> > one-off hack to libvirt support, are we revealing a secret by promoting
> > this model?
> 
> The level of confidentiality has been left open in the vf-token
> implementation across kernel and qemu. Perhaps we need to find a way to
> allow a higher level solution to restrict/tighten it further based on a
> policy. I don't immediately have a suggestion on how.

If there is even a slight expectation of confidentiality (IMO just
calling it a 'secret' in documentation is enough to justify that
expectation) it should be treated as such.

Thus qemu needs to add the possibility to pass it via the 'secret'
object, so that libvirt can pass it encrypted. On the device commandline
we'll just pass the alias to the secret.

There's a well documented and maintained way to do that so it should be
a very straightforward and quick modification.

> Until then the problem is that we are unable to launch the VMs when the PF
> is in the uesrspace. For now this patch is only bridging the gap to qemu
> commandline.

The above should be done prior doing this in libvirt so that we can use
the new approach without having any duplicate code.
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

>
> If there is even a slight expectation of confidentiality (IMO just
> calling it a 'secret' in documentation is enough to justify that
> expectation) it should be treated as such.
>
> Thus qemu needs to add the possibility to pass it via the 'secret'
> object, so that libvirt can pass it encrypted. On the device commandline
> we'll just pass the alias to the secret.
>
> There's a well documented and maintained way to do that so it should be
> a very straightforward and quick modification.
>
>> Until then the problem is that we are unable to launch the VMs when the PF
>> is in the uesrspace. For now this patch is only bridging the gap to qemu
>> commandline.
>
> The above should be done prior doing this in libvirt so that we can use
> the new approach without having any duplicate code.
>

Yes, that sounds good. We need to add the mechanism to pass the vf-token via
a secret object. However, until it is done we are unable to proceed with our
VMs with PF in the userspace unless we provide the vf-token as in this series.

So for now either 
a) the qemu commit needs to be revert (so that we can continue without
    providing vf-token uuid), OR
b) We add libvirt support for clear-text vf-token, then add the choice to
    qemu to additionally provide the vf-token via a secret object and then
    update libvirt to pass the encrypted secret.

-vk
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Mon, Jan 08, 2024 at 17:05:45 +0530, Vivek Kashyap wrote:
> > 
> > If there is even a slight expectation of confidentiality (IMO just
> > calling it a 'secret' in documentation is enough to justify that
> > expectation) it should be treated as such.
> > 
> > Thus qemu needs to add the possibility to pass it via the 'secret'
> > object, so that libvirt can pass it encrypted. On the device commandline
> > we'll just pass the alias to the secret.
> > 
> > There's a well documented and maintained way to do that so it should be
> > a very straightforward and quick modification.
> > 
> > > Until then the problem is that we are unable to launch the VMs when the PF
> > > is in the uesrspace. For now this patch is only bridging the gap to qemu
> > > commandline.
> > 
> > The above should be done prior doing this in libvirt so that we can use
> > the new approach without having any duplicate code.
> > 
> 
> Yes, that sounds good. We need to add the mechanism to pass the vf-token via
> a secret object. However, until it is done we are unable to proceed with our
> VMs with PF in the userspace unless we provide the vf-token as in this series.
> 
> So for now either a) the qemu commit needs to be revert (so that we can
> continue without
>    providing vf-token uuid), OR
> b) We add libvirt support for clear-text vf-token, then add the choice to
>    qemu to additionally provide the vf-token via a secret object and then
>    update libvirt to pass the encrypted secret.

As I've stated above, for libvirt we should consider only passing it via
the 'secret' object.
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Mon, Jan 08, 2024 at 12:44:01 +0100, Peter Krempa wrote:
> On Mon, Jan 08, 2024 at 17:05:45 +0530, Vivek Kashyap wrote:
> > > 
> > > If there is even a slight expectation of confidentiality (IMO just
> > > calling it a 'secret' in documentation is enough to justify that
> > > expectation) it should be treated as such.
> > > 
> > > Thus qemu needs to add the possibility to pass it via the 'secret'
> > > object, so that libvirt can pass it encrypted. On the device commandline
> > > we'll just pass the alias to the secret.
> > > 
> > > There's a well documented and maintained way to do that so it should be
> > > a very straightforward and quick modification.
> > > 
> > > > Until then the problem is that we are unable to launch the VMs when the PF
> > > > is in the uesrspace. For now this patch is only bridging the gap to qemu
> > > > commandline.
> > > 
> > > The above should be done prior doing this in libvirt so that we can use
> > > the new approach without having any duplicate code.
> > > 
> > 
> > Yes, that sounds good. We need to add the mechanism to pass the vf-token via
> > a secret object. However, until it is done we are unable to proceed with our
> > VMs with PF in the userspace unless we provide the vf-token as in this series.
> > 
> > So for now either a) the qemu commit needs to be revert (so that we can
> > continue without
> >    providing vf-token uuid), OR
> > b) We add libvirt support for clear-text vf-token, then add the choice to
> >    qemu to additionally provide the vf-token via a secret object and then
> >    update libvirt to pass the encrypted secret.
> 
> As I've stated above, for libvirt we should consider only passing it via
> the 'secret' object.

Forgot to add:

If you need a way to test it with a libvirt-started VM in the interim
until the qemu commandline configuration accepts secrets (which should
be fairly trivial, and we will accept patches based on qemu code
which was pushed but not released yet) you can use device-property
overrides:

https://libvirt.org/drvqemu.html#overriding-properties-of-qemu-devices

note that it has the same implications about supportability as using
commandline overrides:

https://libvirt.org/drvqemu.html#pass-through-of-arbitrary-qemu-commands
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

...
>> As I've stated above, for libvirt we should consider only passing it via
>> the 'secret' object.

Sounds good.  Will follow this up.

Alex - will you be working on the qemu update?
>
> Forgot to add:
>
> If you need a way to test it with a libvirt-started VM in the interim
> until the qemu commandline configuration accepts secrets (which should
> be fairly trivial, and we will accept patches based on qemu code
> which was pushed but not released yet) you can use device-property
> overrides:
>
> https://libvirt.org/drvqemu.html#overriding-properties-of-qemu-devices
>
> note that it has the same implications about supportability as using
> commandline overrides:
>
> https://libvirt.org/drvqemu.html#pass-through-of-arbitrary-qemu-commands
>

Thanks for the pointer. Will try it out.

-vk
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Mon, 8 Jan 2024 18:42:19 +0530 (IST)
Vivek Kashyap <vivek.kashyap@linux.intel.com> wrote:

> ...
> >> As I've stated above, for libvirt we should consider only passing it via
> >> the 'secret' object.  
> 
> Sounds good.  Will follow this up.
> 
> Alex - will you be working on the qemu update?

I'm not the one driving a use case that requires libvirt support for
vf-token.  Thanks,

Alex
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Mon, 8 Jan 2024, Alex Williamson wrote:

> On Mon, 8 Jan 2024 18:42:19 +0530 (IST)
> Vivek Kashyap <vivek.kashyap@linux.intel.com> wrote:
>
>> ...
>>>> As I've stated above, for libvirt we should consider only passing it via
>>>> the 'secret' object.
>>
>> Sounds good.  Will follow this up.
>>
>> Alex - will you be working on the qemu update?
>
> I'm not the one driving a use case that requires libvirt support for
> vf-token.  Thanks,

Not asking wrt libvirt but queried wrt qemu due to your original
implementation in qemu:

https://lore.kernel.org/lkml/20200204161737.34696b91@w520.home
https://github.com/qemu/qemu/commit/2dca1b37a7605abb135559ef1b0d63929e7ae60d

thanks
vk
>
> Alex
>
>
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Mon, 8 Jan 2024 23:32:04 +0530 (IST)
Vivek Kashyap <vivek.kashyap@linux.intel.com> wrote:

> On Mon, 8 Jan 2024, Alex Williamson wrote:
> 
> > On Mon, 8 Jan 2024 18:42:19 +0530 (IST)
> > Vivek Kashyap <vivek.kashyap@linux.intel.com> wrote:
> >  
> >> ...  
> >>>> As I've stated above, for libvirt we should consider only passing it via
> >>>> the 'secret' object.  
> >>
> >> Sounds good.  Will follow this up.
> >>
> >> Alex - will you be working on the qemu update?  
> >
> > I'm not the one driving a use case that requires libvirt support for
> > vf-token.  Thanks,  
> 
> Not asking wrt libvirt but queried wrt qemu due to your original
> implementation in qemu:
> 
> https://lore.kernel.org/lkml/20200204161737.34696b91@w520.home
> https://github.com/qemu/qemu/commit/2dca1b37a7605abb135559ef1b0d63929e7ae60d

Per the first link:

    NB. It's unclear whether there's value to this QEMU support without
    further exposure of SR-IOV within a VM.  This is meant mostly as a
    test case where the real initial users will likely be DPDK drivers.

I didn't author the commit in the second link.

Based on the above comment it's clear that QEMU, or any VMM use case,
was not the initial target for vf-token support.  It was intended for
DPDK, which already has a pretty low security model.  QEMU was only a
proof of concept with a code base more familiar to me.

I also noted in the above my expectation that SR-IOV would be the
legitimate use case in QEMU.  My thought there was that QEMU would set
a private vf-token and emulate an SR-IOV capability to the guest.
Enabling SR-IOV by the guest would trigger a call-out to libvirt to
effect the change via host pci-sysfs and attach the resulting VFs back
to the VM.  The vf-token would remain private and act as a measure of
protection against other use cases for the VFs.

I've never been strongly in favor of general vf-token support in QEMU.
If a VF requires a vf-token, then by definition the PF is being managed
by another vfio userspace driver.  Somebody needs to decide whether
that userspace driver is trustworthy since it may have access to all
the data accessible to the VF.  An in-kernel PF driver would be trusted
by default, so what's the underlying motivation to make vf-token
support more ubiquitous through the stack?

In my view, this support attempts to de-emphasize the security risk of
a 3rd party userspace PF driver while also promoting their very
existence.  I won't deny that use cases for this exist, but I have yet
to see evidence that those are use cases I care to promote.  So no, I
won't be implementing a secret object implementation of this in QEMU.
Thanks,

Alex
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Mon, 8 Jan 2024, Alex Williamson wrote:

> On Mon, 8 Jan 2024 23:32:04 +0530 (IST)
> Vivek Kashyap <vivek.kashyap@linux.intel.com> wrote:
>
>> On Mon, 8 Jan 2024, Alex Williamson wrote:
>>
>>> On Mon, 8 Jan 2024 18:42:19 +0530 (IST)
>>> Vivek Kashyap <vivek.kashyap@linux.intel.com> wrote:
>>>
>>>> ...
>>>>>> As I've stated above, for libvirt we should consider only passing it via
>>>>>> the 'secret' object.
>>>>
>>>> Sounds good.  Will follow this up.
>>>>
>>>> Alex - will you be working on the qemu update?
>>>
>>> I'm not the one driving a use case that requires libvirt support for
>>> vf-token.  Thanks,
>>
>> Not asking wrt libvirt but queried wrt qemu due to your original
>> implementation in qemu:
>>
>> https://lore.kernel.org/lkml/20200204161737.34696b91@w520.home
>> https://github.com/qemu/qemu/commit/2dca1b37a7605abb135559ef1b0d63929e7ae60d
>
> Per the first link:
>
>    NB. It's unclear whether there's value to this QEMU support without
>    further exposure of SR-IOV within a VM.  This is meant mostly as a
>    test case where the real initial users will likely be DPDK drivers.
>
> I didn't author the commit in the second link.
>
> Based on the above comment it's clear that QEMU, or any VMM use case,
> was not the initial target for vf-token support.  It was intended for
> DPDK, which already has a pretty low security model.  QEMU was only a
> proof of concept with a code base more familiar to me.
>
> I also noted in the above my expectation that SR-IOV would be the
> legitimate use case in QEMU.  My thought there was that QEMU would set
> a private vf-token and emulate an SR-IOV capability to the guest.
> Enabling SR-IOV by the guest would trigger a call-out to libvirt to
> effect the change via host pci-sysfs and attach the resulting VFs back
> to the VM.  The vf-token would remain private and act as a measure of
> protection against other use cases for the VFs.
>
> I've never been strongly in favor of general vf-token support in QEMU.
> If a VF requires a vf-token, then by definition the PF is being managed
> by another vfio userspace driver.  Somebody needs to decide whether
> that userspace driver is trustworthy since it may have access to all
> the data accessible to the VF.  An in-kernel PF driver would be trusted
> by default, so what's the underlying motivation to make vf-token
> support more ubiquitous through the stack?
>
> In my view, this support attempts to de-emphasize the security risk of
> a 3rd party userspace PF driver while also promoting their very
> existence.  I won't deny that use cases for this exist, but I have yet
> to see evidence that those are use cases I care to promote.  So no, I
> won't be implementing a secret object implementation of this in QEMU.
> Thanks,
>

Thanks for the explanation.
I'll follow-up on the secret object implementation.

-vk

> Alex
>
>
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org