linux-kernel - Re: [PATCH v5 2/4] vduse: Temporarily disable control queue features

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 for Android: free password hash cracker in your pocket

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

Date: Mon, 18 Dec 2023 10:21:38 +0100
From: Maxime Coquelin <maxime.coquelin@...hat.com>
To: Jason Wang <jasowang@...hat.com>
Cc: mst@...hat.com, xuanzhuo@...ux.alibaba.com, paul@...l-moore.com,
 jmorris@...ei.org, serge@...lyn.com, stephen.smalley.work@...il.com,
 eparis@...isplace.org, xieyongji@...edance.com,
 virtualization@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
 linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
 david.marchand@...hat.com, lulu@...hat.com, casey@...aufler-ca.com
Subject: Re: [PATCH v5 2/4] vduse: Temporarily disable control queue features



On 12/18/23 03:50, Jason Wang wrote:
> On Wed, Dec 13, 2023 at 7:23 PM Maxime Coquelin
> <maxime.coquelin@...hat.com> wrote:
>>
>> Hi Jason,
>>
>> On 12/13/23 05:52, Jason Wang wrote:
>>> On Tue, Dec 12, 2023 at 9:17 PM Maxime Coquelin
>>> <maxime.coquelin@...hat.com> wrote:
>>>>
>>>> Virtio-net driver control queue implementation is not safe
>>>> when used with VDUSE. If the VDUSE application does not
>>>> reply to control queue messages, it currently ends up
>>>> hanging the kernel thread sending this command.
>>>>
>>>> Some work is on-going to make the control queue
>>>> implementation robust with VDUSE. Until it is completed,
>>>> let's disable control virtqueue and features that depend on
>>>> it.
>>>>
>>>> Signed-off-by: Maxime Coquelin <maxime.coquelin@...hat.com>
>>>
>>> I wonder if it's better to fail instead of a mask as a start.
>>
>> I think it is better to use a mask and not fail, so that we can in the
>> future use a recent VDUSE application with an older kernel.
> 
> It may confuse the userspace unless userspace can do post check after
> CREATE_DEV.
> 
> And for blk we fail when WCE is set in feature_is_valid():
> 
> static bool features_is_valid(u64 features)
> {
>          if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
>                  return false;
> 
>          /* Now we only support read-only configuration space */
>          if (features & (1ULL << VIRTIO_BLK_F_CONFIG_WCE))
>                  return false;
> 
>          return true;
> }

Ok, consistency with other devices types is indeed better.

But should I fail if any of the feature advertised by the application is
not listed by the VDUSE driver, or just fail if control queue is being
advertised by the application?

Thanks,
Maxime

> Thanks
> 
>>
>> Why would it be better to fail than negotiating?
>>
>> Thanks,
>> Maxime
>>
>