*countable infinities only
mitr at volny.cz
Thu May 31 16:42:47 UTC 2012
On Thu, May 31, 2012 at 6:22 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Thu, May 31, 2012 at 12:11 PM, Gerry Reno <greno at verizon.net> wrote:
> On Thu, May 31, 2012 at 12:13 PM, Miloslav Trmač <mitr at 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
> 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
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.
More information about the devel