Hi, if you plug in a usb-stick you can use it to share data between VMs which do not support the QubesIncomming-Feature. So if you need to debug some windows-stuff you could keep the windows stuff air-gapped and transport new software and results to from it using a virtual usb stick that mounts everywhere with ease.
So we would just need an embedded VM that speaks usb storage and claims that its private disk is a usb-stick.
So a USB-Stick-Fake-VM can be a template and the many usb-sticks one uses are app-vms based on the fake-usb-stick VM.
Again, the target VM shall not know that it is a virtual device (only by name or so). So no drivers or changes at the VM using the virtual usb device shall be needed. So for example a virtual cdc-ether device is a usb network board that terminates somewhere in qubes, e.g. at a whonix-gateway providing tor.
So qubes shall say "new hardware available “-fake usbstick- Bluedragon3” or how you name it.
How can we have a VM with small embedded software that fakes a usb storage device?
I found something that we could use:
This also can hack some virtual usb sound and hid devices into a VM.
But here we would need a USB/IP-Driver at the VM which is not desired. Better is faking the usb devices completely in qubes, so that the VM just sees a “real” usb device.
Addenum:
Fake USB-SOUND would also kill most of the sound problems.
“Just” fake a standard 44.1&48KHZ/16Bit Stereo USB Source-Sink and connect it to the audio system (pulse audio - I dont like it) of qubes.
The result is, that all guests that can be executed using the Xen hypervisor get network, storage and sound at ease without having the need for fancy drivers at the VM side.
Not really, it should appear to be a USB-Stick, USB-storage.
Having the choice between USB-Storage, USB-Floppy or USB-cdrom emulation would be nicer.
It is about faking the USB device. So USB storage is hot plugable in most
systems, and it is so common that there are normally no high access restrictions
for users to operate hotplugged usb devices.
Attaching a new block device could require a reboot.
The use case is to just come along with the fake usb stick, get that file and attach
the fake stick to another vm where you use it.
At the moment a real usb stick does the job, but it is not encrypted. As the App-VM should be able to use it without problems.
So having a fake usb stick we have a loop-device or lvm that lives in an encrypted harddrive.
I get your point about the emulated USB, but this is not the best argument. Can (almost) always use Veracrypt to achieve the “USB is encrypted” goal.
It is about having the VM in “virgin” state and having VMs which operate standard usb devices but have no drivers for fancy hardware.
A standard USB-Sound headset just works. A USB-Floppy / CDROM just works as the os which has USB support in most cases implemented the devices common for USB.
Imagine some wired OS like solaris x86, macos x86 or some embedded stuff, xBSD for x86…
