So solves the MITM, but massive infection is still trivial if someone compromises the webserver.
Sure, but that's true for 99% of things. Unless you establish trust outside of the normal distribution channel how would you protect against this? What is your proposed channel that is not bootstrapped from HTTPS PKI?
I'm happy enough with TLS introduced: knowing the server I'm reaching for updates is actually 'amd.com'. Signatures would be nice, sure, but I wouldn't consider them nearly as critical or useful until now. Before we get too caught up in signatures, however, I'd like to see their new/improved updater actually take precedence.
As things stand, I'm not sure key rotation would go well... the updater doesn't mind itself, apparently.
The basics are straightforward: It'd be better if the current installation contains one (or more) public keys, and anything it downloads must validate as being signed by a corresponding private key. You don't need to do fancy things like global certs, discoverable keys, or revocation lists.
If today's installation doesn't have those checks and relies solely on HTTPS... well, that's unfortunate, but it's not like it poses a tricky dilemma! You simply use today's not-so-secure mechanism to install the new code which has more-secure behavior, and it closes the attacker's window of (easier) opportunity.
The current installation was fetched via HTTPS, right? Either by you or in the factory.
Just saying the "bootstrapping already happened" does not make it not happen. It still needs to bootstrap trust from somewhere
A. You're asking what should be done if the manufacturer's auto-update server has already been completely compromised by hackers and remains compromised.
B. [Implicitly rejected in last coment] You're asking how anybody can guarantee the very first install can be trusted even if someone has compromised drivers.amd.com .
C. You're asking if the auto-update process can somehow trick a compromised daemon into overwriting itself with a legit copy.
Those are all interesting to contemplate, but they are at best "out of scope".
1. Axiom: We trust the current daemon and OS. We must assume this, because otherwise it's an entirely separate problem and this whole discussion of an auto-update channel is irrelevant.
2. Axiom: We trust the owner. Tampering with the local auto-update process is not part of our threat-model, because a user who can do that doesn't need to.
3. The daemon is already coded to trust a replacement/successor installer if it meets certain criteria, which are:
3a. It comes from a trusted domain name it already knows should be owned by the same developer/company.
3b. The remote end is authenticated to "be" that domain via certificates from the (trusted) OS.
3c. The content is protected from tampering due, becauese we trust that TLS/SSL encrypts it.
That all already exists, it does not need to be torn down or rebooted. The proposal here is to simply to harden it with a new requirement in the next version:
3d. The next install must be signed by a trusted key-pair that was shipped with the current install.
This improves trust because it means an attacker would also need to compromise keys held in a release pipeline, which is much easier to secure than a CDN/webserver.
I blocked HTTP connections from my local network years ago and you wouldn't believe how many driver installers and auto-updaters break. One should never trust a HW vendor's (auto-)update implementation.