Re: [PATCH 1/5] virtio-blk: enforce iothread-vq-mapping validation

2024-02-06 Thread Stefan Hajnoczi
On Tue, Feb 06, 2024 at 09:29:29AM +0200, Manos Pitsidianakis wrote: > On Mon, 05 Feb 2024 19:26, Stefan Hajnoczi wrote: > > Hanna Czenczek noticed that the safety of > > `vq_aio_context[vq->value] = ctx;` with user-defined vq->value inputs is > > not obvious. > > > > The code is structured in

Re: [PATCH 1/5] virtio-blk: enforce iothread-vq-mapping validation

2024-02-06 Thread Hanna Czenczek
On 05.02.24 18:26, Stefan Hajnoczi wrote: Hanna Czenczek noticed that the safety of `vq_aio_context[vq->value] = ctx;` with user-defined vq->value inputs is not obvious. The code is structured in validate() + apply() steps so input validation is there, but it happens way earlier and there is

Re: [PATCH 1/5] virtio-blk: enforce iothread-vq-mapping validation

2024-02-05 Thread Manos Pitsidianakis
On Mon, 05 Feb 2024 19:26, Stefan Hajnoczi wrote: Hanna Czenczek noticed that the safety of `vq_aio_context[vq->value] = ctx;` with user-defined vq->value inputs is not obvious. The code is structured in validate() + apply() steps so input validation is there, but it happens way earlier and

[PATCH 1/5] virtio-blk: enforce iothread-vq-mapping validation

2024-02-05 Thread Stefan Hajnoczi
Hanna Czenczek noticed that the safety of `vq_aio_context[vq->value] = ctx;` with user-defined vq->value inputs is not obvious. The code is structured in validate() + apply() steps so input validation is there, but it happens way earlier and there is nothing that guarantees apply() can only be