Nvidia – Linux Ice-jam Melts

Nvidia’s devices have been a sore point for Linux development for a decade or longer. Reverse-engineering works but it’s not perfect. Nvidia has promised to be more forthcoming in the future.
“Torvalds has responded to Ars, saying he’s optimistic but not quite ready to apologize to Nvidia. "We’ll see," Torvalds wrote in an e-mail. "I’m cautiously optimistic that this is a real shift in how Nvidia perceives Linux. The actual docs released so far are fairly limited, and in themselves they wouldn’t be a big thing, but if Nvidia really does follow up and start opening up more, that would certainly be great.”

via Nvidia seeks peace with Linux, pledges help on open source driver.

Of course, Nvidia has been quite happy that Android/Linux has pumped $billions into their coffers. It just took a while for them to see that it pays to be open with specifications.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , . Bookmark the permalink.

34 Responses to Nvidia – Linux Ice-jam Melts

  1. Dr Loser says:

    And to illustrate one single point of ignorance:

    Dr Loser system memory cannot be in ram if its not in Physical memory.

    What I am about to point out is irrelevant to the argument, but still.

    System memory can indeed be in RAM but not anywhere else. It’s called a RAMdisk. This is how you boot up things like QNX.

    I have written such a thing. I have written device drivers. I have written firmware.

    You have done none of these things and you do not have the faintest clue how they all fit together. You’re not even that good at finding relevant links.

    Give it up, please. This is getting dull.

  2. Dr Loser says:

    What you are completely missing is the MMIO registers set what memory a device can read and write to. MMIO is the addresses the device is using todo DMA transfers to.

    Means to set physical address into MMIO registers instead of virtual means you get to avoid the OS setup page tables.

    No it doesn’t, oiaohm. It means nothing of the sort. You’re the one who brought IOMMU up: go and read about it. This is precisely why IOMMU is there. Plus which, as a bonus, it mediates between virtualised machines and physical machines.

    Dr Loser. Nvidia does not use separate firmware files to driver. Majority of Nvidia GPU firmware is software load. Nvidia video cards before Nvidia driver is load have quite min functionality.

    It doesn’t actually matter, does it? The firmware resides and operates on the card. The rest of the driver resides and operates in the kernel. Do stop splitting non-existent hairs.

    MMIO registers device side is by X86 design is not required to match up to a OS mapped zone. Stupid enough this is so you can run old like dos based stuff.

    However, a modern OS (be it Linux or Solaris or Windows or OS/X or whatever) enforces this “mapped zone,” wherever you’ve dredged that absurd term up from. There’s no point in bringing DOS up. We no longer live in the 1980s (although I’m beginning to suspect that you live in the Middle Ages). See, again, IOMMU. Although double-buffering is possible, the usual mechanism is to reserve an area of “system memory” for something that is not actually “system memory” but is in fact “device memory.” There are protection mechanisms on the PCI* buses for this, on whatever operating system and using whatever chip-set.

    Don’t you think that, NVidia aside, somebody might have noticed if there weren’t? Of course they would have.

    Still, at least you’ve stopped inventing nonsense about the effect of NVidia drivers on Windows. And at least you’ve shut up about firewire and so on.

    With only a little more effort, you can perhaps concentrate on a single point at issue, and with a bit of luck supply some illustrative code or a useful link — not something off a Nouveau discussion page.

    I’m not holding my breath. But you’re a lovely ignorant little chap, and I want to give you the benefit of the doubt.

  3. oiaohm says:

    What you are completely missing is the MMIO registers set what memory a device can read and write to. MMIO is the addresses the device is using todo DMA transfers to.

    Means to set physical address into MMIO registers instead of virtual means you get to avoid the OS setup page tables.

    What ever is currently in CPU ram can be altered by the Nvidia card.

    When it comes to devices there is only 1 physical memory. Physical memory is the direct address of ram sitting off the memory controller/s.

    Dr Loser to split memory as OS do you create virtual memory using Page Tables. The map kernel side Dr Loser is virtual has always been virtual.

    Dr Loser you don’t understand the basic meaning of Physical memory. MMIO with physical address settable is identical problem to some malware getting into kernel space and setting the page tables flat (1 to 1 addressing between physical and virtual).

    Basically all those magical separate areas disappear as soon as you can set physical addresses into MMIO registers.

    This is a x86 and other bad chipset design things. MMIO registers on PowerPC cannot ever work with a direct physical address. PowerPC demands always virtual from devices.

    Please note in Physical memory mode on x86 arch there is no such thing as read/write protections. You have to be in virtual addressing mode to have read write protection over areas of memory.

    Yes Dr Loser all those OS protections you are talking about are non existent to a MMIO register set to physical address then a dma read/write performed using that MMIO register.

    Dr Loser. Nvidia does not use separate firmware files to driver. Majority of Nvidia GPU firmware is software load. Nvidia video cards before Nvidia driver is load have quite min functionality.

    You have to be ring 0 to load firmware image into devices. Yes Nvidia cards lose there operation firmware when you power off. Majority of the Nvidia firmware for Nvidia cards is stored in ram on the Video cards.

    Firmware file is not much different to a icons and other files you can embed inside executables.

    Dr Loser system memory cannot be in ram if its not in Physical memory. So what does Windows page out its kernel memory when ever it interfaces with a device. I think not.

    The only ways to prevent system memory being access if you have Physical address is the following.
    1) don’t have system memory in ram while accessing inside CPU cache is file. This does not work with devices because you don’t know when a device is going to write.
    2) run fully checksumed memory with encryption signing matching the CPU to make sure no memory can be tampered with.

    Dr Loser you are thinking of MMIO from CPU side too much.

    MMIO registers device side is by X86 design is not required to match up to a OS mapped zone. Stupid enough this is so you can run old like dos based stuff. OS’s that don’t use page tables and virtual addressing or protections. Problem here is that when you turn on virtual addressing CPU side this is does not restrict/block physical addressing from devices. So you are depending on firmware to use virtual addressing.

    IOMMU was invented as a man in middle to handle virtual address translation. Its slow. So by stupidity using IOMMU you can still have a cache of physical address on your device. That you should receive a clear message if the memory map has been moved out of ram or something else on x86.

    Reality Virtual address processing to physical address for devices really should be part of the core chip-set not dumped back on devices.

  4. Dr Loser says:

    oiaohm: first off, I stand corrected. As you say, if you believe Marcin Kościelnicki, there is a possible security flaw in the binary blob.

    It’s not clear how serious, though. Marcin KoÅ›cielnicki is not an expert in the field, is looking at the decompiled microcode, and is making various assumptions. He is not actually offering sample code that proves an issue, let alone substantiates your hysteria:

    Just happens Nvidia firmware just happen to be another place where you can set MMIO registers directly to what ever you want.

    No, that does not “just happen” at all, in any meaningful sense. Given firmware support on the device side (not the kernel side), you can always “set MMIO registers directly to whatever you want,” but that’s meaningless. What’s important is what they map to on the kernel side.

    Now, Mr Kościelnicki goes on to suggest is

    The PGRAPH context switch microcode allows user to read/write arbitrary
    MMIO registers by submitting the firmware methods. The GF100+ video decoding etc. falcon microcodes allow you to just ask for physical instead of virtual addressing, and that includes physical system memory.

    Notice that he’s talking about MMIO registers; not about memory-mapped file IO. Just to be clear, this means that we are not talking about DMA, either System or Bus-Mastered.

    We’re talking arbitrary registers, not arbitrary system memory.

    What happens here is that the NVidia card reads/writes an IO register, which is mapped to memory on the CPU side. (Incidentally, properly set up, the physical memory here should be a separate area from “system” — ie general-use — memory. Your stated problem therefore does not arise.)

    As far as I can see, therefore, Mr KoÅ›cielnicki Is being loose with his terminology. You do not “access physical system memory” via MMIO registers, not unless for some peculiar reason the system itself has mapped those registers to physical system memory, which it shouldn’t.

    Back to your mention of firewire. Firewire (and PCMCIA) have a completely different interface to physical system memory, which is why they are potential security risks. But they have nothing in common with NVidia drivers. Please stop suggesting that the two are in any way related; you’re just confusing yourself.

    Read my first clearer. Nvidia drivers GPU cannot come on line until PGRAPH part is loaded. The PGRAPH firmware binary blob is embedded inside the Nvidia driver that gets loaded up into kernel space.

    I don’t believe that it is “embedded” in this way, unless “firmware” means something completely different in this single case. I would expect “firmware” and “microcode” to be things that operate on the NVidia card itself, not in the kernel. Perhaps you have other evidence? This “first link” of yours isn’t very persuasive or informative on the matter.

    In short: shut up about firewire. It is not relevant. Demonstrate, either with code or with a link, that a security hole exists. While you’re at it, demonstrate that this hole affects Windows, which it quite clearly does not even on your terms.

    At the moment you don’t seem to understand how firewire works, you don’t seem to understand MMIO registers, you don’t seem to understand the use of firmware, and you don’t seem to understand virtualisation (I got a bit tired, so I haven’t bothered going into that).

    That’s quite a collection of things you don’t seem to understand. What do you understand?

  5. oiaohm says:

    Dr Loser you don’t know the topic and you admit it you are failing to be able to read the terms.

    MMIO registers by pure evil of x86 arch are setable from the device side of the bus. If they were not setable from the device side of bus the fire-wire attack would not have been possible.

    Just happens Nvidia firmware just happen to be another place where you can set MMIO registers directly to what ever you want without proper OS/hyper-visor approvals.

    You have presumed to your very big mistake Dr Loser that I cannot read it.

    I understand what the MMIO registers are. I used the term System DMA because you did. MMIO registers is how to do System DMA but from the device side.

    Dr Loser your theorising is complete crap.

    Defective firmware does not require open source driver to exploit. All it requires is something in kernel space able to send the command to the device. Does this mean I have to get my code into kernel space no. All it requires is some defective driver.

  6. oiaohm says:

    –The PGRAPH context switch microcode allows user to read/write arbitrary
    MMIO registers by submitting the firmware methods. The GF100+ video
    decoding etc. falcon microcodes allow you to just ask for physical
    instead of virtual addressing, and that includes physical system memory.
    Why did nVidia include such obviously security-breaking functionality in
    the firmware images? —

    Note the last line. Dr Loser. This is clearly Nvidia firmware this is not Nouveau.

    Dr Loser you want to know how this turns into attack. At this stage the attack is non effective. Use VT-d functionality to pass Nvidia card to a guest OS under a hypervisor. The system dies if you load up Nvidia drivers.

    Ok now where is the very big problem here. What loads the firmware into a VT-d device the Guest OS because Nvidia is not properly VT-d compatible.

    The firewire problems happened due to poor handling of MMIO register access by firewire firmware. Firewire case was worse you could set what you wanted the MMIO registers set to over the Firewire cable. Result you could read anywhere from a independent computer.

    Nvidia case the MMIO is limited if Nvidia kernel space is secure to something that has breached kernel space and can send commands to hardware problems can happen.

    Nvidia PGRAPH flaw is a Hyper-visor breaker. You take the guest OS then you can take the hosting os of the Hyper-visor as well.

    Badly design MMIO handling by cards on x86 chip sets is hazard.

    X86 MMIO is completely fun that the device can set values into MMIO without CPU or OS approval.

    The fact that PGRAPH was Nvidia was in my first link.

    Read my first clearer. Nvidia drivers GPU cannot come on line until PGRAPH part is loaded. The PGRAPH firmware binary blob is embedded inside the Nvidia driver that gets loaded up into kernel space.

    Please also note the version number on Nvidia drivers for Windows and Linux is identical because they contain the same firmware. The code that happens after the firmware around is different Dr Loser.

    Yes if Nvidia Drivers was correct Windows 7 and 8 would work on a machine using Hyper-V with VT-d pass through of the video card.

    Yes Dr Loser broken MMIO register usage equals not safe to use with Hyper-visor at min.

    The problem Dr Loser the secuirty issue is writing in my first post. Miss usage of the MMIO registers firmware side by Nvidia.

    Does a wild expliot have to exist for something like this no. Its still a secuirty flaw even if its not exploited yet. Its more good luck that the case where it is a secuirty flaw the result of the bad MMIO normally crashes the system.

    Yes DR Loser this is a flaw and system crash.

  7. Dr Loser says:

    I’ll expand a little bit further on oiaohm’s link, if I may. And I’ll ignore the fact that it links to Phoronix, which isn’t really source material for anything.

    It’s beginning to look like Dougie might be right, and that NVidia binary blobs are currently the way to go:

    Besides this initial FUC microcode firmware issue, the Nouveau developers are also struggling with re-clocking support / power management / fan control, which hopefully they’ll have made more progress on in time for the next kernel merge window in a couple of months. Most NVIDIA Fermi owners will be best off right now using the proprietary NVIDIA Linux driver.

    Note, oiaohm, that this has nothing at all to do with your spurious claims of “System DMA” security problems.

    Also:

    As a result, most NVIDIA GeForce 400/500 owners have kernel mode-setting if using the open-source driver, but there’s no acceleration.

    Once again, talking about hardware acceleration; not about security.

    My tentative conclusions so far?

    Robert is making sense. If you don’t need hardware acceleration on NVidia cards, use a FOSS alternative.

    Dougie is making sense. If you want full support of a recent NVidia card on Linux, use the binary blob.

    oiaohm is flailing around inside the confines of his own mind. I’m still waiting for any evidence of security issues here.

  8. Dr Loser says:

    No, oiaohm, firewire issues have nothing at all to do with NVidia drivers. It’s a completely separate issue. Stop making things up.

    I’m indebted to your link to find that PGRAPH is in fact the name of a bit of NVidia microcode. Other than that, it tells me nothing. It talks purely of producing a FOSS alternative. It doesn’t talk about vulnerabilities.

    You have yet to produce any indication of a Windows vulnerability. All you’ve got so far is a potential vulnerability on Linux, and I stress potential. I’m theorising that it applies only to Nouveau, and you’re claiming that it applies to the binary blob as well (although you have no proof of this).

    Are you seriously trying to prove that Windows is more secure than Linux? Because that certainly appears to be the thrust of your argument.

    And no, nobody uses System DMA any more, at least on Intel chipsets. I’ve found some indications that it’s used on ARM chipsets, but I’m dubious even there.

  9. oiaohm says:

    Dr Loser the fireware exploit post 2000 is the same problem.

    PGRAPH http://lists.freedesktop.org/archives/nouveau/2013-September/014497.html is Nvidia blobs not Nouveau DrLoser. The function in the Nouveau blob to get application memory has a different name completely.

    –Correct me if I’m wrong, but PGRAPH is a “Printer Graphics Library” on Linux, isn’t it? Not on Windows?–
    There is no such Library in Linux. Linux printers take postscript or pdf. So there is no special printer format.

    http://www.phoronix.com/scan.php?page=news_item&px=OTQ4NA

    NVIDIA PGRAPH firmware has to be replaced to fire up Nvidia video cards so you can transfer data from System Memory to GPU Memory.

    Simple reality Dr Loser if you have not loaded up Nvidia PGRAPH or replacement Nouveau firmware Nvidia video cards are bricks.

    Please note the Nouveau firmware to replace NVIDIA PGRAPH is not called PGRAPH. Dr Loser PGRAPH is a unique Nvidia name for one of the firmware blob.

    Dr Loser Nvidia blobs has been choosing speed not security.

    PGRAPH firmware bit is a bit that should be open to independent audit. Even if nvidia open source the PGRAPH thinking it only deals with transfering memory from system to gpu it does not expose internal tricks of the GPU.

  10. Dr Loser says:

    Please stop trying to pretend you know anything about deice drivers, oiaohm. Clearly you do not. You have not provided either:
    1) A link suggesting that there is a security issue for NVidia on Windows (or for that matter using the binary blob on Linux)
    2) Code demonstrating a security issue of any kind

    I stand by my previously stated position:

    1) The DMA issue you fantasise about does not exist on Windows.
    2) It almost certainly doesn’t exist on the Linux binary blob.
    3) Your own link suggests that it exists on early versions of Nouveau, but it’s being fixed.

    The only person in the whole wide world who thinks that this is a problem either on Linux or on Windows is you. The only reason you think it’s an issue is because you don’t know what you’re talking about.

    Dr Loser the problem you are missing is the device does not require CPU permission to enable the old style System DMA. System DMA is still fully present in the Chipset.

    Really? I doubt it. But even if so, you have no evidence that any driver other than Nouveau is “turning it on.”

    PGRAPH in Nvidia FIrmware is turning that back on.

    It seems to be in Nouveau at the moment, yes. Correct me if I’m wrong, but PGRAPH is a “Printer Graphics Library” on Linux, isn’t it? Not on Windows?

    Dr Loser you also forget Nvidia and Microsoft had a big blow up when Vista was released. Nvidia basically said they would not release drivers if Microsoft did not let them do what they wanted.

    Is this relevant? How?

    The firewire DMA breach happened after the year 2000 DR Loser where have you been.

    This has nothing at all to do with NVidia drivers, does it? Contantinople fell to the Turks in 1453, oiaohm. Where have you been?

    As the old IT saying goes “You can have Performance or Security pick one”.

    As my link implies, oiaohm, Windows post-Vista picked Security. I presume the NVidia binary blob also picked Security. It appears that Nouveau is developing towards Security.

    You have nothing here but inconsequential gibberish, do you?

  11. oiaohm says:

    Dr Loser what GPU_allocate is evilly doing is getting the Physical address from the Virtual Address zone the OS has given in then its the Physical passed to the card. Or what it thinks to be the Physical address. Just to be fun with page tables you don’t need the OS permission to look up what is the what it thinks is the Physical Address either.

    Sorry Dr Loser the ugly reality is yes the Nvidia takes its own independent address space to the OS then goes and used Physical Address of that zone from the Device.

    To use true independent zone you have to use iommu to do translations between Virtual Address to Physical so Virtual Address and page table reference goes to device. Nvidia by passed this Dr Loser why iommu is a slow item when you have to process page tables.

    Your time of death of the problem is wrong Dr Loser. OS Core activated system DMA died out in Linux before the Year 2000. Version 2.0 Linux in fact well before Year 2000.

    Dr Loser System DMA is only alive and kicking due to parties making drivers trying to win performance competitions and the fact chip-set never removed the functionality.

    As the old IT saying goes “You can have Performance or Security pick one”.

    Nvidia some FIrewire drivers some Raid controllers and a few other strange odds and ends are still using System DMA due to the fact is faster. Yes ruined your system security but its faster.

    Dr Loser you also forget Nvidia and Microsoft had a big blow up when Vista was released. Nvidia basically said they would not release drivers if Microsoft did not let them do what they wanted.

    Nvidia has been quite an ass to everyone. Yes Linus giving Nvidia the finger has been the best thing going. It made Nvidia wake up they are impressing no one being an ass.

  12. oiaohm says:

    Dr Loser the problem you are missing is the device does not require CPU permission to enable the old style System DMA. System DMA is still fully present in the Chipset. PGRAPH in Nvidia FIrmware is turning that back on.

    Only way to make sure System DMA is never turned on is to make sure all the firmwares in your system don’t enable it.

    Yes there is a problem with the X86 chipset.

    The firewire DMA breach happened after the year 2000 DR Loser where have you been. Yes Firewire DMA flaw can attack even windows 8 on systems with defective Firewire firmware. Note you said that was done in the year 2000 so how did the fireware reading and write all physical system memory happen.

    This is the problem Microsoft has not got it under control. Only 2 solutions can truly fix it.

    1 the ideal the CHIPSET loses the functionally of SYSTEM DMA complete particularly device side activated.
    2 all firmwares get audit to make sure none contain SYSTEM DMA requests.

    Legacy hardware support is a ass.

  13. Dr Loser says:

    It’s always obvious when you’re losing the plot, oiaohm: you resort to links from Wikipedia that describe general characteristics but do not support your thesis.

    So then. a link for you that will help you understand Windows drivers in the context of both the driver framework and of DMA.

    Note, on page 12, the description of the Windows DMA Abstraction. I quote:

    The address space on any given device bus is separate from the address space of system memory.

    In other words, no, your device is not allowed to write to arbitrary parts of system memory. The framework mediates the mapping.

    You may be thinking of System DMA, which died out around 2000 and which might indeed have led to the security issues you theorize about.

    Since 2000 or so, all modern hardware on Windows works on bus-mastered DMA and consequently passes through the driver framework. It’s “Direct Memory Access,” but no longer in the sense that you think it is. The end result is (hopefully safely) mapped.

    This isn’t really a hard concept to understand.

    Everything else about your latest post is just guff, but I don’t want to waste space on Robert’s blog by detailing why. Briefly:

    The firmware you load into the gpu can send back instruction to clear all of physical memory if you wished. The x86 chipsets would accept these instructions.

    No it can’t.

    And your favourite link, as far as I can see, is still a reference to fixing up Nouveau.

    That is no bad thing.

    On Linux, you can run a vanilla driver if you want and get VESA performance. (Robert’s choice, I believe.)

    Or you can run a binary blob and trust NVidia (which Dougie is recommending).

    Or you can help develop a FOSS driver like Nouveau, in which case you are going to see the odd hiccough and a few technical problems that need fixing.

    It’s a trade-off. But when you make a trade-off, it helps if you have the faintest grasp of what you are talking about, and do not constantly veer off onto irrelevant tangents.

  14. oiaohm says:

    Dr Loser
    –No, it’s not a new issue. Again, afaik, it was fixed on Windows when Vista came out. You cannot do this any more. It is not possible (on Windows).–
    In fact its not fixed in Vista. The issue is firmware side. Its the way PCI bus and prior were designed.

    DMA exploits are possible for the same reason.

    http://en.wikipedia.org/wiki/Memory-mapped_I/O MMIO might pay you to read and take note.

    The Nvidia firmware is able to write anywhere into physical memory.

    http://en.wikipedia.org/wiki/IOMMU
    Note correct secure answer for memory interface from devices. Why is Nvidia not using this its slower.

    Dr Loser there are two ways of talking from devices to physical memory. The old MMIO method is not secure. This is why we had firewire able to dump the complete address space on some systems.

    Yes there is a list of on going issues. Really IOMMU you be disabled from being able to pass threw physical addressing.

    Dr Loser where has Microsoft built all the fences. CPU side. What side am I talking about sending instructions to alter CPU ram. GPU side. The firmware you load into the gpu can send back instruction to clear all of physical memory if you wished. The x86 chipsets would accept these instructions.

    IOMMU in relation to virtualization is also a good read Dr Loser.

    This secuirty bug around DMA is most in face when doing virtualisation.

    Are you going to tell me that I can PCI-e pass threw Nvidia video card to a guest Windows running in Xen or KVM or Hyper-V and not have the computer die. The reality is it will die because Nvidia card will attempt to alter Physical memory that does not line up. The guest fake physical memory addresses will be used to dump data into real physical memory address so killing the hyper-visor at some point. How to escape hyper-visor 101.

    Dr Loser it is in fact very simple to demonstrate since virtual machines have allowed passing through of full video cards.

    Mind you ATI/AMD based cards work fine. One of the reason why ATI/AMD graphics cards has been slower than nvidia is their usage of iommu to get data to and from the video card.

    Basically Dr Loser if it was fixed in Windows we would be able to run Windows in Hyper-v, Xen and KVM with normal Nvidia accelerated drivers. Yes video card would have to be decanted to guest.

    Microsoft has not be able to refuse Nvidia certification for this problem. Mostly because Microsoft does not get to read the firmware and go hey you should not be doing this stuff.

    Dr Loser how Linux users came aware of this problem was domain 0 on Xen. Physical address information in kernel space is slightly off. Nvidia binary blobs has not worked in these environments since day dot.

    Something that is highly fun Dr Loser is that from a device you can clear no execute flags. There are some major X86 bus design problems.

  15. Dr Loser says:

    As an addendum, oiaohm, I don’t really wish to torture that fine Faberge egg of a brain you have, but I’m compelled to point out one more salient fact.

    It’s on slide 1. Here it is:

    Using process address space on the GPU

    It’s a (potential) attack on directly-mapped memory on the GPU. It has nothing to do either with the Linux kernel or with a putative Windows kernel.

    Now, obviously, you could theoretically use this as an attack vector. But what do you do next?

    Both the Windows kernel and the Linux kernel have fences between the CPU memory and the GPU memory.

    You do realise that NVidia cards have their own RAM, don’t you? Quite a lot of it, in fact. So, for your next question: how do you map the intrusion from GPU ram to CPU ram? (And I’m going to insist that the CPU ram is at kernel level.)

    This is going to be fascinating.

  16. Dr Loser says:

    There has been a historic problem of video cards doing their own memory management independent to OS and not using hardware assistance. Dr Loser this is not a new issue.

    No, it’s not a new issue. Again, afaik, it was fixed on Windows when Vista came out. You cannot do this any more. It is not possible (on Windows).

    Linux, however? Apparently Linux has yet to advance beyond Windows XP, or even 98, in this regard.

    To repeat the link that you, yourself, insist on repeating:

    While I’m personally one of the guys who wouldn’t like to see a binary
    blob in nouveau, no matter the terms, I’ve read the firmware blobs
    decompilation and I’m quite concerned about possible security implications.

    It was decompiled on Linux.

    I’m all for FOSS getting this fixed via the Nouveau driver. I think that’s an excellent idea.

    Hi yo, oiaohm! Your next rainy Wednesday afternoon project!

  17. Dr Loser says:

    Always worth reading the substance of the links, oiaohm. In this case, you have presented us with a PDF slide presentation from M Glisse on how NVidia and RedHat are working together to correct security flaws in Nouveau.

    Or did you not realise that? Google harder, my man.

    There seems to be some sort of problem with vec_add(), whatever that might be. Specifically, your link suggests that it is something to do with its application to X, rather than with Windows.

    OK, so it’s not obviously a M$ problem.

    Is it a problem with X and a NVidia binary blob? Who knows? That’s the beauty of a binary blob!

    Of course, if M Glisse were employed by NVidia, he might be able to tell you. But he’s not. He’s employed by RedHat.

    This leads me to suspect, and I am open to correction, that your link is specifically talking about a security hole in the Nouveau driver when applied via X on a Linux system to the irregular manipulation of direct physical memory. Which, btw, you cannot do under any circumstances on a Windows machine, afaik.

    Dr Loser the big problem here is there is no talk from Microsoft how they are going to address the device attacking OS at all.

    oiaohm the big problem here is that you wouldn’t recognise a clue-bat if it hit you. Microsoft (in this case at least) has no reason to waste their time with your paranoia.

    Maybe there’s a security issue on M$. Maybe there’s even a security issue on Linux via the binary blob (kindly linked to by Dougie, that stalwart Defender of the Faith). But you couldn’t prove it by the links you’ve supplied.

    Looks like a security hole in Nouveau to me.

    I even downloaded the 3.9.11 kernel (courtesy of the Nouveau website, which is not particularly well set up for “examine, modify, mock, ignore” activities, unfortunately). I’ve yet to track down the code on slide 3.

    And slide 7? It’s talking about virtualisation. In what way is this relevant?

  18. oiaohm says:

    Dr Loser the functions that is defective is Nvidia GPU_alloc and GPU_upload and the download back to normal memory as well.

    This change deletes the usage of these functions completely.

    There has been a historic problem of video cards doing their own memory management independent to OS and not using hardware assistance. Dr Loser this is not a new issue.

    Really we are lucky that attackers have been taking other targets for this long.

  19. oiaohm says:

    Dr Loser http://www.x.org/wiki/Events/XDC2013/XDC2013JeromeGlisseUsingProcessAddressSpaceGPU/xdc2013-glisse.pdf

    The PDF here relates to a very particular security problem.

    The biggest splats with the Nvidia driver relate to page 7. pcie passthrew to and have a guess OS running a current Nvidia driver and watch how long until complete OS dies. This being the fix does not mean Nvidia guys have to yell from roof they are busted.

    Dr Loser
    http://lists.freedesktop.org/archives/nouveau/2013-September/014497.html
    These finger Nvidia binary drivers firmware as problem.

    Even that Nvidia binary blobs are closed the nouveau team had decompiled them. Dr Loser PGRAPH context issue has been mentioned for years.
    PGRAPH is the firmware blob shorted name for what the PDF is addressing.

    PGRAPH in current nvidia drivers depend on pinning memory and using a physical address to write to that memory.

    Yes the PDF will see a new PGRAPH function in Nvidia firmware for Linux.

    This is the problem Dr Loser. Nvidia are faulty. The nouveau developers extract firmware from Windows and Linux and Freebsd and the OS X drivers.

    Dr Loser the big problem here is there is no talk from Microsoft how they are going to address the device attacking OS at all.

  20. Dr Loser says:

    There may or may not be security issues with NVidia drivers on Windows, oiaohm.

    Unfortunately, your link:
    a) is sourced from Phoronix, who are not especially well-known in the domain
    b) doesn’t talk about Windows drivers at all
    c) does not refer to current proprietary binary drivers
    d) doesn’t mention any specific security hole; in fact, doesn’t even venture very far into the topic at all
    e) doesn’t even finger NVidia drivers as a culprit, which is hardly surprising since Jerome Gliss is an NVidia employee.

    One has to wonder what strange compulsion caused you to forward this link. It’s interesting, but of zero relevance. After that, your post went downhill a bit.

    Once again: Robert is right. “Keep It Simple, Stupid” is an excellent way to avoid getting into trouble. The only question here is whether you take Dougie’s approach, which involves recommending the use of non-FLOSS binary blob drivers (Dougie is as yet unrepentant of this sin), or you go for a FLOSS driver that does what you need.

    I recommend that you keep it simple, oiaohm.

  21. oiaohm says:

    Dr Loser there are a lot of device to physical memory attacks turning up.
    http://www.phoronix.com/scan.php?page=news_item&px=MTQ3MTY

    Yes there is work under way between Nvidia and Redhat to close the flaw.

    Dr Loser also read the quote again. Its not hard to see how to exploit the video decoding in the default Nvidia firmware since accepts direct physical address methods from userspace. Only protection is every program using the Nvidia video acceleration is using the Nvidia interface library. Yes the attack is not straight forwards.

    Nvidia firmware is not the only 1 with this kind of issue Dr Loser. Yes a complete new framework is required to address the problem.

    Yes Dr Loser the memory manager of every OS out there needs to be reworked to avoid these nasties.

    There has been a critical disconnect between CPU address space controls and device accessing address space.

    http://en.wikipedia.org/wiki/DMA_attack

    Yes some of what is required to fix some these driver faults also is new hardware Dr Loser.

    Really what are you saying Dr Loser that we have to wait for systems to be hacked before addressing. A security exploit is still a security exploit even if no attacks are in the wild yet.

    Sorry Dr Loser Nvidia firmware images are extracted from Nvidia blobs. Yes response now that Nvidia is taking is the joint operation between Nvidia and Redhat to close it forever.

    Dr Loser the problem I have is I have heard nothing from Microsoft or OS X about new memory management framework. Only way to seal lots of these hardware device attacks is for OS to take more control over data from device to memory.

    Yes lot of OS’s are at core still design for a world without DMA so its more good luck than good management that we don’t have more breaches from devices.

    Yes Dr Loser this is in fact very serous. All the effort to secure the boot process and securing devices properly was missed.

  22. Kevin Lynch says:

    Until the FOSS driver for Nvidia devices works properly. Binaries are the only option if you want a stable system. The FOSS driver has never worked properly on any of my machines. It causes Linux to crash.

  23. bw wrote, ” As a matter of fact, anything that Linux cannot do is just frills.”

    Silly. GNU/Linux does 3D all the time. As I recall, 3D desktops emerged in GNU/Linux long before that other OS had them:
    Vista had it in January 2007 but GNU/Linux had it in January 2005. It’s sad when $billions “invested” in software cannot beat “a bunch of amateurs working in their basements”.

    I tried it once or twice and stayed with 2D. If I can see it I know what to click upon. If it’s out back, I can’t, and I certainly can’t deal with an infinite number of combinations of gestures.

  24. Dr Loser says:

    To Robert: I’m actually agreeing with you. I think Dougie is doing the cause a disservice by promoting binaries. Which is what he explicitly did. Nouveau is perfectly in line with the FOSS manifesto, and I think they’re doing the right thing.

    I’ve a few technical doubts about why you would want to rewrite the driver for an NVidia card, rather than just using a) on-board video or b) a VESA driver, but those can wait. I can trust you to follow this story, and it’s certainly an interesting one.

    To oiaohm: I think you may have misrepresented your link. Here’s the nub of it:

    The PGRAPH context switch microcode allows user to read/write arbitrary MMIO registers by submitting the firmware methods. The GF100+ video decoding etc. falcon microcodes allow you to just ask for physical instead of virtual addressing, and that includes physical system memory. Why did nVidia include such obviously security-breaking functionality in the firmware images?

    This isn’t actually a warning against the security implications of using the original binary blob. (I hesitate to say there are none, although none have been reported.) The original binary blob Is self-contained and, one would hope, properly tested.

    This is actually a warning against a simple-minded decompilation/reverse-engineering of the blob, followed by what look like perfectly sensible and justifiable rewrites.

    In other words, Here Be Dragons! Play at your peril!

    But then, as an experienced RTOS engineer, oiaohm, you don’t need me to explain this trivial stuff to you, do you?

  25. bw says:

    3D is just frills

    Definitely. As a matter of fact, anything that Linux cannot do is just frills.

  26. oiaohm says:

    Dr Loser there is a major problem with the Closed source Nvidia firmware binary.
    http://lists.freedesktop.org/archives/nouveau/2013-September/014497.html

    It is in fact a universal way to hack a OS. The open source firmware blob is intentionally does not implement this.

    So yes Dr Loser installing the Nvidia binary blob is downgrading your OS security this does not matter if it Linux or Windows or any other OS. So this is currently a horible choice between performance/Stability and Security.

    WIndows uses the same binary firmware blobs as Linux in the Nvidia cards. Nouveau have script to rip the firmware blobs out of the closed source drivers also has been decompiling the Nvidia firmware blobs. Including recently developing a specialist de-complier tool.

    So you have 3 running patterns.
    Open Source Nouveau with Open Source Firmware that is secure but not stable.
    Open Source Nouveau with Nvidia closed firmware. Not secure and not stable.
    Nvidia user-space driver with Nvidia Firmware. Not secure but mostly stable.

    Dr Loser now that dialogue is open with Nvidia maybe the side channel attack hiding in Nvidia video cards can be closed.

    Robert Pogson yes this Nvidia one is really a great example why closed source code in drivers is a really bad idea from a Security point of view.

  27. Dr Loser wrote, “This driver is required to fully utilise the 3d Potential of NVIDIA graphics cards, as well as provide 2D acceleration of newer cards.”

    Last time I checked, screens were 2D and on a desktop, 3D is just frills. Certainly Unity does not require 3D to work. That’s why I’ve never had much trouble with Nvidia’s graphics… We have one system here with an Nvidia driver and it’s a pain because a new driver has to be built for each update of the kernel, not because it’s physically necessary but because Nvidia requires it… I quit updating that kernel. If Nvidia gets the right details into FLOSS drivers the world will be a better place. How long has it taken them? A decade or more? Linus was right to give them rude feedback.

  28. Dr Loser says:

    I love it when you get red in the face, Dougie. So then. Let’s proceed to the next paragraph in your link. You may not have read it.

    This driver is required to fully utilise the 3d Potential of NVIDIA graphics cards, as well as provide 2D acceleration of newer cards.

    So it goes.

    What you are basically proposing is that the people of FLOSS should actually download and activate a non-FOSS proprietary binary; as opposed to building, testing, verifying, and uploading the fixes for the actual FLOSS project you belatedly mentioned (ie Nouveau).

    I believe you owe the Big Man an apology for this, no doubt, temporary boggle.

    Robert makes sense. You don’t.

  29. dougman says:

    *Rolls Eyes* Nice try troll.

    Trying to argue over the semantics, and have you distract from the topic.

    Get back under thy bridge!

  30. Dr Loser says:

    What a loveable little rascal you are, Dougie.

    Check yer link.

    To quote:

    Licence: Proprietary

    3D-accelerated proprietary graphics driver for NVIDIA cards. Required if you want to run Unity.

    What part of that do YOU not understand?

  31. dougman says:

    Duh. I never said they were Loser. What part of proprietary do YOU not understand.

    if you want a FOSS video driver for Nvidia, one simply needs to install the nouveau driver.
    http://nouveau.freedesktop.org/wiki/

  32. Dr Loser says:

    Ah, Dougie …

    You are aware of the fact that “binaries” are not actually “FOSS,” aren’t you?

    Get with the Big Man on this!

  33. dougman says:

    Yes, by warming up to Linux perhaps they will not have to endure future failings.

    http://www.theverge.com/2013/8/9/4604798/nvidia-earnings-hit-by-windows-rt-failure

    Installing the binaries are simple. In Linux Mint you click on ‘Additional Drivers’ then select which one you want.

    https://dl.dropboxusercontent.com/u/12600821/Screenshot%20from%202013-09-27%2010%3A48%3A04.png

  34. ram says:

    This is a very positive development. NVidia not only noticed that open source Android devices are most of their consumer business, but also that their CUDA cards are heavily used in Linux high performance computers and workstations — far more than in consumer “gaming” machines.

    The movement of many game companies to Linux removes even that market from proprietary platforms.

Leave a Reply