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)
Feb 23 2024, 10:57 AM
Unknown Object (File)
Dec 20 2023, 7:32 AM
Unknown Object (File)
Dec 3 2023, 12:45 PM
Unknown Object (File)
Dec 3 2023, 12:45 PM
Unknown Object (File)
Dec 3 2023, 12:45 PM
Unknown Object (File)
Dec 3 2023, 11:29 AM
Unknown Object (File)
Sep 24 2023, 1:16 AM
Unknown Object (File)
Jul 24 2023, 5:19 AM
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

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

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)