Re: Summary of the DebConf firmware discussion
On Sun, Aug 30, 2015 at 5:26 PM, Philipp Kern wrote:
> 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.
I was talking about software running on the layer of the CPU above the
microcode (aka Linux and most Debian packages).
>> 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.
It seems I should clarify the second sentence: obviously for
upload-on-boot firmware, we do know the mechanisms for getting code
onto the device I since the Linux kernel uploads it for us and Linux
is usually available in source code form. That often isn't the case
for preinstalled code. For example the WiFi device on the OpenMoko
GTA02 has preinstalled code of a buggy alpha release and the tool used
to update it is Windows-only, proprietary and not released publicly in
any form. If it was released publicly even once in any form there
would be the possibility of reverse engineering.
> 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).
Personally I think giving users choice about firmware updates is
correct. Whether or not to do updates to proprietary preinstalled code
is a trade-off. Choosing updates means the unknown set of issues in
your firmware is always changing. Some folks would prefer to stick
with one unknown set of firmware issues.
>> 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.
That is exactly what I mean.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: