Page MenuHomeFreeBSD

bhyve(8): Fix NVMe data structure copy to guest
ClosedPublic

Authored by chuck on Mar 24 2019, 5:18 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 19 2024, 9:14 AM
Unknown Object (File)
Feb 11 2024, 8:51 PM
Unknown Object (File)
Dec 20 2023, 6:44 PM
Unknown Object (File)
Dec 20 2023, 4:40 AM
Unknown Object (File)
Nov 23 2023, 11:14 PM
Unknown Object (File)
Nov 6 2023, 10:47 PM
Unknown Object (File)
Oct 2 2023, 3:35 PM
Unknown Object (File)
Sep 2 2023, 3:03 AM
Subscribers

Details

Summary

bhyve's NVMe emulation was transferring Identify data back to the guest
incorrectly causing memory corruptions. These corruptions resulted in
core dumps and other system level errors in the guest.

In their simplest form, NVMe Physical Region Page (PRP) values in
commands indicate which physical pages to use for data transfer. The
first PRP value is not required to be page aligned but does not cross a
page boundary. The second PRP value must be page aligned, does not cross
a page boundary, and need not be contiguous with PRP1.

The code was copying Identify data past the end of PRP1. This happens to
work if PRP1 and PRP2 are physically contiguous but will corrupt guest
memory in unpredictable ways if they are not.

Fix is to copy the Identify data back to the guest piecewise (i.e. for
each PRP entry). Also fix a similarly wrong problem when copying back
Log page data.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This looks good to me. It's the right thing to do.
Do we need to expand it more generally (in a different commit) for any time we have to copy data out, or is the I/O path good?

It looks good! Thanks again @chuck

This revision is now accepted and ready to land.Apr 4 2019, 5:23 PM
In D19695#423813, @imp wrote:

This looks good to me. It's the right thing to do.
Do we need to expand it more generally (in a different commit) for any time we have to copy data out, or is the I/O path good?

The IO path appears to be OK, but I only took brief look. That said, I've run a fair amount of IO against and haven't seen any issues in practice. Where as this issue was easily reproducible.

In D19695#423813, @imp wrote:

This looks good to me. It's the right thing to do.
Do we need to expand it more generally (in a different commit) for any time we have to copy data out, or is the I/O path good?

The IO path appears to be OK, but I only took brief look. That said, I've run a fair amount of IO against and haven't seen any issues in practice. Where as this issue was easily reproducible.

Good enough for me. Let's get it in.

This revision was automatically updated to reflect the committed changes.