From owner-freebsd-questions@FreeBSD.ORG Tue Jul 9 00:39:56 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BBC139F9 for ; Tue, 9 Jul 2013 00:39:56 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8E52012C3 for ; Tue, 9 Jul 2013 00:31:42 +0000 (UTC) Received: from r56.edvax.de (port-92-195-76-18.dynamic.qsc.de [92.195.76.18]) by mx01.qsc.de (Postfix) with ESMTP id 1F0C93D2D5; Tue, 9 Jul 2013 02:31:34 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id r690VehM001944; Tue, 9 Jul 2013 02:31:40 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Tue, 9 Jul 2013 02:31:40 +0200 From: Polytropon To: jb Subject: Re: UEFI Secure Boot Message-Id: <20130709023140.9c7c4f40.freebsd@edvax.de> In-Reply-To: References: Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 00:39:56 -0000 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, ...