 Thank you for coming. Let me get started with my presentation. My name is Yorick Sato from Tokyo Tech. So my topics I would like to talk about here is USB Deback capability. DVC stands for Deback Capability on privacy. So this is online. I am a Japanese privacy committer since 2000 and I am working in various areas. Yes, I attended the URB-STIC on for a long time, but this is the first time to give a talk at the URB-STIC on. And I will explain the background of the USB Deback capability and some technical details. And after that, I will demonstrate how the USB Deback works by using the actual hardware. And I will explain some future work. So first of all, let me explain the background of this functionality. USB Deback is not related to debugging the USB itself, USB or USB stack itself. The purpose I want to emphasize is that usually developing a privacy or kernel-side development requires some way to connect the target machine, the USB Deback target machine to get the information when the kernel went wrong or unresponsive for most cases, in most cases that the core is at the back, but it is difficult to find the contents of memory or internet state. So it is difficult to get such information using the normal hardware available in the market. So one thing we traditionally do is using the remote access via a CIO console. So the photo on the right-hand side is a small PC. It is actually available here. But this small PC has actually a legacy CIO port in addition to the modern HDMI or USB. So if the machine has a legacy CIO hardware, it is easy for you to get the machine-to-machine connection by using the closed cable and to get the login prompt over the CIO line or even you can use the gdb, so remote gdb session because the privacy supports attaching the remote gdb session. So you can debug the kernel to examine the internet state or memory over the closed cable. So raise your hand if you have used the CIO console. And raise your hand if you are still using the CIO console by using the CIO cable. So the problem is that there is no CIO port anymore in modern hardware. It is considered as a legacy interface. But these days for the purpose that remote access to the hairless machine, the server-grade machines have a BMC, a baseboard management controller, with a function that can redirect the console to the virtual CIO port to the internet. More specifically, the IPMI has a specification to provide the serial access. So facing the machine side, that is simply a legacy CIO port. And facing the outside, the IPMI specification can send the serial communication over UDP communication. So you can use that IPMI tool to get the serial console access over the internet connection. But this requires additional hardware. So consumer-level hardware does not have this kind of functionality. So it is difficult to get serial access. For example, if you are using the laptop. So the USB is actually the replacement of the legacy interfaces, including the serial port. So if this is actually the replacement of the legacy hardware, the legacy serial port, we want to use this as a tool to get the connection between the two machines. But the direct connection between the two USB ports is not allowed, at least in the USB 2.0 specification. Recently, Type-C connector-based USB specification allows this kind of connection. But basically, USB relies on the connection topology, so-called TR-STAR topology. TR-STAR means like a tree that has only one root. So every USB host machine. USB host means the machine. The machine is the USB ports and the hardware you have. So that has the host root have. That is a mandatory hardware portion of the USB. And you can connect the USB device to root have. And the number of ports available on the hardware is totally depending on the actual configuration. But root have is always the top of the hierarchy of the connection topology. And you can add the USB have and connect to the root have. And the USB device can be added to the under have. But in this topology, USB device to USB device connection never happened. Always the USB device is connected to have. That is the limitation or structure that the USB has, and the so-called TR-STAR topology. So we cannot get the direct connection like this. So let's move on to the USB debug capability. So one sentence summary of the USB debug capability is like this. USB debug capability changes one of the USB ports on the USB host for a USB device. So you see probably you know USB OTG on the go feature on the smartphone or similar hardware that can provide the USB device function for other machines. I mean you can connect the USB connector to smartphone to get the contents of the memory card by using that connection. But the smartphone itself is the host and the UAPC is the host. So usually that connection is not allowed. But the USB OTG feature, it is one of the features on the smartphone side, can change the role of the port to the USB device. So from the UAPC, the smartphone is recognized as a USB device such as a UMass or a storage device. But the normal USB host controller on a new laptop or motherboard doesn't support such a feature because USB OTG requires additional hardware. So normally usually it never happens on the host controller. But USB debug capability is to make it possible for debugging purpose. And this is an optional feature in the USB 3 specification that most of the Intel XHCI controller supports it and probably other vendors. I did not check the other controller yet. But most of USB circuit IP distributed by the chip maker supports this functionality. So probably you can use your hardware. And I know that this is not the point-to-point connection, but you can connect the two USB ports because the target side can be recognized as a USB device by activating the USB debug capability on this side. By converting one of the ports to USB device, the topology remains the same structure. So this device is always connected to have. So in this way, the machine-to-machine connection can be realized by using a single cable. This is what the USB debug capability can do. And the cable is not normal, A to A cable. The A to A cable is not allowed for USB 2.0. However, USB 3, the A to A cable is added to the specification here. And as in the CR cross cable, this USB 3, A to A cable has a cross connection to the RX and TX line. So you can buy the A to A cable. So let's move on to the previous slide. You can connect the two machines and activate the USB debug capability on the target. So you can get access to the USB device just like the legacy CL ports. That is, the USB debug capability can be realized. So let me explain the similar technologies before getting into the details of the USB debug capability. The first one is the Firewire. Firewire is considered a legacy interface that you can no longer see the Firewire on the motherboard. But this controller, OHCI, is a controller specification. It supports reading and writing memory on the other endpoint of the connection. The Firewire is basically a point-to-point connection in the vast topology. But reading a specific memory region or writing a memory region is in the specification. And this is considered a security issue that the hardware supports this kind of manipulation command. And it previously has an implementation that uses this memory access function to get a serial communication channel. So DCONS is a driver in a base system already for 20 years or so. And this realizes the serial access of a Firewire. So this is still a work game, but it's difficult for you to get the Firewire interface. And another technology that is quite similar is USB 2.0 debug capability. So Apple Air specification is almost the same as USB 3.0 debug capability. But USB 2.0 has only a pair of the data line on the USB. So it is impossible to have a cross cable. USB 2.0 shares the two wires on the center side, the receiver side, and the half-duplex communication between the two. So it is impossible to get a cross cable and impossible to distinguish the initiator of the communication and the receiver side of the communication. So reversing the wall is not possible. So specification says if you want to use the debug capability of the USB 2.0, you need a special repeater hardware at the intermediate between the debug host and the debug target. This is another endpoint that realizes the reversing the direction of the communication just like a cross cable. But this device is not available in the market. It is too special and it is very expensive. I have one or two, but it was $100 and $200. So it is not realistic for normal hardware. So I have an implementation for the USB 2.0 debug also, but I do not think it is worth considering. So let's move on to the implementation details. First, I will explain the knowledge that needs to understand the communication over USB. The first thing is how the legacy CL voice works. So CL communication is basically down by using the... It is difficult to read, but this is machine A and this is machine B connected to the single wire. So if you want to one byte from A to B by the serial communication, you have to prepare... Usually you prepare the SIFT register on both sides and the SIFT register means a register that can get a right-moist or left-moist bit by triggering the clock or something and shifting all of the bits to the right or right-to-left. In this case, one byte, 65 in hexadecimal can be transferred over the wire. So a single wire can have only one state or only two states by usually a voltage, the high or low. The high means one and the low means zero, but at the same time, a single one or zero can be transferred. So if you want to send eight bits, it must be done in a time-division manner. So first, the right-most bit is transferred to the machine B and the second clock, the second bit is transferred. So this operation can be done using the two identical SIFT registers on the machine A and the machine B. So this is the timeline and the two SIFT registers and after the one clock cycle, the right-most bit is transferred to the machine B's SIFT register. And the SIFT register is always left-to-right shifting. So at every clock, the bit by bit communication is realized over a single line. So this is how the LACCO communication works. So in the USB case, oh, it's difficult to see, but this is the machine A. So USB host controller and this is the machine B USB device controller. These two are connected using the USB cable and the logical connection is established between the two, the host controller and the device controller, as well as in the same way as the legacy CO ports. But the transferring of the data is not by bit by bit. It is a transfer unit. It is by the transfer unit. It's called transfer request block. So USB host controller has an array of the request transfer block. The transfer block has this 16-bit data structure. It is difficult to read, but the first 64-bit is a buffer address. And the third one is a length and the fourth one is a type or the flag. And this data structure points the data buffer that's to be transferred. And the host controller reads from the top to bottom. So the array of the TRB transfer request block and transferred the data to the receiver side, the device side. And the device, upon receiving the data on the receiver side, the device controller side, the same data is stored into the TRB structure. So what the software that wants to transfer data from machine A to the end-case of the host controller just put the data into buffer and construct the data that have the pointer to the buffer as TRB and put the TRB into the array of the host controller that is looking at. And there is no source address or destination of this concept like in the communication using Ethernet because this TRB array is prepared for each devices in the direction. So you do not need to specify the direction or communication endpoint, another endpoint. The buffer is prepared for the each device in each direction. So after putting the data, there is no need to further action on the software side. The host controller will pick up the TRB and data is transferred. And if it is completed, the event is sent to the host controller to the software as a complete or failure event. So just like a legacy server for the interface, just a task of the host controller is reading the data in the array. And actually an implementation is a ring buffer. So this structure is called as TRB ring frequently. And the ring can be realized by using the special type of TLB called the link TLB. Link TLB is, so type field is different. And this address, 64 bit address is value two point the next TRB. Without the link TLB, the host controller will read the next TLB by the size of the TLB, 16 bit. So this one and this one and this one, let's read the four TLB as 16 bit. So host controller can read the next one. But if the host controller detected a link TLB, host controller reads the buffer address as the next TLB. So putting the link TLB at the tail of this array, this array can be used as a ring buffer. Or if the device driver cannot get the contiguous memory region, TLB array can be segmented by using the link TLB. So there is no limitation of the total length. And one data pointed by this address can hold the maximum size is 64 kilobytes. So this transfer, the data transfer by using this structure is not so efficient, but it can reach the two, one or two gigabits. So this is a summary of the functions of the USB debug capability. So as I explained, the virtual device side controller can be realized by activating the USB debug capability. There has a minimal functionality because usually such a function is not required for USB host. And one of the ports can be converted to the host, to the device side function. And this device can be seen from other boxes as a normal USB device. But that device has two pipes, so virtual serial connection between the host controller, device controller, and explained in this slide. This is a pipe in the point and in the point. So two pipe is in and out. In and out means the direction. So device can send the data from the device to host and the host can send to the device. So bi-directional communication can be happened. And the speed is super speed, so 5 gigabits at least in a specification. And the maximum size of the USB pocket is one kilobytes. TLB can hold 64 kilobytes in a single TLB, but the pocket size itself is one kilobyte. And the host controller cannot see the port where the USB debug capability is activated. It is isolated from the main host controller logic. So after initialization, the OS cannot recognize that port as a normal USB port. And then the device, so virtual device side controller does not require the full USB stack. So as to specify the USB ring structure, so that requires the memory address of the TLB ring. After that, for example, the state management of the ports, USB ports, or managing the USB stack state machine, these kind of tasks are down in the hardware. So there is no need to prepare the USB software to handle the device side. So all you have to do is to construct the TLB and put it into the array. So after that, the controller will pick up and do the transfer. So using this function, it is easy to implement the getC or toC function. It is more than the legacy hardware, legacy hardware uses outB or inB, but constructing a TLB and put the data into the memory is not so complex. So even when the kernel goes wrong in this getPutC and getC function, it can do the necessary tasks to extract the information or providing the DDB access from the remote. So the debugging capabilities originally were actually designed for the transport of the more complex debug feature, the access to the debug feature inside the processor or debug device next to the processor like the JTAG. So Intel DCI is one of the big consumer of this transport, and this can export the internal state of the processors to the remote machine. So the debug host. But these features are not available in the normal hardware. So you can get in the market. But the capability itself is usable as a multipurpose, just a simple serial communication. So to get the serial console is one of the practical applications when using the debug capability. So software components for debug capability is summarized in this slide. On the debugging host, a normal USB-3 stack is sufficient because the host side is not required in any special feature. However, a client driver is required to access the USB device on the converted USB port on the debug target. Because the USB device has a special debug class, DC. So usually there is no driver for this. And so I wrote the UDBC driver for the simple serial communication over the debug capability. And on the debug target, the activation is required. And after the activation, you can get the one port as the USB device. After that, the TRB ring must be used to send or receive the serial communication. To realize the serial console as a legacy hardware, the console back end in the FVVC loader and kernel must be implemented. And the physical setup that I explained to the cable is a bit special, the A2A cable. And after activating the USB debug capability, one of the ports will disappear from the OS side. So one port is recognized as a USB device. But the problem is which port is actually converted after the activation. The answer is one of the ports. So one of the ports, and inserting the debug cable, the cross cable, just after the cross cable, that will be converted to the debug port. So you can choose one of the ports on the UDBC. The second problem is which port is connected to the UDBC. So your motherboard or laptop can have the multiple have internally. So if you have the 16 port on the motherboard, probably there are two or three have between the UDBC and the actual port. So it is difficult to find. There is no standard way to find which is connected to the UDBC. So you have to find which one actually works. And so any USB 2.0 ports do not work. Because 2.0 specification doesn't have a concept of a cross cable. So it is not supported by the USB debug capability. And so I am distributing the cable here. So if you are interested in, I will give away for the 20-year-old, please. And this small cable is A to A cable. And this is extension and A to C adapter and VST chart. So I have nine cable here. So if you are interested in it. And K Evans told me that this kind of cable is already available in the sound distributor. And I think you can get $10 or $20. So if you are interested in it, please take one here or find A to A cable. So I will show the demo here. Because one concern on my side is I am interested in how good the... So my implementation can work with the wide range of the hardware, including the AMD USB host controller. I tested Intel USB host controller. A lot of types and they all of them worked. But some models has a link-up issue. So before submitting the patches to the project, I would like to get more feedback. So if you are interested in it, please visit this URL. And this URL has a client-side driver. And on the debug target, the loader has some testing... Some testing command is available as a memostick image. So you can get the communication between the two machines with the close cable. So let's see the actual behavior by using the... So it is difficult to read, but I will show just a moment. So I am trying to boot from the memostick and then initialize the USB debug capability and after the initialization, I will show the screen by using a zoom function. So it is not so... I have the information, but this is a loader prompt. And the DVC something is I added to the loader. And I wrote the detailed instruction in the URL. If your hardware is working with the debug capability, the command displays the DVC-enabled DS and the DC-DV-running-eagle-DS. And in this state, one of the points of this small PC is acting as a device. It's connected to my MacBook. So MacBook can detect this device as like this. It's pretty common in Japanese characters, the Japanese version of the MacBook. But USB 3.0 have detects the previously USB DVC device. And yeah, manufacturing is a previously foundation, but this string can be changed in driver. But this is one of the steps that check if your hardware can work with the debug capability. After that, check the communication can be realized. So in testing instructions, the loader side, so this small PC side can send the string to the USB host. In this case, the MacBook, but the MacBook cannot have the client device. So I use the QMU to check if the client driver works. So if the privacy is connected to such a device over the close cable, UDBC driver can detect the existence. And this is a simple serial communication driver. So it creates the device noise under dev. So using a tip command, the UDBC is ready to receive the information. So in this state, I can send four Xs and the Xs appeared. I entered four Xs on this PC, and the string is transferred from this device to QMU on the MacBook. So this is the test that this functionality is working or not. So if you can try, please help testing the functionality. So I will submit the patches because this is a client-side driver, and the kernel side or loader side implementation is almost complete. But one thing I need to check is probing of the USB debug capability. So all of the Intel USB3 controller is... So all of the device ID is already implemented, already added, but the AMD lines or other chip vendors lines, I did not add them. So if you have non-intel architecture, or also non-intel architecture, please send the device ID and try to use the cross-gable to see if it works or not. And this is not an Intel or X86 specific, so it should be easy to port to other VSDs or other architectures. And the future work, this can actually be extended to mimic the other type of USB devices. The limitation is we cannot change the class ID or a device ID that is used to distinguish the USB type. So we have to write a client-side driver, but almost every normal machine can have a USB device port. So by using that, there are several useful and interesting features that can be implemented. One of the lifelines is target-disk mode. So after the loader runs a block device, it can be exported via the USB debug cell access. So it is useful for installing OS or diagnostics purpose. Okay, this is the summary. The first bullet and two bullets is already explained. And the fourth one is important. I need more information about the device compatibility. And if you're interested in it, please take this for 20 euros. Okay, that's all. Thank you. Can I have four questions? Or just... I'm sorry. No insistence in real console. So what do you mean by no insistence in real console? Yes, that works if the machine has a USB-3. So without any other serial option, it can be used. Any other questions? Okay. Did we beat your question again? So USB-C. Yes, still need to get a yes. And I tried to use the USB-C, but some USB-C connector had a link-up issue. So I have to investigate more. But if the USB-C or USB-A, it does not matter. There is no standard just providing the serial communication channel so you can put any data over them and just transfer the phone to the host-use device. And the B-more to GDB is standardized in the Linux Foundation. So there is no industrial standard about the Linux Foundation. They have their own ID for GDB B-more. So that ID can be used as what format is used or not. Thank you.