6 ms·

Raw Gadget is a kernel module that allows to emulate USB devices from userspace

68 points by SomeSnail 7y ago

Vogtinator 7y ago
Arguably this can be implemented already using usbip to localhost. That's already part of mainline, so does not need any out of tree modules.
TorKlingberg 7y ago
Neat. Can you clarify what "emulate" means? Would this let me implement a USB gadget on a Linux board with a device-side USB port, without writing a kernel module?
- Vogtinator 7y ago
  That's already possible using usb functionfs.
codebeaker 7y ago
Could this be useful to "mock" A USB device for integration testing hardware (or specifically writing specs against not-plugged-in-hardware)?
XMPPwocky 7y ago
A key bit of information that might clear up some confusion - USB gadgets are the main peripheral-side USB interface in the Linux kernel. When you plug an embedded Linux device like a phone into something, it could use USB gadgets to expose internal storage as a mass storage device, create a tty and expose that as a USB ACM/CDC device, etc- and using the gadget mechanism, allocate USB endpoints to each of these functions, and enable or disable them at runtime. So, this project seems to be allowing a Linux device to emulate arbitrary peripherals to an external USB host. Prior work in this area: see Facedancer. Neat.
- Vogtinator 7y ago
  No, this allows userspace to act as a USB gadget connected to the Linux kernel it's running on.
  - XMPPwocky 7y ago
    It sure doesn't seem to. That's why they have a separate subproject for it- https://github.com/xairy/raw-gadget/blob/master/dummy_hcd/README.md https://github.com/xairy/raw-gadget/blob/master/dummy_hcd/RE... But you certainly could know more than me about it! Why do you think it's exclusively for acting as a USB gadget connected to the Linux kernel it's running on?
    - Vogtinator 7y ago
      It looks like I'm only partially right: dummy_hcd is just for the local kernel, but raw gadget is just yet another interface to the UDC, so like usb functionfs just without sanity checks. I found documentation about this in the submission to mainline: https://lwn.net/ml/linux-usb/461a787e63a9a01d83edc563575b8585bc138e8d.1579007786.git.andreyknvl@google.com/ https://lwn.net/ml/linux-usb/461a787e63a9a01d83edc563575b858...
zokier 7y ago
Bit of clarification is apparently needed. The loopback USB emulation is already in mainline via CONFIG_USB_DUMMY_HCD What this new module provides is new userspace API to the gadget subsystem, making the dummy hcd much more practical especially for testing USB driver code
lmilcin 7y ago
This is really fantastic. I am currently building my own keyboard with my own controller and it will be much easier for me to first implement mock controller in userspace before I try to get it right on external device. Especially because I will want to put some complicated functionality in it like steno.
- jrockway 7y ago
  I don't think you need that for this. The keyboard firmware likely consists of three big chunks, the USB code, the matrix scan, and the processing of the matrix scan data into keystrokes. The USB stack is likely a peripheral on your microcontroller, which they have in theory already tested. The matrix scan will need to be tested on real hardware. The processing code should be abstracted enough from USB and matrix scanning that you can just compile it for your host machine and write tests the usual way (given matrix state x then y, output state should be foo). For final integration tests, you can use an additional microcontroller to be the key matrix. Instead of wiring up keyswitches, wire the microcontroller to the matrix pins, and have it accept commands over the serial port to set the matrix to a certain state. This way, you can do a full end-to-end test on your real hardware. The only place USB gadget emulation might be helpful is in writing the code that switches the keyboard from compatibility mode (6KRO) to the NKRO mode. It's been done a million times, though, so there is plenty of library code to just copy.
  - lmilcin 7y ago
    First, this is going to be my first USB device. Second, I plan to put some more complex functionality. I intend it to be my last keyboard so I want to be able to map every key however I want (the whole point of having my own controller). I also want it to have built-in steno which is much more than just matrix scanning. While I could achieve all of that with OS driver and plover the sad reality is that I am unable to install my own software on my corporate PC and I would like to have consistent environment at my home and office.
    - jrockway 7y ago
      All I'm saying is that the interesting part of the code will run just fine on your host machine, so you don't need any complicated tricks to develop and test it. Obviously in production it will run on the microcontroller, so you get the functionality you desire without OS drivers. Do keep in mind that /usr/share/dict/words is about 10x larger than the flash on microcontrollers. This is why most people do the steno conversion in software, not on the keyboard itself.
vrsfvwae5tbh 7y ago
Could this be used to emulate a usb keyboard from untrusted code and break out of a sandbox?
RyanMathewson 7y ago
Does anything like this exist for Windows? I was recently looking and couldn't find anything.

68 points by SomeSnail 7y ago

Arguably this can be implemented already using usbip to localhost. That's already part of mainline, so does not need any out of tree modules.

TorKlingberg 7y ago

Neat. Can you clarify what "emulate" means? Would this let me implement a USB gadget on a Linux board with a device-side USB port, without writing a kernel module?

Vogtinator 7y ago
That's already possible using usb functionfs.

codebeaker 7y ago

Could this be useful to "mock" A USB device for integration testing hardware (or specifically writing specs against not-plugged-in-hardware)?

XMPPwocky 7y ago

A key bit of information that might clear up some confusion - USB gadgets are the main peripheral-side USB interface in the Linux kernel. When you plug an embedded Linux device like a phone into something, it could use USB gadgets to expose internal storage as a mass storage device, create a tty and expose that as a USB ACM/CDC device, etc- and using the gadget mechanism, allocate USB endpoints to each of these functions, and enable or disable them at runtime. So, this project seems to be allowing a Linux device to emulate arbitrary peripherals to an external USB host. Prior work in this area: see Facedancer. Neat.

Vogtinator 7y ago
No, this allows userspace to act as a USB gadget connected to the Linux kernel it's running on.
- XMPPwocky 7y ago
  It sure doesn't seem to. That's why they have a separate subproject for it- https://github.com/xairy/raw-gadget/blob/master/dummy_hcd/README.md https://github.com/xairy/raw-gadget/blob/master/dummy_hcd/RE... But you certainly could know more than me about it! Why do you think it's exclusively for acting as a USB gadget connected to the Linux kernel it's running on?
  - Vogtinator 7y ago
    It looks like I'm only partially right: dummy_hcd is just for the local kernel, but raw gadget is just yet another interface to the UDC, so like usb functionfs just without sanity checks. I found documentation about this in the submission to mainline: https://lwn.net/ml/linux-usb/461a787e63a9a01d83edc563575b8585bc138e8d.1579007786.git.andreyknvl@google.com/ https://lwn.net/ml/linux-usb/461a787e63a9a01d83edc563575b858...

zokier 7y ago

Bit of clarification is apparently needed. The loopback USB emulation is already in mainline via CONFIG_USB_DUMMY_HCD What this new module provides is new userspace API to the gadget subsystem, making the dummy hcd much more practical especially for testing USB driver code

lmilcin 7y ago

This is really fantastic. I am currently building my own keyboard with my own controller and it will be much easier for me to first implement mock controller in userspace before I try to get it right on external device. Especially because I will want to put some complicated functionality in it like steno.

jrockway 7y ago
I don't think you need that for this. The keyboard firmware likely consists of three big chunks, the USB code, the matrix scan, and the processing of the matrix scan data into keystrokes. The USB stack is likely a peripheral on your microcontroller, which they have in theory already tested. The matrix scan will need to be tested on real hardware. The processing code should be abstracted enough from USB and matrix scanning that you can just compile it for your host machine and write tests the usual way (given matrix state x then y, output state should be foo). For final integration tests, you can use an additional microcontroller to be the key matrix. Instead of wiring up keyswitches, wire the microcontroller to the matrix pins, and have it accept commands over the serial port to set the matrix to a certain state. This way, you can do a full end-to-end test on your real hardware. The only place USB gadget emulation might be helpful is in writing the code that switches the keyboard from compatibility mode (6KRO) to the NKRO mode. It's been done a million times, though, so there is plenty of library code to just copy.
- lmilcin 7y ago
  First, this is going to be my first USB device. Second, I plan to put some more complex functionality. I intend it to be my last keyboard so I want to be able to map every key however I want (the whole point of having my own controller). I also want it to have built-in steno which is much more than just matrix scanning. While I could achieve all of that with OS driver and plover the sad reality is that I am unable to install my own software on my corporate PC and I would like to have consistent environment at my home and office.
  - jrockway 7y ago
    All I'm saying is that the interesting part of the code will run just fine on your host machine, so you don't need any complicated tricks to develop and test it. Obviously in production it will run on the microcontroller, so you get the functionality you desire without OS drivers. Do keep in mind that /usr/share/dict/words is about 10x larger than the flash on microcontrollers. This is why most people do the steno conversion in software, not on the keyboard itself.

vrsfvwae5tbh 7y ago

Could this be used to emulate a usb keyboard from untrusted code and break out of a sandbox?

RyanMathewson 7y ago

Does anything like this exist for Windows? I was recently looking and couldn't find anything.