Open-Source NVIDIA "Nouveau" DRM Changes Begin Queuing Ahead Of Linux 5.1

[starshipeleven]

Malware comes from malicious-software. It is not a technical term describing a group of used techniques . It describes behavior.
In other words, not every debug tool is malware, just because some malware could use debug tools.

What the fuck? Intercepting DMA is a "malware-like" action as it is something that would compromise the system if it was readily available to all applications.

In other words this specific action requires to override or disable specific security protections designed to block its potential use by malware.

[iive]

What the fuck? Intercepting DMA is a "malware-like" action as it is something that would compromise the system if it was readily available to all applications.

In other words this specific action requires to override or disable specific security protections designed to block its potential use by malware.

Disable what exactly? What are you talking about?

DMA is not security protection feature. Actually quite the opposite. See MMU vs IOMMU.

The mmiotrace is only accessible by superuser, not all programs. Linux kernel and userland contains a lot more powerful debugging tools.

I will ask you again to stop spreading FUD and misinformation.

[starshipeleven]

Disable what exactly? What are you talking about?.

the mmiotrace tool requires to have kernel features that are debug-only and not compiled in most production kernels for security reasons. As I said in the other post, btw.

CONFIG_MMIOTRACE is not set" and CONFIG_DEBUG_FS

The former is required to have the kernel module used by the mmiotrace userspace tools to actually do the job, and the debugfs is needed to get dumps of the data you are intercepting.

Even though a noveau developer said you can't modify mmiotrace to intercept DMAs, to the contrary of what you stated, https://www.phoronix.com/forums/foru...07#post1080307

The same basic concept remains, you still need a kernel module since the kernel on its own cannot intercept and dump DMAs at the tip of a hat, nor can userspace go and read random arbitrary memory to intercept what is sent around via DMA.
And you still need debugfs or another way to have the kernel dump the intercepted data in a place you can actually go and get it.

The mmiotrace is only accessible by superuser, not all programs.

It would be used by a malware payload, once malware has reached root privileges by other means.

You know what a Rootkit is? https://en.wikipedia.org/wiki/Rootkit It's a malware payload that is employed only AFTER the system has ben compromised, and is usually the actual goal of the attack.

I will ask you again to stop spreading FUD and misinformation.

I'm not the one spreading FUD here.

[iive]

MMIOTrace can't be "changed" to intercept DMA. It works by removing PTEs on the relevant mmio areas, and installing a page fault handler which emulates the underlying instruction and figures out what address it would have read/written with what value.

In order to "intercept" the DMA, one would either have to do the same with an IOMMU, where I think faults aren't so easy to handle, and it's unlikely to be possible to restart the source transactions. A more probable approach is to make something that analyzes the trace data in real-time, and when it's detected that certain commands are being sent to the hardware, to also access the system memory which those commands are telling the GPU to retrieve data from.

The later seems quite feasible to do, especially if it is a one time thing.

Do you know who initiates the DMA transfer?
The drivers might ask the host to push the data to the card, or the driver might issue GPU command that would initiate pull transfer.
I guess it is the latter, otherwise it would be trivial to dump the dma buffer before initiating transfer, since it should be calling internal kernel functions to do that (and the specific host driver).

I took a quick look at IOMMU, it seems that it needs buffers to be dma_map()-ed before use and dma_unmap()-ed they are no longer needed. The buffer could be dumped at map and mmiotrace could track the access to the buffer memory.

I'm quite surprised that you've managed to get so far by just mmio without dma intercept.
For example Radeons fetch Command Stream with DMA.

Also, to clarify, the signed firmware is just a blob of data. Once it's identified, it's usually easy to make a tool that extracts it. I've even made a scanner that looks for firmware-type blobs in the code. https://github.com/envytools/firmware . I did this for the video decoding accel firmware, for example, as well as various gr firmware (fecs, gpccs).

Of course, once we have the firmware and can load it correctly (which is no easy feat), that's still only like 10% of the battle. Now we have to interact with this firmware properly in order to perform reclocking. It's not like one command, it's going to be a very complex procedure, heavily involving VBIOS table data, etc.

All in all, stick to Kepler. Or get AMD.

You know, we love creating more work for you

And I do agree with you. Get AMD.