Skip to main content
added 1239 characters in body
Source Link
user123
  • 1.1k
  • 5
  • 5

The transfer is DMA so it isn't really the other programs which create periodicity. It is more like bus-mastering and the speed with which the device answers the read and write commands. I assume you are on Windows desktop with an x86-64 CPU. On these desktops an xHCI is used to transfer data. I actually wrote a partial xHCI driver which I have not finished yet.

I can tell the xHCI supports MSI-X. The xHCI thus can trigger interrupts directly to the local APIC of one specific CPU core. The currently running program on the core is interrupted and the TSS is used to switch the stacks if there was a ring 3 to ring 0 transition. Otherwise, the interrupts are simply nested on the same stack. The interrupts are short lived because they don't do the main work. They simply do some work to add the interrupt to the queue of programs that the OS will then switch on using the scheduler. The data Transfer Event TRB is probably also read by the driver and it pushes the data of the TRB to some other place. This is called Bottom-Half Interrupt Processing. The TRB informs software of the size of the transfer (for more info see When are a controller's registers loaded and ready to inform an I/O Operation?).

The periodicity can be created by file switching. One file can be "programmed" to be read/written to a USB stick to a specific address at once whatever the file's size) but you cannot tell the xHCI to just write to a device with five different addresses and tell it to read the files from 5 different addresses. There is some processing involved by software on file switch that can create periodicity in the transfer.

The scatter gather operations can create periodicity because the virtual memory is contiguous but not physical memory. The physical memory is separated in chunks of 4KB so the buffer allocated to your program (the built-in file explorer) may be bigger than a page and be scathered around RAM. To avoid that you can use one buffer of 4KB but that makes the operation slower because you need to schedule the operation several times to read into the buffer. Instead, file explorer probably makes the buffer much bigger and let the OS do the scather gather by putting several TDs on the Transfer Ring of the endpoint for that device. The TDs contain TRBs and specify physical addresses so the OS must make sure that the transfer doesn't overwrite parts of the address space of another process. It must also pin the pages to physical memory instead of swap because DMA transfers are writing directly to it. If the OS swaps the page-frame to the hard-disk and give the page-frame to another process, the DMA engine is writing to another process's address space. This is very dangerous and could be a potential vulnerability. There have been some vulnerabilites known in the past so this is actually something that can happen in a recent OS (because it happened in recent years but I don't know if there are current vulnerabilities).

A lot of other things can create periodicity. It is a very complex operation which involves bringing the data to RAM and then sending the data back to the other device.

Also, I didn't read the xHCI spec for the bulk transfer part. Bulk transfers seem to be the way to transfer data from a mass storage device to RAM or vice-versa. Maybe start to read the spec and you'll have all the info you need. The spec is linked on my answer that I linked above.

The transfer is DMA so it isn't really the other programs which create periodicity. It is more like bus-mastering and the speed with which the device answers the read and write commands. I assume you are on Windows desktop with an x86-64 CPU. On these desktops an xHCI is used to transfer data. I actually wrote a partial xHCI driver which I have not finished yet.

I can tell the xHCI supports MSI-X. The xHCI thus can trigger interrupts directly to the local APIC of one specific CPU core. The currently running program on the core is interrupted and the TSS is used to switch the stacks if there was a ring 3 to ring 0 transition. Otherwise, the interrupts are simply nested on the same stack. The interrupts are short lived because they don't do the main work. They simply do some work to add the interrupt to the queue of programs that the OS will then switch on using the scheduler. The data Transfer Event TRB is probably also read by the driver and it pushes the data of the TRB to some other place. This is called Bottom-Half Interrupt Processing. The TRB informs software of the size of the transfer (for more info see When are a controller's registers loaded and ready to inform an I/O Operation?).

The periodicity can be created by file switching. One file can be "programmed" to be read/written to a USB stick to a specific address at once whatever the file's size) but you cannot tell the xHCI to just write to a device with five different addresses and tell it to read the files from 5 different addresses. There is some processing involved by software on file switch that can create periodicity in the transfer.

A lot of other things can create periodicity. It is a very complex operation which involves bringing the data to RAM and then sending the data back to the other device.

Also, I didn't read the xHCI spec for the bulk transfer part. Bulk transfers seem to be the way to transfer data from a mass storage device to RAM or vice-versa. Maybe start to read the spec and you'll have all the info you need. The spec is linked on my answer that I linked above.

The transfer is DMA so it isn't really the other programs which create periodicity. It is more like bus-mastering and the speed with which the device answers the read and write commands. I assume you are on Windows desktop with an x86-64 CPU. On these desktops an xHCI is used to transfer data. I actually wrote a partial xHCI driver which I have not finished yet.

I can tell the xHCI supports MSI-X. The xHCI thus can trigger interrupts directly to the local APIC of one specific CPU core. The currently running program on the core is interrupted and the TSS is used to switch the stacks if there was a ring 3 to ring 0 transition. Otherwise, the interrupts are simply nested on the same stack. The interrupts are short lived because they don't do the main work. They simply do some work to add the interrupt to the queue of programs that the OS will then switch on using the scheduler. The data Transfer Event TRB is probably also read by the driver and it pushes the data of the TRB to some other place. This is called Bottom-Half Interrupt Processing. The TRB informs software of the size of the transfer (for more info see When are a controller's registers loaded and ready to inform an I/O Operation?).

The periodicity can be created by file switching. One file can be "programmed" to be read/written to a USB stick to a specific address at once whatever the file's size) but you cannot tell the xHCI to just write to a device with five different addresses and tell it to read the files from 5 different addresses. There is some processing involved by software on file switch that can create periodicity in the transfer.

The scatter gather operations can create periodicity because the virtual memory is contiguous but not physical memory. The physical memory is separated in chunks of 4KB so the buffer allocated to your program (the built-in file explorer) may be bigger than a page and be scathered around RAM. To avoid that you can use one buffer of 4KB but that makes the operation slower because you need to schedule the operation several times to read into the buffer. Instead, file explorer probably makes the buffer much bigger and let the OS do the scather gather by putting several TDs on the Transfer Ring of the endpoint for that device. The TDs contain TRBs and specify physical addresses so the OS must make sure that the transfer doesn't overwrite parts of the address space of another process. It must also pin the pages to physical memory instead of swap because DMA transfers are writing directly to it. If the OS swaps the page-frame to the hard-disk and give the page-frame to another process, the DMA engine is writing to another process's address space. This is very dangerous and could be a potential vulnerability. There have been some vulnerabilites known in the past so this is actually something that can happen in a recent OS (because it happened in recent years but I don't know if there are current vulnerabilities).

A lot of other things can create periodicity. It is a very complex operation which involves bringing the data to RAM and then sending the data back to the other device.

Also, I didn't read the xHCI spec for the bulk transfer part. Bulk transfers seem to be the way to transfer data from a mass storage device to RAM or vice-versa. Maybe start to read the spec and you'll have all the info you need. The spec is linked on my answer that I linked above.

Source Link
user123
  • 1.1k
  • 5
  • 5

The transfer is DMA so it isn't really the other programs which create periodicity. It is more like bus-mastering and the speed with which the device answers the read and write commands. I assume you are on Windows desktop with an x86-64 CPU. On these desktops an xHCI is used to transfer data. I actually wrote a partial xHCI driver which I have not finished yet.

I can tell the xHCI supports MSI-X. The xHCI thus can trigger interrupts directly to the local APIC of one specific CPU core. The currently running program on the core is interrupted and the TSS is used to switch the stacks if there was a ring 3 to ring 0 transition. Otherwise, the interrupts are simply nested on the same stack. The interrupts are short lived because they don't do the main work. They simply do some work to add the interrupt to the queue of programs that the OS will then switch on using the scheduler. The data Transfer Event TRB is probably also read by the driver and it pushes the data of the TRB to some other place. This is called Bottom-Half Interrupt Processing. The TRB informs software of the size of the transfer (for more info see When are a controller's registers loaded and ready to inform an I/O Operation?).

The periodicity can be created by file switching. One file can be "programmed" to be read/written to a USB stick to a specific address at once whatever the file's size) but you cannot tell the xHCI to just write to a device with five different addresses and tell it to read the files from 5 different addresses. There is some processing involved by software on file switch that can create periodicity in the transfer.

A lot of other things can create periodicity. It is a very complex operation which involves bringing the data to RAM and then sending the data back to the other device.

Also, I didn't read the xHCI spec for the bulk transfer part. Bulk transfers seem to be the way to transfer data from a mass storage device to RAM or vice-versa. Maybe start to read the spec and you'll have all the info you need. The spec is linked on my answer that I linked above.