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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • iive
    replied
    Originally posted by imirkin View Post
    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.

    Originally posted by imirkin View Post
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by iive View Post
    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.

    Leave a comment:


  • iive
    replied
    Originally posted by starshipeleven View Post
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by iive View Post
    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.

    Leave a comment:


  • imirkin
    replied
    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.

    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.

    Leave a comment:


  • iive
    replied
    Originally posted by lucrus View Post
    So absurd that they actually match what others said:

    Then maybe nouveau devs are all stupid, but luckily there's you to show them how to extract the firmware from the official drivers and load it into the GPU, right?
    The "others" don't seem to be developers and they don't seem to collaborate your "explanation".

    It is absurd for the driver to sign the firmware. It means that the driver also contain the signing key. That key is far more valuable, as once it is found-out, it could be used to sign any custom created firmware. This is the reason the private key is kept in safe place in NVidia and the public key is placed inside the card.

    Now, the driver might contain the firmware in obfuscated form, it may need to be decrypted before uploading. However the driver still needs to have the key for decrypting the file. At the end, it just means that extracting the firmware might need a bit more complicated program than a script.

    Originally posted by starshipeleven View Post
    Actually intercepting DMA commands is just malware-like.
    You want to know why? That tool does require debug features to be actually compiled in the kernel, and like most debug tools they are obvious gaping security holes, that aren't usually enabled in production kernels. https://www.mjmwired.net/kernel/Docu.../mmiotrace.txt

    For example I would have to recompile my own kernel on OpenSUSE as "CONFIG_MMIOTRACE is not set" and I would also need CONFIG_DEBUG_FS.

    Also, its usage does not seem that easy to automate either if I read that readme correctly.

    Why this matters? Because you can't just have an experienced dev run this on select GPUs to extract the firmware and then redistribute it, as this would violate NVIDIA's license.

    You would have to make a script that can do this on client PCs, and you would have to ask your users to recompile and install a debug-enabled kernel for this trick to work.

    Is it possible? yeah. But I guess it is a massive PITA as if it was "just improving the mmiotracer" they would have done it already.
    I repeated what imirkin has said.
    Originally posted by imirkin View Post
    This would require a much more sophisticated tracer that no one's bothered to write yet.
    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.
    Don't spread FUD.

    You are correct that the firmware obtained through mmiotracer cannot be distributed, for legal reasons. It's however because its copyright is owned by NVidia, not because it breaks the license. Indeed it is a minor distinction, but it's the loophole that allows firmware extraction by users.

    Finding out how to obtain the firmware from the binary drivers might require some RE and this is also legally risky for the developers. They should not be tainted by RE.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by iive View Post
    Actually it is just improving the mmiotracer to intercept DMA commands.
    Actually intercepting DMA commands is just malware-like.

    You want to know why? That tool does require debug features to be actually compiled in the kernel, and like most debug tools they are obvious gaping security holes, that aren't usually enabled in production kernels. https://www.mjmwired.net/kernel/Docu.../mmiotrace.txt

    For example I would have to recompile my own kernel on OpenSUSE as "CONFIG_MMIOTRACE is not set" and I would also need CONFIG_DEBUG_FS.

    Also, its usage does not seem that easy to automate either if I read that readme correctly.

    Why this matters? Because you can't just have an experienced dev run this on select GPUs to extract the firmware and then redistribute it, as this would violate NVIDIA's license.

    You would have to make a script that can do this on client PCs, and you would have to ask your users to recompile and install a debug-enabled kernel for this trick to work.

    Is it possible? yeah. But I guess it is a massive PITA as if it was "just improving the mmiotracer" they would have done it already.

    Leave a comment:


  • lucrus
    replied
    Originally posted by iive View Post
    If you don't know, then please, don't make absurd speculations.
    So absurd that they actually match what others said:

    Originally posted by starshipeleven View Post
    Afaik this was not possible because you can only load signed firmware, extracting it from the blob driver does not yeld a properly signed firmware.
    Originally posted by iive View Post
    The firmware is signed from nvidia before been distributed
    Then maybe nouveau devs are all stupid, but luckily there's you to show them how to extract the firmware from the official drivers and load it into the GPU, right?

    Leave a comment:


  • iive
    replied
    Originally posted by lucrus View Post
    I'm afraid it's harder than you believe. If I got it right, the "signed" firmware has to be "signed". I don't know the details, but I believe you can't just cut it out of a driver file and expect the GPU will load it. I understand that the driver must sign the damn blob once per GPU, maybe using a GPU public key and a NVidia private key or something like that. Not sure anyway, just guessing, but there must be a real reason for that (well deserved) finger...
    If you don't know, then please, don't make absurd speculations.

    The firmware is signed from nvidia before been distributed. The check of the signature is done by the card that has the (public) key.
    It just makes sure that the uploaded code is the same as the one signed.

    Originally posted by starshipeleven View Post
    One of the developers said why they don't do that. https://www.phoronix.com/forums/foru...07#post1051307

    It basically boils down to writing some pretty malware-like software to intercept this firmware loading process.

    I quite frankly still think that the lack of any progress in this field is beyond suspicious, I mean if you can't reclock the card anyway, then Noveau is more a hobby project than something actually useful.
    Actually it is just improving the mmiotracer to intercept DMA commands.

    Leave a comment:


  • bemerk
    replied
    We don't need custom firmware and the signing keys, just a few files. Nvidia gives out some of them, to make the hardware work, but just not enough to allow nouveau to come closer to the binary one. Someone fears that nouveau will steal the show or so. Cracking the key is impossible, but cutting out the necessary files in a script should be possible if someone skilled is looking for it.

    Leave a comment:

Working...
X