From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gj4Ff-0001Fp-9B for mharc-grub-devel@gnu.org; Mon, 14 Jan 2019 10:34:11 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gj4FZ-0001CP-Vc for grub-devel@gnu.org; Mon, 14 Jan 2019 10:34:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gj4FZ-0003si-5F for grub-devel@gnu.org; Mon, 14 Jan 2019 10:34:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40648) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gj4FY-0003rz-VO for grub-devel@gnu.org; Mon, 14 Jan 2019 10:34:05 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2365CB2746; Mon, 14 Jan 2019 15:27:38 +0000 (UTC) Received: from redhat.com (dhcp-10-20-1-51.bss.redhat.com [10.20.1.51]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 507D1601A4; Mon, 14 Jan 2019 15:27:37 +0000 (UTC) Date: Mon, 14 Jan 2019 10:27:35 -0500 From: Peter Jones To: Ard Biesheuvel Cc: Leif Lindholm , Alexander Graf , grub-devel@gnu.org, Matthew Garrett , Benjamin Brunner Subject: Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM Message-ID: <20190114152734.a7m4km2opclshnap@redhat.com> References: <20190110081208.GA5021@mazu> <1CE00885-C88C-4D0C-B41C-3BBDDB65F716@suse.de> <20190111105854.4byy3hjcft6oeziy@bivouac.eciton.net> <20190114045829.GC5833@mazu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 14 Jan 2019 15:27:38 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 15:34:10 -0000 On Mon, Jan 14, 2019 at 08:07:34AM +0100, Ard Biesheuvel wrote: > > 3. The Shim's fallback mode has been used to recreate boot entries > > after firmware update for x86, not sure if that any problem for ARM. > > It thought fallback was a separate binary? If the distros sign that, > there is no reason we couldn't load it straight from a Boot#### or > PlatformRecovery#### entry. It is a separate binary, but your deployment method here is way off - the whole point is that it just rebuilds Boot#### entries from the CSV file in your vendor directory. Anyway, it's tiny and only tangentially related to shim - it just happens to be built from the same tree because that's where I happened to put it. > > > As I understand it, there was a concern with the wording in UEFI > > > 2.(3?, 4?) that made it possible to interpret it such that only > > > one key had to be supported. > > > > > > It all comes down to who wants to make sure the key is already in > > > shipped systems.. > > > > Do you think all vendors and distro will have to use common secure > > channel to communicate the key distribution related issues ? > > Define 'secure'. I don't think the distros should be sharing any > secrets with the vendor, but I guess they would have to establish some > kind of trust if the any keys get installed in the factory. > This is similar to how you get your public key hash fused into your > silicon when you order secure parts from a silicon vendor. On x86 land revocations are distributed by UEFI posting them to their website, but obviously that's only workable because we have a common signer. But it's also only *needed* because we have a common root of trust in the signing chain. -- Peter