On Thu, May 31, 2012 at 6:22 PM, Gregory Maxwell <gmaxwell(a)gmail.com> wrote:
On Thu, May 31, 2012 at 12:11 PM, Gerry Reno
<greno(a)verizon.net> wrote:
On Thu, May 31, 2012 at 12:13 PM, Miloslav Trmač <mitr(a)volny.cz> wrote:
> That is just untrue. SecureBoot can be used to make sure you only run
> the software you intended to run, which is impossible without
> SecureBoot (e.g. this cannot be done with a TPM). The idea is solid,
I don't think this is fair.
SecureBoot doesn't protect you from someone with access to the
hardware (they can disable secureboot).
BIOS passwords. (Yes, it can be reset on
many machines, but that's a
property of the machine, not of the design.)
And if your kernel is secure
than userspace malware can also not change your boot environment.
If your kernel is _not_ secure then the malware will just modify the
first piece of unsigned userspace code (e.g. systemd) so that it
executes the kernel exploit at startup before updates have a chance to
run, and the kernel rootkit will prevent the updates.
Right, you have to sign or
otherwise authenticate (e.g. dm-verity) a lot.
So unless you take the route of signing everything (with the
according
loss of software freedom, and a lot of runtime overhead) this actually
doesn't buy you a lot.
I can't see that this is a freedom issue. You are
absolutely not
_forced_ to use the system this way. You can use a hardware and
software combination in this more secure way with Secure Boot, and it
is not possible without Secure Boot, but you as the owner of the
hardware are fully in control.
The hardware owner's ability to completely disable Secure Boot
enforcement in the firmware means that he has exactly the same freedom
as when using hardware or software that does not support Secure Boot.
AFAICS, this is, overall, purely a convenience issue - but I may be
missing something.
Microsoft's competitive advantage is that they lose little by
locking
down everything and will potentially get more security as a result.
Fedora's pas competitive advantage was that it provided its users with
the freedom to change the whole system with low friction— something
MSFT's business model can't allow. By playing along we legitimize
their advantages and weaken our own. And in practice, since we won't
accept a full lock down (nor, hopefully would the licenses permit it),
Fedora will mostly not enjoy the security benefit.
Well, Fedora will enjoy a
different security benefit by removing the
user-space ability to manipulate DMA, even for users that don't have
SecureBoot-capable hardware.
If you don't want to "play along", don't buy hardware that defaults to
enforcing SecureBoot. That has probably more potential to change the
situation than Fedora not signing its releases, anyway.
Mirek