7 ms·
New Generation of Intel Graphics for Linux Requires Proprietary Firmware
- vbezhenar 11y agoRecently there was a good discussion about difference between firmware and software/drivers: https://news.ycombinator.com/item?id=9671025 https://news.ycombinator.com/item?id=9671025 Proprietary firmware is not a good thing, but it's not a very bad thing until we have open hardware, in my opinion.
- jcreedon 11y agoThis is not to mention that even if it were open source, it is not likely that the tool chain used to create it is even available, let alone open source. Firmware blobs are just a fact of life, for now at least.
- digi_owl 11y agoAnd i don't think it will become less common. You can get a product out the door much faster if it use a off the shelf microcontroller and a EEPROM than a custom IC.
- thristian 11y agoIntel has licensed GPU designs from third-parties before, but typically only for their low-power (Atom) chips where they just didn't have the technology in-house. Here, we're talking about a new micro-architecture for Intel's premium product line; I would be very surprised to hear Intel licensed anything in the design from third-parties. If Intel wanted their tool-chain to be available, they could make it so.
- bjwbell 11y agoFrom somewhat old first hand knowledge. The GuC isn't that complicated of a toolchain, mostly linux based. The GuC itself is basically a pentium processor running a very simple OS.
- thristian 11y agoI think this is news because we had open hardware (or at least, we had fully-documented GPUs that did not require firmware blobs), and with Skylake we will not.
- pavanky 11y agoHow do you know that the previous generations of GPUs did not have on board firmware ?
- wtallis 11y agoIf they did, it wasn't the operating system's problem and was handled by and stored alongside the motherboard firmware.
- thristian 11y agoAlmost surely it did, since software is eating the world. However, the question I care about is "does the original manufacturer have more power over the physical device I paid for than I do". If my Ivy Bridge GPU has on-board firmware, that I can't change, well, Intel probably can't change it either. Or if they can, they haven't documented it and so the kernel driver doesn't provide the facility and so effectively they can't, short of NSA-type hackery, an answer I am happy enough to truncate to "no". However, for Skylake the answer to "Does the original developer have more power over the device I paid for than I do" is "very obviously yes" and no amount of handwaving or approximation will suffice.
- igravious 11y agoIt boils down to the ol' pragmatical versus ethical debate again. a) Pragmatism dictates that in order to use the `new shiny' we use non-free firmware. b) Ethical concerns dictate that no amount of `new shiny' is tempting enough to compromise our ideals. I guess there are points in between and maybe these are poles in the debate with yer Stallman-types tending towards (b) and yer Torvalds-types tending towards (a). I'd like a world without scary binary blobs and the Stallman in me chides me on my bad decision-making and lack of character. On the other hand, ooh look at the new shiny.
- dmitrygr 11y agoI am willing to tolerate custom firmware in hardware that lives behind an IOMMU and under an OS that uses it. That will at least make it unlikely that something scary lives in there and collects my data. Without an IOMMU in use, the entire RAM is fair game, and, with some creativity, the network card buffers to sneak the data out.
- the8472 11y agoAs I understand it the SMM has full access to physical memory and contains proprietary firmware
- deleted 11y ago[deleted]
- zerohp 11y agoX86 system management mode is not something you can turn off. It is there to protect motherboard firmware code that runs on the CPU. That code does things like emulate PS/2 mouse and keyboard. See chapter 34 in [1]. SMM is not for enterprise sysadmins. They use other hardware and software for systems management. [1] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf http://www.intel.com/content/dam/www/public/us/en/documents/...
- leereeves 11y ago> The future is manufacturers—of devices ranging from phones, to laptops, to cars—being the centralized ops staff for all the devices they make. That's open to so many forms of abuse. Extra-judicial punishment by government agencies and companies, hackers wiping your devices for the lulz, disgruntled employees, ex-spouses...
- igravious 11y agoI've never understood this. Isn't it always possible to detect unsanctioned network traffic. Sure, most people don't. But all it takes is one person to spot an errant packet and a malicious actor's cover is blown. What purpose could possibly be served by putting code into firmware that gives itself away by generating network traffic. Hacking firmware is another matter. But a vendor distributing malicious firmware code that generates network traffic? Not wittingly, it doesn't make sense. Of course if it's for some sensitive piece of machinery and the vendor has been compromised. But then if you're buying sensitive parts maybe you should be extra-cautious to ensure they operate as intended. But consumer hardware? I'm not seeing it. Call me naive or not tin-foil-hatty enough :)
- bjwbell 11y agoCould they have open sourced it? Yes. But it was never likely since firmware is almost always done as a binary blob from intel or otherwise. They're actually being more open than most vendors, since skylake isn't even shipped yet.
- lasermike026 11y agoYeah, this isn't going to work.
- snarfy 11y ago> GuC is designed to perform graphics workload scheduling on the various graphics parallel engines. In this scheduling model, host software submits work through one of the 256 graphics doorbells and this invokes the scheduling operation on the appropriate graphics engine. I'm highly suspicious this idea is patent encumbered.
- stephengillie 11y agoBut...but...but... They're using doorbells instead of schedulers. That's different, right? ;)
- jakobdabo 11y agoRecently there was a discussion [1] in OpenBSD's mailing list and you can also see [2] Theo de Raadt's point of view. [1] https://marc.info/?l=openbsd-misc&m=143354954711286&w=2 https://marc.info/?l=openbsd-misc&m=143354954711286&w=2 [2] https://marc.info/?l=openbsd-misc&m=143355112811564&w=2 https://marc.info/?l=openbsd-misc&m=143355112811564&w=2
- digi_owl 11y agoAs an aside, the part about how ROMs are writeable via manufacturer tricks is what makes "amateur" reverse engineering of drivers a potentially costly affair. You never know when you pop a hidden write trigger, and subsequently fill the ROM of your expensive hardware with garbage. I recall reading about such a incident involving a DVD burner, where the OEM had reused a seldom used signal (stupid on their part, but still) as the trigger for a firmware update...
- 0x0 11y agoSome versions of Linux were bricking some LG CD-ROM drives: http://en.wikipedia.org/wiki/Killer_poke#LG_CD-ROM_drives http://en.wikipedia.org/wiki/Killer_poke#LG_CD-ROM_drives
- duskwuff 11y agoI believe that was Plextor drives, although I can't find a reference. Anyways, smart manufacturers these days put some sort of a signature on the firmware (even just a CRC will do), and don't write updates to flash unless they have a good signature. That makes it much more difficult to accidentally trigger an update.
- anonbanker 11y agoDid this on an nvidia-based laptop using colord. Had to replace the motherboard once colord destroyed the ROM.
- etiam 11y agoI see de Raadt's still delivers his point of view in a hissy fit of insults.
- walterbell 11y agoWill this affect graphics virtualization on Skylake, https://01.org/zh/blogs/skjain/2014/intel%C2%AE-graphics-virtualization-update?langredirect=1 https://01.org/zh/blogs/skjain/2014/intel%C2%AE-graphics-vir...?
- bjwbell 11y agoYes. It most closely corresponds to the GVT-g scenario in the blog post.
- faragon 11y agoWhy previous generations didn't?
- comrade1 11y agoIt's really too bad, but linux has failed as a consumer os. As an example, most of us use laptops and linux power management is horrendous on a laptop with battery life of 50% or less compared to Windows. And their consumer desktop UIs are a joke and the programmers have no interest in improving them in a consistent strategic manner. There is no distinctive driving force with a vision. It's no wonder graphics chips manufacturers don't see it as worth their time to provide source code. I am sure everyone is tired of this argument. But keep hoping - we love you for it. But on the server side it's great. The majority of my servers run some form of Linux. I used to run FreeBSD but have moved Linux.
- betaby 11y agoIs it true? Also some vendors sells Ubuntu / Chromebooks, would they have better battery life if reformatted to Windows ?
- toast0 11y agoYes, a chromebook in windows has much better battery life, the keyboard and trackpad don't work, so it goes to sleep, and uses very little power.
- e12e 11y agoAlso, Android doesn't exist, and doesn't work as a consumer OS? On a more serious note, I can't really understand the claim about a big difference in power-saving between Windows and (GNU/)Linux. It's not been an issue on my (admittedly rather old) devices. One thinkpad t420s (whose battery could use a replacement, due to age) and an ageing netbook.
- krick 11y agoI never have run tests, but have heard about "bad Linux battery time" many times, so I really wonder if it's true. And if it is: is it fixable or is some almost inherent flaw?
- rhinoceraptor 11y ago
- aosmith 11y agoI need a closed source driver on my pci bus as much as I need a bullet in the head.