On Sat, Aug 29, 2015 at 01:29:16PM +0200, Paul Wise wrote: > On Sat, Aug 29, 2015 at 9:48 AM, Philipp Kern wrote: > > freeness are distinct for the CPU and auxiliary PUs. > I get the feeling that the practical consequences of non-free software > running on auxiliary PUs can be worse than CPUs: > > May include signature checks to prevent new code from running. For > CPUs we usually have ways to disable those checks. We do not have a way to disable the firmware signature check on the Intel microcode. > Reverse engineering is harder due to custom/unknown ISAs and lack of > free infrastructure surrounding the proprietary code. > > For preinstalled code it is much more likely that one cannot do > updates nor find out how to update it. Obviously not an issue for > upload-on-boot firmware. Correct. And our view of the world does not allow to ship fixes to the firmware to users by default. I disagree that the latter is "obviously not an issue", because you really want microcode updates for CPUs to guard yourself against security vulnerabilities (see e.g. the TSX on Intel mess). > Unknown amounts of storage for persistant malware to live in after > exploiting the firmware. > Harder to detect or restrict misbehaviour when it happens. Verifiability is an orthogonal concern. I agree it's a valid one. But take this case: Someone plants new firmware in the device, knowing that the system will never supply its own firmware. So the argument goes, again, both ways. Kind regards Philipp Kern
Attachment:
signature.asc
Description: Digital signature