Date: Mon, 8 Jul 2013 21:54:49 -0400 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: Polytropon <freebsd@edvax.de> Cc: jb <jb.1234abcd@gmail.com>, FreeBSD Questions Mailing List <freebsd-questions@freebsd.org> Subject: Re: UEFI Secure Boot Message-ID: <CAOgwaMuY_650rz5tfsWB%2BnYHJXQPXazWW4kiZJVS8dzuiOdx0g@mail.gmail.com> 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 Mon, Jul 8, 2013 at 8:31 PM, 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, ... > To assume that UEFI with some magic numbers is a security provider with current hardware is only a day dream . Consider stolen security signing keys and other by-passing mechanisms . For me , I think , over time there will exist free , but really free operating systems which they are not enslaved themselves to some companies , and hardware ( mainly main boards ) which will not require such enslaving . Then , to do task is just plainly to switch to such hardware and software . Personally , I will never want to live under a restriction tried to be enforced by a company and blindly accepted by its followers . I think I am not the only one in the world . Thank you very much . Mehmet Erol Sanliturk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMuY_650rz5tfsWB%2BnYHJXQPXazWW4kiZJVS8dzuiOdx0g>