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.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Thanks all!
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.
Comment Actions
I did not check how the disk is opened by loader
The open is currently read-only.
fd = open(path, O_RDONLY);
Comment Actions
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)