From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Sb8gQ-0004h9-GC for garchives@archives.gentoo.org; Sun, 03 Jun 2012 11:09:18 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 88AB8E0687; Sun, 3 Jun 2012 11:09:04 +0000 (UTC) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by pigeon.gentoo.org (Postfix) with ESMTP id CFE23E063F for ; Sun, 3 Jun 2012 11:07:17 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8F1EA213D8 for ; Sun, 3 Jun 2012 07:07:17 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 03 Jun 2012 07:07:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=binarywings.net; h=message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type; s=mesmtp; bh=eeADLcdoV3mjbEuYG3d9jSz7 NUU=; b=X+DOR9GjA8xj8AMgI2Q848Ft7FPmfRD+6vKuU2pDBsTBm2yLu071ccDA BBQircJxuvkehGI4y15601OnhJtTgSXLKnATgcknUkMpULzfCQRz5QLnj73qnCG1 554s44Vc8FU6rM3iw5+T86n9OJ3/yj8WbadfP4z9FMGLNsmY28Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type; s=smtpout; bh=eeAD LcdoV3mjbEuYG3d9jSz7NUU=; b=Ulzjzyjh38fWjh56PbZ2OBhsow2afV8oNe0h 4ysZzzdI5EUF83hNlXt21syys/vNzOObX8H0yED6bqyNOgT4cEERPMsCwgMeMaYj PUPapicSjmCqkn+PoqWFFA5CsNkJ/gubRH3uhMGnleAxh66LrdEmPb2LCaxRbCar OdMg8uw= X-Sasl-enc: gbGZdVTtg0ivNCeQ3VxS2Tp/+okA6caU624Pw7CJ8sdZ 1338721637 Received: from [192.168.5.18] (unknown [83.169.5.6]) by mail.messagingengine.com (Postfix) with ESMTPA id 098284837F3 for ; Sun, 3 Jun 2012 07:07:16 -0400 (EDT) Message-ID: <4FCB455F.4040605@binarywings.net> Date: Sun, 03 Jun 2012 13:07:11 +0200 From: Florian Philipp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120505 Thunderbird/10.0.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users' computers References: <1338603963.12172.1.camel@moriah> <4FC9C425.9010301@binarywings.net> <4FCA1159.40909@binarywings.net> <4FCA6EDB.4070908@coolmail.se> <4FCA98D2.7020804@coolmail.se> <20120603065722.GA16751@waltdnes.org> In-Reply-To: <20120603065722.GA16751@waltdnes.org> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDB90B46AAE7201C3DBBB85FB" X-Archives-Salt: 5f51f8cf-395c-4525-a2bb-cb39fb685686 X-Archives-Hash: 757aeefddd7ba58e76c90ab72d9191dc This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDB90B46AAE7201C3DBBB85FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 03.06.2012 08:57, schrieb Walter Dnes: > On Sat, Jun 02, 2012 at 07:36:51PM -0400, Michael Mol wrote >=20 >> The BIOS will only load a signed bootloader. The signed bootloader >> will only load a signed kernel. >=20 > OK, so I sign LILO. What code is in there that prevents LILO from > loading whatever kernel I've compiled? >=20 Nothing. The point is, if you sign software that is used (or can be used) for malware, your key will be blacklisted. That's why Fedora takes the measures I've listed: They don't want to have their key revoked. >> The signed kernel will...do whatever you tell it to do. >=20 > Define "kernel"... no... seriously. > 1) Could it actually be a hypervisor? >=20 > 2) Or maybe another copy of LILO which proceeds to load the actual > kernel? >=20 Sure, whatever floats your boat. UEFI only checks the boot loader directly. After that, it is the boot loader's responsibility to keep the next stage secure. But if you allow unchecked access to the hardware through whatever signed code you have, your key will be blacklisted. To quote Matthew again: > Secure boot is built on the idea that all code that can touch the > hardware directly is trusted, and any untrusted code must go through > the trusted code. This can be circumvented if users can execute > arbitrary code in the kernel. So, we'll be moving to requiring signed > kernel modules and locking down certain aspects of kernel > functionality. The most obvious example is that it won't be possible > to access PCI regions directly from userspace, which means all > graphics cards will need kernel drivers. Userspace modesetting will > be a thing of the past. Again, disabling secure boot will disable > these restrictions. Regards, Florian Philipp --------------enigDB90B46AAE7201C3DBBB85FB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/LRWMACgkQqs4uOUlOuU8bWQCfTQGIQodNcXPf7uZJbKS8JseL 0mMAoIIs/CiQdOhilp1ZregW0gPP6B7h =t1oj -----END PGP SIGNATURE----- --------------enigDB90B46AAE7201C3DBBB85FB--