From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1giwLg-0005l3-5u for mharc-grub-devel@gnu.org; Mon, 14 Jan 2019 02:07:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1giwLd-0005km-9A for grub-devel@gnu.org; Mon, 14 Jan 2019 02:07:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1giwLc-0003ng-5q for grub-devel@gnu.org; Mon, 14 Jan 2019 02:07:49 -0500 Received: from mail-it1-x142.google.com ([2607:f8b0:4864:20::142]:53883) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1giwLb-0003m3-LH for grub-devel@gnu.org; Mon, 14 Jan 2019 02:07:48 -0500 Received: by mail-it1-x142.google.com with SMTP id g85so11583603ita.3 for ; Sun, 13 Jan 2019 23:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=b5nU/iQhZs2W/aQVvEO0QWQ7/9eDtbxi9BTPTT/7qIE=; b=Bo+7z20biPbXoLK/QqjLSZ9KsB80UVd1zWRiTuZEGuzh9v+kA6kUy+7ijOJ0oG4jm9 hWh/cCf2VyKip1gHepIhsvEmRYya71EAhzCyhGxlMtNcD/H8g6nm0KnKUtjxBfAFik3m BOn80IYikzg2c/6gpsHnrK1qJa35m5zzj0fT8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=b5nU/iQhZs2W/aQVvEO0QWQ7/9eDtbxi9BTPTT/7qIE=; b=ER5CvGjNRFRtXefPSi2dmswF89G13fQZAPN3JEaLWqcH0gTHeI9Ds6BCBzvoQLAFIO QeORUUdDY0ugZr9yG3jNPtr1hQ7tz4YBg6rmIy6j5AMSHqmNDIw+f3SjMyQWTNd2TaMH hcszfJUhYofbD+dS/h20Eav/9YvaDIhc2ftzjRqmbU/PznCLHIJmYQ4EuwLzZNrtP7GQ zA6C5c/BSHjoAOoRSTWQdOMAqhkfSS8uJsfjFya6ePChbmD0Ib6noQ8HRkgGXH5GQeHM l8OdaN9roubkR2ubDvaRAAQ67dXKoUYnUwk0rK530X+C2883VZHhPnSEp+TSKJQK718A 3HNA== X-Gm-Message-State: AJcUukd9TCx5xAG2bRAOSaHb6fi9hi0p3SHAc7GlCtEKL9X+pTjkE/YR Zhuiyqf6src1nTngtl4MJb1uu5/vK+nJ2XJr5rU9pQ== X-Google-Smtp-Source: ALg8bN5/GnyK8/ZhYr+AXIwl/XjY8hKbEKtD93+X/1/P7SzHBuO848quddVTVpNjooud4EZzhKRqjzF5GmCrhwrV7zs= X-Received: by 2002:a02:4c9:: with SMTP id 192mr16445168jab.2.1547449665785; Sun, 13 Jan 2019 23:07:45 -0800 (PST) MIME-Version: 1.0 References: <20190110081208.GA5021@mazu> <1CE00885-C88C-4D0C-B41C-3BBDDB65F716@suse.de> <20190111105854.4byy3hjcft6oeziy@bivouac.eciton.net> <20190114045829.GC5833@mazu> In-Reply-To: <20190114045829.GC5833@mazu> From: Ard Biesheuvel Date: Mon, 14 Jan 2019 08:07:34 +0100 Message-ID: Subject: Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM To: Leif Lindholm , Alexander Graf , grub-devel@gnu.org, Ard Biesheuvel , Peter Jones , Matthew Garrett , Benjamin Brunner Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::142 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 07:07:50 -0000 On Mon, 14 Jan 2019 at 05:58, Michael Chang wrote: > > On Fri, Jan 11, 2019 at 10:58:54AM +0000, Leif Lindholm wrote: > > On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote: > > > > Am 10.01.2019 um 09:12 schrieb Michael Chang : > > > > > > > > Hi, > > > > > > > > With the advent of new verifier framework and shim lock protocol support > > > > to the grub's community, we are driving to the world of UEFI Secure > > > > Boot, well, almost .. > > > > > > > > There is a missing piece in the puzzle remaining, that is booting linux > > > > kernel via it's own EFI Handover Protocol's entry. Strictly speaking, > > > > the interface is not part of the UEFI Secure Boot, but we have to use it > > > > to avoid problem of using UEFI LoadImage Protocol, which will not work > > > > with shim and it's Machine Owner Key (MOK) as they are not part of > > > > firmware's KEK and db. > > > > > > So really dumb question here: What if we didn't use the MS key? What > > > if instead, we just provide a SUSE/openSUSE key and give customers > > > the ability to sign their own grub+Linux binaries? > > > > > > Then we would only need to lobby with platform vendors to include > > > our public key in the delivered Keystore in parallel and everything > > > would "just work". > > > > > > The only reason shim needs to provide its own key management is that > > > on most x86 systems, we (and customers) don't have control over the > > > keystore, right? We can just push to not have that problem on ARM. > > > > Sure. That's a valid (and I think Ard would say preferable) decision, > > and should "just work" with upstream GRUB. But that's for each distro > > to decide. > > It will work as far as it goes. I think part of the reason shim was used > is that early x86 UEFI Secure Boot shipped without function to disable > it and also no way to enter setup mode. It is then become some sort of > vendor lock-in and has legal concern to the open source software like > grub if it gets signed to prevent from freely distributed. If ARM > provides setup mode and user has the freedom to manipulate on the > firmware stores then I think shim may not be necessary. > > > > Am I missing anything? > > As time goes by shim has also evolved to do the work than it was > expected originally. Here listed some of related features to consider > when we get rid of shim or the MOK key store it manages. I don't know > ARM folks consider these real issue or not, just for information. > > 1. Key revocation: To revoke a key in db would require the authenticate > varaible support in linux, I didn't know its status much yet. And also > it means each distro requires to work with vendor to get its variable > signed, compared with shim that each disto could revoke their key > indendently it brings way more complex and overhead in the process. > If the distro's key is in KEK, the distro can sign revocation updates directly. > 2. Some distribution may be using kernel module signing which chains to > the MOK store as it is easier to updat from the OS. > Pardon my ignorance, but I thought MOK keys were only updatable at boot time? So why is it easier to update a MOK key than it is to update db directly? > 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. > > > > 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.