Page MenuHomeFreeBSD

bhyveload(8): Implement loader_callbacks::diskwrite
ClosedPublic

Authored by cem on Oct 7 2020, 7:05 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Jul 4, 3:55 PM
Unknown Object (File)
Sat, Jun 28, 3:21 AM
Unknown Object (File)
Fri, Jun 27, 5:00 PM
Unknown Object (File)
Fri, Jun 27, 10:21 AM
Unknown Object (File)
Thu, Jun 26, 8:46 AM
Unknown Object (File)
Fri, Jun 20, 9:02 AM
Unknown Object (File)
Sun, Jun 15, 6:13 AM
Unknown Object (File)
Wed, Jun 11, 4:45 PM
Subscribers

Details

Summary

The method was optional prior to r365938, which made it mandatory but did
not implement it for bhyveload. The code path might not be hit unless the
user's loader was configured to write to a file on disk, such as
nextboot(8)'s nextboot.conf.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 34043
Build 31227: arc lint + arc unit

Event Timeline

cem requested review of this revision.Oct 7 2020, 7:05 PM
This revision is now accepted and ready to land.Oct 7 2020, 7:50 PM

I assume, bhyveload does open disk images RW.

Thanks all!

I assume, bhyveload does open disk images RW.

I was worried about possible privdrop / sandboxing issues as well, but I think this is correct regardless. Without a diskwrite method, we segfault and crash. If the disk is opened RO, worst case the write operation errors, at the guest loader level, with EACCES or whatever. I did not check how the disk is opened by loader, but in practice: before this change, bhyveload(8) reliably cored after guest nextboot(8); afterwards, it does not.

This revision was automatically updated to reflect the committed changes.

I did not check how the disk is opened by loader

The open is currently read-only.

fd = open(path, O_RDONLY);

We should perhaps try to open O_RDWR and fallback to O_RDONLY if that fails. I know I use nextboot quite frequently during development (which is one my main use cases for bhyve)