[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k018p4xs.fsf@ubik.fi.intel.com>
Date: Fri, 27 Jan 2023 13:55:43 +0200
From: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
jasowang@...hat.com, virtualization@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, elena.reshetova@...el.com,
kirill.shutemov@...ux.intel.com, Andi Kleen <ak@...ux.intel.com>,
Amit Shah <amit@...nel.org>, Arnd Bergmann <arnd@...db.de>,
alexander.shishkin@...ux.intel.com
Subject: Re: [PATCH v1 2/6] virtio console: Harden port adding
"Michael S. Tsirkin" <mst@...hat.com> writes:
> On Thu, Jan 19, 2023 at 10:13:18PM +0200, Alexander Shishkin wrote:
>> When handling control messages, instead of peeking at the device memory
>> to obtain bits of the control structure,
>
> Except the message makes it seem that we are getting data from
> device memory, when we do nothing of the kind.
We can be, see below.
>> take a snapshot of it once and
>> use it instead, to prevent it from changing under us. This avoids races
>> between port id validation and control event decoding, which can lead
>> to, for example, a NULL dereference in port removal of a nonexistent
>> port.
>>
>> The control structure is small enough (8 bytes) that it can be cached
>> directly on the stack.
>
> I still have no real idea why we want a copy here.
> If device can poke anywhere at memory then it can crash kernel anyway.
> If there's a bounce buffer or an iommu or some other protection
> in place, then this memory can no longer change by the time
> we look at it.
We can have shared pages between the host and guest without bounce
buffers in between, so they can be both looking directly at the same
page.
Regards,
--
Alex
Powered by blists - more mailing lists