*countable infinities only

Gregory Maxwell gmaxwell at gmail.com
Thu May 31 16:22:14 UTC 2012


On Thu, May 31, 2012 at 12:11 PM, Gerry Reno <greno at verizon.net> wrote:
> This is a monopolistic attack disguised as a security effort.
> The highly restrictive technological approach that has been taken needs to be challenged in the courts.
> I'd rather see Microsoft users have to attach a dongle to their system to get the "security" that they need.

My understanding is that some of the relevant legal minds believe that
Microsoft's "you can disable it" concession forecloses the possibility
of a successful legal attack on this— the law may care about the
anti-competativeness of this stuff, but not so much as to care about a
$99 signing key or some minor install time hurdle. (and the fact that
fedora is willing to plan this probably justifies this position).

It was arguably a strategic error to blow the whistle in advance and
give Microsoft time to compromise. Their first attempt was much more
likely to have created a civil cause of action as well as to have run
afoul on antitrust grounds.   But I can hardly blame anyone for
trying.  Hindsight 20/20 and all that.

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).  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.

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.

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.


On Thu, May 31, 2012 at 12:20 PM, Basil Mohamed Gohar
<basilgohar at librevideo.org> wrote:
> Ah, yes, but then you also won't be able to run Fedora, under the
> currently proposed solution.  Oops!  See how slick the slope is?

They could if they replace the key while removing the MSFT one, or
disable secure boot at the same time.


More information about the devel mailing list