Manuel Giraud <man...@ledu-giraud.fr> writes:
> Mike Larkin <mlar...@nested.page> writes: > >> On Thu, Oct 12, 2023 at 09:24:33AM -0600, Theo de Raadt wrote: >>> Manuel Giraud <man...@ledu-giraud.fr> wrote: >>> >>> > > Manuel Giraud <man...@ledu-giraud.fr> writes: >>> > > >>> > >> Hi, >>> > >> >>> > >> I can't find the information on this list (or elsewhere). Is it >>> > >> possible to have a vm that access a disk through its device? The >>> > >> following does not seem to work: >>> > >> >>> > >> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm >>> > >> vmctl: start vm command failed: Unknown error: -1 >>> > > >>> > > No, passing file descriptors to devices over ipc sockets isn't currently >>> > > allowed by the kernel. You'd need to use the raw character device, too, >>> > > afaik if passing them were allowed. >>> > >>> > Ok, noted. BTW I have the same error passing the raw character device. >>> >>> >>> >>> I made the decision to not allow passing of weird file descriptor types >>> very intentionally. I'm still very sure that is the right decision. >>> >>> Here's 1 program which wants to do it, but the other 1000 pledge'd programs >>> are being protected from being passed an incorrect fd and then doing system >>> calls upon it which behave "different". By that, I mean seek, read, and >>> write short-operation behaviours are subtly different outside of files and >>> sockets, and it would also expose some ioctl (which is MOSTLY limited by >>> pledge, but ioctl "request" values are just numbers, and they can overlap in >>> surprising ways). >>> >> >> I would like to make clear that vmd does not "want to do it", and that I >> agree >> that the current design of not being able to pass these types of fds is >> correct. It may be slightly inconvient for certain niche use cases, but not >> worth weakening everything else or putting in hacks. Just dd the device you >> want to a .raw file and use that. > > Thanks for making that clear. I do not understand all the security > implications but you do :) Maybe to prevent future request, you could > have a more explicit error message. I agree reporting "Unknown error" is unhelpful. I don't think having something specific to people trying to use devices instead of files is worth the effort as none of the documentation should be implying that's a feature.
