[Libguestfs] [nbdkit PATCH] nbd: Opt in to libnbd pread_initialize speedup
Laszlo Ersek
lersek at redhat.com
Fri Feb 11 15:38:04 UTC 2022
On 02/11/22 15:35, Eric Blake wrote:
> On Fri, Feb 11, 2022 at 07:14:30AM +0100, Laszlo Ersek wrote:
>> On 02/10/22 16:38, Eric Blake wrote:
>>> Our nbd plugin has always properly checked for asynch errors (and thus
>>> has never been at risk of a vulnerability similar to CVE-2022-0485
>>> just fixed in nbdcopy). What's more, the nbdkit core guarantees
>>> (since commit b1ce255e in 2019, v1.13.1) that the buffer handed to a
>>> .pread callback has been pre-sanitized to not leak heap contents,
>>> regardless of how buggy a plugin might be (see
>>> server/protocol.c:protocol_recv_request_send_reply(), which uses
>>> server/threadlocal.c:threadlocal_buffer() for a safe buffer). Thus,
>>> we do not need libnbd to spend time re-initializing the buffer, if
>>> libnbd is new enough to give us that knob.
>>> ---
>>>
>
>>> +#if LIBNBD_HAVE_NBD_SET_PREAD_INITIALIZE
>>> + /* nbdkit guarantees that the buffers passed to our .pread callback
>>> + * are pre-initialized; and we in turn ensure that the buffer is not
>>> + * dereferenced if the NBD server replied with an error. Thus, we
>>> + * are safe opting in to this libnbd speedup.
>>> + */
>>> + if (nbd_set_pread_initialize (h->nbd, false) == -1)
>>> + goto errnbd;
>>> #endif
>>> if (dynamic_export && uri) {
>>> #if LIBNBD_HAVE_NBD_SET_OPT_MODE
>>>
>>
>> hahaha, this was real quick ;)
>
> I don't know if the speedy pun was intentional ;)
Heh, no, I didn't notice that coincidence :)
>
> Now pushed as 31997b25.
>
More information about the Libguestfs
mailing list