Qualcomm's Open Kernel Driver Leads To A Dirty Mess
Phoronix: Qualcomm's Open Kernel Driver Leads To A Dirty Mess
Well, it sounded nice when Qualcomm announced an open-source 2D/3D kernel driver for their Snapdragon platform that's used by phones like the Nexus One and Dell Streak, but it turns out that their user-space Linux driver that hooks into this kernel driver is currently a closed-source blob. This has led to the eternal debate about open-source kernel components but with only closed-source components...
as intel in the past opensource-code of the GPU-driver but no spec
means if they do not support the driver by an internal NDA feedet team the driver goes useless in the future.
best exampel is my mom's 2ghz P4 igp G845 ubuntu 10.04 and 10.10 fails complete on this hardware because of the closed-NDA-intel-Development.
without hardware specs you don't have a hardware....
yes intel release specs after amd does but intel do not break the ICE amd does it!
same problem by via/s3 dev a kernel drm for an cloused source driver FAIL and to late for the spec just to 'late'
amd do have some misunderstandings to in the past to.
they wana save HDCP copy-protection in the UVD unit but they need 2007-2010-6 3,5 Years of time to check out that the reverence card of the R600 opensource driver the hd2900 do not have a UVD unit at all!!!!!!(you can read this amd-fail at bridgmans forum log and i save him from that mistake (i save the opensource driver))
and now o wow!... they wana dev a shader based opensource acceleration because they unterstand now there is no UVD unit to save in the R600 reverence hd2900 hardware LOL! 3,5 Years to 'late'
there are so many ways of misunderstanding the beauty of open-source-drivers
I was actually wondering how a command executed by the GPU could possibly modify a file on a FS, but that might just be me...
I'm pretty sure Dave was being facetious in that particular spot (using that as an absurd example of sacrificing a core goal like security/reliability). As he alludes to later in the message, though, an insecure GPU driver could potentially be used to read/write arbitrary RAM with DMA operations, which means that an attacker could modify/replace privileged code. The DRM driver might inspect these operations and reject ones that go out of the appropriate bounds, but again it might be hard to know whether that's happening (or happening correctly) if they're trying to keep the GPU programming details a secret.