On Mon, Jul 18, 2022 at 05:21:44PM +1000, Dave Airlie wrote:
> From: Dave Airlie <airlied@xxxxxxxxxx>
>
> A recent snafu where Intel ignored upstream feedback on a firmware
> change, led to a late rc6 fix being required. In order to avoid this
> in the future we should document some expectations around
> linux-firmware.
>
> I was originally going to write this for drm, but it seems quite generic
> advice.
>
> I'm cc'ing this quite widely to reach subsystems which use fw a lot.
>
> Signed-off-by: Dave Airlie <airlied@xxxxxxxxxx>
Document well deserved to be written, thanks for making this happen.
Modulo all the silly spelling / bike-shedding issues folks might find,
in case you care to re-spin for a v2:
Acked-by: Luis Chamberlain <mcgrof@xxxxxxxxxx>
Now let's think about the impact of two corner cases which *do*
happen and so this poses security implications on enablement:
1) Devices which end up with a security issue which a vendor considers
obsolete, and the only way to fix something is firmware. We're
security-out-of-luck. For this I've previously sucessfully have put
effort into organizations to open source the firmware. We were
successful more than once:
* https://github.com/qca/open-ath9k-htc-firmware
* https://github.com/qca/ath6kl-firmware
When these efforts fall short we have a slew of reverse engineering
efforts which fortunately also have been sucessfull.
2) Vendor goes belly up
Both implicate the need to help persuade early on a strategy for open
source firmware, and I don't want to hear anyone tell me it is not
possible.
When that fails we can either reverse engineer and worst case, I am not
sure if we have a process for annotations or should. Perhaps a kconfig
symbol which drivers with buggy firmware can depend on, and only if you
enable that kconfig symbol would these drivers be available to be
enabled?
Are we aware of such device drivers? They must exist...
Luis
