AMD Catalyst driver update vulnerability
ceriksen.com
ceriksen.com
I didn't have any of their cards for a decade until I got an old company Dell and hooked it up to the TV. From time to time it forgets that there IS sound coming through the HDMI cable. I googled around. Seems to be a common problem for several versions already. It seemed to have been fixed for some people. Some...
I can't understand how you can allow such things as a big company today.
> Due to a minor security vulnerability in the auto-update notification
Palm, meet face.
Nope, I can't think of any. Oh wait aren't we're actually responding to a post about a vulnerability in the update mechanism, when you say, "not only is it vulnerable, but it should essentially be automatic!" :)
Think of how many errors Windows' aggressive updating causes. And that is from Microsoft. They have ONE JOB! (okay, the OS division has one job).
So if they do all this internal testing and still push things onto your OS that cause problems. What is a third party to do?
The sane thing to do is NOT to treat is as a back door that you can push stuff over, even if the customer asks.
The sane thing to do is to treat it like installing a new application. If the 'new' application has problems, then you stop making it available. You're in control. The customer is in control. It's their pc. It doesn't get broken.
Really, for anything that interacts with the hardware and OS on as low a level as a display driver, there is really no alternative to massive testing beforehand.
Once it's in the wild, you should not expect or have the functionality to simply push firmware or software updates. It should take work and commitment from the customer, the same as installing an application. In the case of firmware, perhaps a bit more.
Deleted comment
1) The customer didn't ask. It's their PC, not yours.
2) "Backwards compatibility." See: https://xkcd.com/1172/
Basically, if you don't leave your program bit-for-bit the same as it was, maybe you break someone's shitty workflow that you could not possibly have predicted and which has no grounding in anything sane.
3) BIG ONE!!! You might have made a mistake. The old version worked fine, for millions of your customers. But you just pushed a version that causes a fairly common setup to have all sorts of problems.
How do you protect against this? Well, for one thing, you can make the update process a bit more involved. Track it better. Keep logs. Nip it in the bud. (Meaning when the first few complaints from early adopters - who jump through the hurdles - trickle in. Not millions at once.) That way you won't accidentally screw your whole entire installed base for NO reason (what they had was working fine) and cause literally millions of dollars of damage (lost productivity as people, some of whom have no access to any IT, simply cannot see their screens anymore).
4) Maybe your installer is not doing what you think it will do. i.e. vulnerability or error in installer. When you mess remotely on a user's PC, this is not to be taken lightly. At all.
This is actually squarely the territory we're in with this article.
So, I find it kind of funny that in an article on an update vulnerability, someone quips that not only that, but it should be WAY more automatic! :)
You can see what bugs were fixed and what features were added and choose to include or not include. At worst you can google and find out how this update affected other users.
I've had machines using FGLRX off and on for years and never realized it had this feature. Guess that's a good thing, though, considering it evidently was never well implemented. It also seems like bad idea as you might lose compatibility between whichever specific driver/kernel pair if you aren't careful.
But I take exception to those who claim the Catalyst install process is horrendous. I think AMD's process of
./<installerName> --buildpkg <distro/version>
followed by:
<package manager install command (for example, dpkg -i)> <generated package name>
and tying in to the DKMS subsystem is much more convenient than Nvidia's approach which directly patches itself into your kernel in a way that would force you to manually reinstall it after every kernel update (unless you were using a distro packaged version, obviously). Maybe they've changed that? (Right now I'm using the distro-packaged driver on my nVidia system.)
While I'm not happy with the current AMD Linux driver mostly because it lacks video decode/render accel as nice as VDPAU, I think most of the other frequent complaints about the driver tend to be a little unfair considering how you can often have obnoxious problems with the nVidia binary as well. With things like HDMI it's been my experience that both drivers tend to have some eccentricities, for example.