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
Slice() is easier to use and faster than Get() or Bytes(). Let's use the
new way.
Signed-off-by: Nir Soffer
---
golang/libnbd_020_aio_buffer_test.go | 8 +---
golang/libnbd_500_aio_pread_test.go | 2 +-
golang/libnbd_510_aio_pwrite_test.go | 8 +---
3 files changed, 11 insertions(+), 7
AioBuffer.Bytes() cannot be used for copying images from NBD to other
APis because it copies the entire image. Add a new Slice() function,
creating a slice backed by the underlying buffer.
Using Slice() is efficient, but less safe, like Get(). The returned
slice must be used only before calling
Now that we have an efficient way to use AioBuffer, we don't need the
hacks to create AioBuffer from Go slice.
Benchmarking AioBuffer shows that allocating a 256k buffer is
practically free, so there is no need for the buffer pool. Now we
allocate a new buffer per request, keep it in the command,
Using Slice() we can use builtin copy() instead of a manual loop, which
is 4.6 times faster with a typical 256k buffer:
Before:
BenchmarkFromBytes-12 9806111474 ns/op
After:
BenchmarkFromBytes-12 48193 24106 ns/op
Signed-off-by:
Add benchmark for coping a buffer using 3 strategies - reusing same
buffer, making a new uninitialized buffer per copy, and using a zeroed
buffer per copy. This benchmark is the worst possible case, copying a
buffer to memory. Any real I/O will be much slower, hiding the overhead
of allocating or
Make it easy to create a zeroed buffer via calloc(), preventing leaking
sensitive info from the heap.
Benchmarking shows that creating a zeroed buffer is much slower compared
with uninitialized buffer, but much faster compared with manually
initializing the buffer with a loop.
Add standard function documentation comments.
The documentation should be available here:
https://pkg.go.dev/libguestfs.org/libnbd#AioBuffer
Signed-off-by: Nir Soffer
---
golang/aio_buffer.go | 12
1 file changed, 12 insertions(+)
diff --git a/golang/aio_buffer.go
Improve AioBuffer to make it safer, easier to use, and faster when integrating
with other Go APIs.
New Go specific APIs:
- MakeAioBufferZero() - creates a new buffer using calloc(), to make it easy
and efficient to use a zeroed buffer.
- AioBuffer.Slice() - create a slice backed by the
If a Go program tries to use AioBuffer after calling AioBuffer.Free(),
the program may silently corrupt data, accessing memory that does not
belong to the buffer any more, or segfault if the address is not mapped.
In the worst case, it can corrupt memory silently. Calling Free() twice
may silently
Add unit tests and benchmarks for AioBuffer. The tests are trivial but
they server as running documentation, and they point out important
details about the type.
The benchmarks show the efficiency of allocating a new buffer, zeroing
it, and interfacing with Go code.
These tests will also ensure
On Tue, Feb 1, 2022 at 3:12 PM Eric Blake wrote:
>
> On Sun, Jan 30, 2022 at 01:33:33AM +0200, Nir Soffer wrote:
> > AioBuffer.Bytes() cannot be used for coping images from NBD to other
>
> copying
>
> > APis because it copies the entire image. Add a new Slice() function,
> > creating a slice
On Tue, Feb 8, 2022 at 10:45 PM Eric Blake wrote:
>
> On Sun, Jan 30, 2022 at 01:33:32AM +0200, Nir Soffer wrote:
> > Make it easy to create a zeroed buffer via calloc(), preventing leaking
> > sensitive info from the heap.
> >
> > Benchmarking show that creating a zeroed buffer is much slower
On Tue, Feb 1, 2022 at 3:09 PM Eric Blake wrote:
>
> On Sun, Jan 30, 2022 at 01:33:31AM +0200, Nir Soffer wrote:
> > Add standard function documentation comments.
> >
> > The documentation should be available here:
> > https://pkg.go.dev/libguestfs.org/libnbd#AioBuffer
> >
> > Signed-off-by: Nir
On Tue, Feb 8, 2022 at 9:33 PM Eric Blake wrote:
>
> On Sun, Jan 30, 2022 at 01:33:29AM +0200, Nir Soffer wrote:
> > Add unit tests and benchmarks for AioBuffer. The tests are trivial but
> > they server as running documentation, and they point out important
> > details about the type.
> >
> >
On Tue, Feb 8, 2022 at 9:23 PM Eric Blake wrote:
>
> On Sun, Feb 06, 2022 at 07:45:20PM +0200, Nir Soffer wrote:
> > Create a slice backed up by the entries pointer, and copy the data with
> > builtin copy(). This can be 3x times faster but I did not measure it.
> >
> > Eric posted a similar
On Tue, Feb 8, 2022 at 5:24 PM Richard W.M. Jones wrote:
...
>
> ACK 4 & 5.
Push series without patch 2 as
99b6e31b output/rhv-upload-plugin: Keep connections alive
02d2236b output/rhv-upload-plugin: Track http last request time
a436a0dc output/rhv-upload-plugin: Extract send_flush() helper
On Thu, Feb 10, 2022 at 03:09:46PM +, Richard W.M. Jones wrote:
> For Fedora, I won't do anything now, just let this go out in the next
> release. It'll need a small adjustment if we backport it to the
> stable-1.10 branch.
>
> For RHEL, I'm going to put this in RHEL 9.0, but won't bother
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
On Thu, Feb 10, 2022 at 08:50:07AM -0600, Eric Blake wrote:
> On Thu, Feb 10, 2022 at 09:38:30AM +, Richard W.M. Jones wrote:
> > On Wed, Feb 09, 2022 at 04:07:26PM -0600, Eric Blake wrote:
> > > + "set_pread_initialize", {
> > > +default_call with
> > > +args = [Bool "request"]; ret
On Thu, Feb 10, 2022 at 09:38:30AM +, Richard W.M. Jones wrote:
> On Wed, Feb 09, 2022 at 04:07:26PM -0600, Eric Blake wrote:
> > + "set_pread_initialize", {
> > +default_call with
> > +args = [Bool "request"]; ret = RErr;
> > +shortdesc = "control whether libnbd pre-initializes
On Thu, Feb 10, 2022 at 02:51:56PM +0100, Laszlo Ersek wrote:
> On 02/09/22 23:07, Eric Blake wrote:
> > As mentioned in the previous patch, we left the state of the buffer
> > undefined if we fail pread prior to attempting NBD_CMD_READ. Better
> > is to tweak the generator to sanitize the buffer
On 02/09/22 23:07, Eric Blake wrote:
> The recent patch series for CVE-2022-0485 demonstrated that when
> applications using libnbd are not careful about error checking, the
> difference on whether a data leak is at least sanitized (all zeroes,
> partial reads, or data leftover from a prior read)
On 02/09/22 23:07, Eric Blake wrote:
> As mentioned in the previous patch, we left the state of the buffer
> undefined if we fail pread prior to attempting NBD_CMD_READ. Better
> is to tweak the generator to sanitize the buffer unconditionally, as a
> way of hardening against potential bugs in
On 02/09/22 23:07, Eric Blake wrote:
> The recent CVE-2022-0485 demonstrated that clients that pass in an
> uninitialized buffer to nbd_pread and friends, but are then not
> careful about checking for read errors, were subjected to
> server-dependent behavior on whether their use of the buffer
On 02/09/22 14:36, Richard W.M. Jones wrote:
> On Wed, Feb 09, 2022 at 02:17:38PM +0100, Laszlo Ersek wrote:
>> Utilities shouldn't directly call "Std_utils.wrap" for printing
>> informative messages; the "Tools_utils.info" function handles that better.
>>
>> Because "info" prints a trailing
On Wed, Feb 09, 2022 at 04:07:26PM -0600, Eric Blake wrote:
> + "set_pread_initialize", {
> +default_call with
> +args = [Bool "request"]; ret = RErr;
> +shortdesc = "control whether libnbd pre-initializes read buffers";
> +longdesc = "\
> +By default, libnbd will pre-initialize
27 matches
Mail list logo
