Date: Mon, 8 Jul 2013 21:00:51 -0400 From: Mike Jeays <mike.jeays@rogers.com> To: freebsd-questions@freebsd.org Cc: Polytropon <freebsd@edvax.de> Subject: Re: UEFI Secure Boot Message-ID: <20130708210051.1edc028e@europa> In-Reply-To: <20130709023140.9c7c4f40.freebsd@edvax.de> References: <loom.20130708T182036-992@post.gmane.org> <20130709023140.9c7c4f40.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Jul 2013 02:31:40 +0200 Polytropon <freebsd@edvax.de> wrote: > On Mon, 8 Jul 2013 16:21:28 +0000 (UTC), jb wrote: > > I hope FreeBSD (and other OSs) luminaries, devs and users will find a way not > > to harm themselves. > > A massive problem I (personally) have is that with Restricted Boot > (this is what "Secure Boot" basically is) you are no longer able > to _ignore_ MICROS~1 and their products. A restrictive boot loader > mechanism that requires signed and confirmed keys, handled by a > major offender of free decisions and a healthy market - no thanks. > What prevents MICROS~1 from revoking keys of a possible competitor? > Or from messing with the specs just that things start breaking? > > Don't get me wrong: I don't even argument that a mechanism where > a competitor requires you to pay money to run _your_ software > instead of _their_ software sounds horribly wrong. This approach > will introduce a philosophical or even legal context to the > technical problem. > > I see interesting chances in UEFI per se. It can be called a kind > of "micro-OS" which can be rich on features that could also be > useful. But history has shown that if such an infrastructure is > provided, it will lead to bloated, insecure and incompatible > implementations quickly, and the worst, it will happen at a very > low level. This is simly dangerous. > > Regarding UEFI + Restricted Boot: To obtain MICROS~1's sticker of > approval for hardware, vendors need to implement those features. > Even worse, on _specific_ platforms, they are not allowed to make > it possible to _remove_ those features, so "on by default" is > required - if I remember correctly (Intel vs. ARM architectures). > > As you see, I try to ignore this whole topic as I am not interested > in using it. In the past, this has been possible. When building a > new system, buying a blank disk and _no_ "Windows" was particularly > easy. For systems that already came with some "Windows" preinstalled, > simply deleting the partition was a solution; install FreeBSD boot > mechanism, initialize disk, and be done. No more dealing with what > MICROS~1 seems to insist is "normal". When _their_ product decisions > make _me_ invest time to find a way to remove and ignore them, I > feel offended. > > I would like to see a way UEFI hardware, with or without Restricted > Boot, can be used with FreeBSD _without_ involving the "good will" > of MICROS~1. But as they have already gotten their fingers everywhere, > this doesn't seem to happen all too soon... :-( > > > > > -- > Polytropon > Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" If I have understood correctly, it is quite easy to disable secure boot on most current machines; it is just an option in the UEFI setup. The real danger is machines where it cannot be disabled. This includes some recent HP machines; whether by design or incompetence I cannot say. These are the real danger to non-Microsoft operating systems, and the free software movement needs to fight tooth and nail against them. I can all too easily see them proliferating in the marketplace, perhaps secretly 'encouraged' by Microsoft.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130708210051.1edc028e>