From: John Johnson <john.g.johnson@oracle.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: QEMU Devel Mailing List <qemu-devel@nongnu.org>
Subject: Re: [RFC v3 05/19] Add validation ops vector
Date: Tue, 7 Dec 2021 07:48:52 +0000 [thread overview]
Message-ID: <AEEFBAEC-A0BA-4FD2-8647-068FFADB51D3@oracle.com> (raw)
In-Reply-To: <20211119154219.65a02f15.alex.williamson@redhat.com>
> On Nov 19, 2021, at 2:42 PM, Alex Williamson <alex.williamson@redhat.com> wrote:
>
>
> Add a prefix on Subject: please. Same for previous in series.
>
ok
> On Mon, 8 Nov 2021 16:46:33 -0800
> John Johnson <john.g.johnson@oracle.com> wrote:
>
>> Validates cases where the return values aren't fully trusted
>> (prep work for vfio-user, where the return values from the
>> remote process aren't trusted)
>>
>> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
>> ---
>> include/hw/vfio/vfio-common.h | 21 ++++++++++++++
>> hw/vfio/pci.c | 67 +++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 88 insertions(+)
>>
>> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
>> index 43fa948..c0dbbfb 100644
>> --- a/include/hw/vfio/vfio-common.h
>> +++ b/include/hw/vfio/vfio-common.h
>> @@ -125,6 +125,7 @@ typedef struct VFIOHostDMAWindow {
>>
>> typedef struct VFIODeviceOps VFIODeviceOps;
>> typedef struct VFIODevIO VFIODevIO;
>> +typedef struct VFIOValidOps VFIOValidOps;
>>
>> typedef struct VFIODevice {
>> QLIST_ENTRY(VFIODevice) next;
>> @@ -141,6 +142,7 @@ typedef struct VFIODevice {
>> bool enable_migration;
>> VFIODeviceOps *ops;
>> VFIODevIO *io_ops;
>> + VFIOValidOps *valid_ops;
>> unsigned int num_irqs;
>> unsigned int num_regions;
>> unsigned int flags;
>> @@ -214,6 +216,25 @@ struct VFIOContIO {
>> extern VFIODevIO vfio_dev_io_ioctl;
>> extern VFIOContIO vfio_cont_io_ioctl;
>>
>> +/*
>> + * This ops vector allows for bus-specific verification
>> + * routines in cases where the server may not be fully
>> + * trusted.
>> + */
>> +struct VFIOValidOps {
>> + int (*validate_get_info)(VFIODevice *vdev, struct vfio_device_info *info);
>> + int (*validate_get_region_info)(VFIODevice *vdev,
>> + struct vfio_region_info *info, int *fd);
>> + int (*validate_get_irq_info)(VFIODevice *vdev, struct vfio_irq_info *info);
>> +};
>> +
>> +#define VDEV_VALID_INFO(vdev, info) \
>> + ((vdev)->valid_ops->validate_get_info((vdev), (info)))
>> +#define VDEV_VALID_REGION_INFO(vdev, info, fd) \
>> + ((vdev)->valid_ops->validate_get_region_info((vdev), (info), (fd)))
>> +#define VDEV_VALID_IRQ_INFO(vdev, irq) \
>> + ((vdev)->valid_ops->validate_get_irq_info((vdev), (irq)))
>> +
>> #endif /* CONFIG_LINUX */
>>
>> typedef struct VFIOGroup {
>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>> index 28f21f8..6e2ce35 100644
>> --- a/hw/vfio/pci.c
>> +++ b/hw/vfio/pci.c
>> @@ -3371,3 +3371,70 @@ static void register_vfio_pci_dev_type(void)
>> }
>>
>> type_init(register_vfio_pci_dev_type)
>> +
>> +
>> +/*
>> + * PCI validation ops - used when return values need
>> + * validation before use
>> + */
>> +
>> +static int vfio_pci_valid_info(VFIODevice *vbasedev,
>> + struct vfio_device_info *info)
>> +{
>> + /* must be PCI */
>> + if ((info->flags & VFIO_DEVICE_FLAGS_PCI) == 0) {
>> + return -EINVAL;
>> + }
>> + /* only other valid flag is reset */
>> + if (info->flags & ~(VFIO_DEVICE_FLAGS_PCI | VFIO_DEVICE_FLAGS_RESET)) {
>> + return -EINVAL;
>> + }
>
> This means QEMU vfio-pci breaks on any extension of the flags field.
>
>> + /* account for extra migration region */
>> + if (info->num_regions > VFIO_PCI_NUM_REGIONS + 1) {
>> + return -EINVAL;
>> + }
>
> This is also invalid, there can be device specific regions beyond
> migration.
>
>> + if (info->num_irqs > VFIO_PCI_NUM_IRQS) {
>> + return -EINVAL;
>> + }
>
> And device specific IRQs.
>
>> + return 0;
>> +}
>> +
>> +static int vfio_pci_valid_region_info(VFIODevice *vbasedev,
>> + struct vfio_region_info *info,
>> + int *fd)
>> +{
>> + if (info->flags & ~(VFIO_REGION_INFO_FLAG_READ |
>> + VFIO_REGION_INFO_FLAG_WRITE |
>> + VFIO_REGION_INFO_FLAG_MMAP |
>> + VFIO_REGION_INFO_FLAG_CAPS)) {
>> + return -EINVAL;
>> + }
>
> Similarly, this allows zero future extensions. Notice for instance how
> the CAPS flag was added later as a backwards compatible extension.
>
>> + if (info->index > vbasedev->num_regions) {
>> + return -EINVAL;
>> + }
>> + /* cap_offset in valid area */
>> + if ((info->flags & VFIO_REGION_INFO_FLAG_CAPS) &&
>> + (info->cap_offset < sizeof(*info) || info->cap_offset > info->argsz)) {
>> + return -EINVAL;
>> + }
>> + return 0;
>> +}
>> +
>> +static int vfio_pci_valid_irq_info(VFIODevice *vbasedev,
>> + struct vfio_irq_info *info)
>> +{
>> + if (info->flags & ~(VFIO_IRQ_INFO_EVENTFD | VFIO_IRQ_INFO_MASKABLE |
>> + VFIO_IRQ_INFO_AUTOMASKED | VFIO_IRQ_INFO_NORESIZE)) {
>> + return -EINVAL;
>> + }
>
> Similarly, nak. Thanks,
>
The verification routines are to sanitize the data returned when we
don’t trust the server. The kernel driver return values are not verified, as
the kernel has much better ways of corrupting the client. When new flags
are added, the they’d be added here, too.
I can push them down into the the vfio-user code, but that forces
the vfio-code to change versions or add capabilities whenever a new flag is
added.
JJ
next prev parent reply other threads:[~2021-12-07 7:52 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-09 0:46 [RFC v3 00/19] vfio-user client John Johnson
2021-11-09 0:46 ` [RFC v3 01/19] vfio-user: introduce vfio-user protocol specification John Johnson
2021-11-09 0:46 ` [RFC v3 02/19] vfio-user: add VFIO base abstract class John Johnson
2021-11-19 22:42 ` Alex Williamson
2021-12-07 7:47 ` John Johnson
2021-11-09 0:46 ` [RFC v3 03/19] Add container IO ops vector John Johnson
2021-11-09 0:46 ` [RFC v3 04/19] Add device " John Johnson
2021-11-19 22:42 ` Alex Williamson
2021-12-07 7:48 ` John Johnson
2021-11-09 0:46 ` [RFC v3 05/19] Add validation " John Johnson
2021-11-19 22:42 ` Alex Williamson
2021-12-07 7:48 ` John Johnson [this message]
2021-11-09 0:46 ` [RFC v3 06/19] vfio-user: Define type vfio_user_pci_dev_info John Johnson
2021-11-19 22:42 ` Alex Williamson
2021-12-07 7:49 ` John Johnson
2021-11-09 0:46 ` [RFC v3 07/19] vfio-user: connect vfio proxy to remote server John Johnson
2021-11-19 22:42 ` Alex Williamson
2021-12-07 7:49 ` John Johnson
2021-11-09 0:46 ` [RFC v3 08/19] vfio-user: define socket receive functions John Johnson
2021-11-19 22:42 ` Alex Williamson
2021-12-07 7:49 ` John Johnson
2021-11-09 0:46 ` [RFC v3 09/19] vfio-user: define socket send functions John Johnson
2021-11-09 0:46 ` [RFC v3 10/19] vfio-user: get device info John Johnson
2021-11-09 0:46 ` [RFC v3 11/19] vfio-user: get region info John Johnson
2021-11-19 22:42 ` Alex Williamson
2021-12-07 7:50 ` John Johnson
2021-11-09 0:46 ` [RFC v3 12/19] vfio-user: region read/write John Johnson
2021-11-19 22:42 ` Alex Williamson
2021-12-07 7:50 ` John Johnson
2021-11-09 0:46 ` [RFC v3 13/19] vfio-user: pci_user_realize PCI setup John Johnson
2021-11-19 22:42 ` Alex Williamson
2021-12-07 7:50 ` John Johnson
2021-11-09 0:46 ` [RFC v3 14/19] vfio-user: get and set IRQs John Johnson
2021-11-09 0:46 ` [RFC v3 15/19] vfio-user: proxy container connect/disconnect John Johnson
2021-11-09 0:46 ` [RFC v3 16/19] vfio-user: dma map/unmap operations John Johnson
2021-11-19 22:42 ` Alex Williamson
2021-12-07 7:50 ` John Johnson
2021-11-09 0:46 ` [RFC v3 17/19] vfio-user: dma read/write operations John Johnson
2021-11-09 0:46 ` [RFC v3 18/19] vfio-user: pci reset John Johnson
2021-11-09 0:46 ` [RFC v3 19/19] vfio-user: migration support John Johnson
2021-11-19 22:42 ` Alex Williamson
2021-12-07 7:50 ` John Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AEEFBAEC-A0BA-4FD2-8647-068FFADB51D3@oracle.com \
--to=john.g.johnson@oracle.com \
--cc=alex.williamson@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).