linux-kernel - Re: [PATCH 2/2] xen/virtio: Avoid use of the dom0 backend in dom0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e5eda26f-9a31-dc3a-d97f-33d2efa20efa@suse.com>
Date:   Tue, 4 Jul 2023 12:39:40 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Roger Pau Monné <roger.pau@...rix.com>,
        Stefano Stabellini <sstabellini@...nel.org>
Cc:     Oleksandr Tyshchenko <Oleksandr_Tyshchenko@...m.com>,
        Petr Pavlu <petr.pavlu@...e.com>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        vikram.garhwal@....com
Subject: Re: [PATCH 2/2] xen/virtio: Avoid use of the dom0 backend in dom0

On 04.07.23 09:48, Roger Pau Monné wrote:
> On Thu, Jun 29, 2023 at 03:44:04PM -0700, Stefano Stabellini wrote:
>> On Thu, 29 Jun 2023, Oleksandr Tyshchenko wrote:
>>> On 29.06.23 04:00, Stefano Stabellini wrote:
>>>> I think we need to add a second way? It could be anything that can help
>>>> us distinguish between a non-grants-capable virtio backend and a
>>>> grants-capable virtio backend, such as:
>>>> - a string on xenstore
>>>> - a xen param
>>>> - a special PCI configuration register value
>>>> - something in the ACPI tables
>>>> - the QEMU machine type
>>>
>>>
>>> Yes, I remember there was a discussion regarding that. The point is to
>>> choose a solution to be functional for both PV and HVM *and* to be able
>>> to support a hotplug. IIRC, the xenstore could be a possible candidate.
>>
>> xenstore would be among the easiest to make work. The only downside is
>> the dependency on xenstore which otherwise virtio+grants doesn't have.
> 
> I would avoid introducing a dependency on xenstore, if nothing else we
> know it's a performance bottleneck.
> 
> We would also need to map the virtio device topology into xenstore, so
> that we can pass different options for each device.

This aspect (different options) is important. How do you want to pass virtio
device configuration parameters from dom0 to the virtio backend domain? You
probably need something like Xenstore (a virtio based alternative like virtiofs
would work, too) for that purpose.

Mapping the topology should be rather easy via the PCI-Id, e.g.:

/local/domain/42/device/virtio/0000:00:1c.0/backend

> 
>> Vikram is working on virtio with grants support in QEMU as we speak.
>> Maybe we could find a way to add a flag in QEMU so that we can detect at
>> runtime if a given virtio device support grants or not.
> 
> Isn't there a way for the device to expose capabilities already?  For
> example how does a virtio-blk backend expose support for indirect
> descriptors?

Those capabilities are defined in the virtio spec [1]. Adding the backend
domid would be possible, but it probably wouldn't be that easy (requires
changing the virtio spec by either expanding an existing config area or by
adding a new one). I'm not sure handling in the specific frontends is
generic enough for being able to have a central place where the backend
domid could be retrieved, without requiring any change of the frontends.


Juergen

[1]: http://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)