Attacking the Windows Nvidia Driver

Post by ksk » Thu, Feb 16, 2017, 9:12 PM UTC

sametmax wrote: post #9

cr0sh wrote: post #6

Earlier quoted context omitted.

Yeah - that sounds like fun - recreating a driver install issue after you finally have it working on your system. Heck, even if you set up a system -just- to recreate this problem, it would still be one of those "nightmare inducing" trials of will. I'm not saying it shouldn't be done, I just can't imagine doing it (especially on my personal workstation).

Plus you paid for the computer, graphic card and OS. Why in hell would you spend hours of work on your free time for this ? Do people try to find defects in their car then send a report to Ferrari ?

Post by sherincall » Thu, Feb 16, 2017, 9:14 PM UTC

rhcom2 wrote: post #41

Can someone give me a layman's definition of an "escape" and why they would be legitimately needed? Are they needed so callbacks can "escape" and be exposed to other classes? (does that make any sense?)

    void escape(int command, void *param);

    void escape(int command, void *param)
    {
        switch (command)
        {
            case COMMAND_FOO:
                do_foo((foo_param_t *)param);
                return;
            case COMMAND_BAR:
                do_bar((bar_param_t *)param);
                return;
        }
    }

Post by rhcom2 » Thu, Feb 16, 2017, 9:19 PM UTC

sherincall wrote: post #53

rhcom2 wrote: post #41

Can someone give me a layman's definition of an "escape" and why they would be legitimately needed? Are they needed so callbacks can "escape" and be exposed to other classes? (does that make any sense?)

It is very similar to an ioctl on Unix (DeviceIoControl on Windows), just specific to the Display/Video driver here. It is a way to send arbitrary data from usermode into kernelmode, for whatever reason. You can imagine the usermode interface as: void escape(int command, void *param); And then the kernelmode implementation would look something like: void escape(int command, void *param) { switch (command) { case COMM…

Post by Filligree » Thu, Feb 16, 2017, 9:28 PM UTC

louithethrid wrote: post #54

vvanders wrote: post #31

Earlier quoted context omitted.

That's true on split-memory architectures(desktop) but most mobile GPUs(and a couple consoles) use a unified memory model. Also most browsers use the GPU to speed up rendering so you can pick out things from there too potentially.

I wonder, do you really have to write zero to all the memorycells? Or can you just stop the refresh cycle in hardware and let squares of memory drain and die in one or two cycles?

Post by __jal » Thu, Feb 16, 2017, 10:12 PM UTC

bonzini wrote: post #37

__jal wrote: post #32

Earlier quoted context omitted.

Yeah, Nvidia rather sucks at cleaning up after themselves, for whatever reason. The main reason I'm not buying another card from them is their stance towards Linux in general and their stance towards PCI virtualization in particular. I'm currently not upgrading drivers due to the latter; they're trying to disable the capabilities (dedicating a card to a VM) that are the reason I bought a second card in the first plac…

If you're talking about GPU pass-through, they're just trying to make it hard, but they're not making it impossible. If you're talking about virtual GPUs, where one card is split across multiple VMs, however, unfortunately that's Tesla only. That said, I worked (as the maintainer of KVM) with the nVidia driver people working on vGPU, and I was very impressed. They were very knowledgeable and professional, and they ma…