From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ghxdT-0005cs-8n for mharc-grub-devel@gnu.org; Fri, 11 Jan 2019 09:18:11 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghxdR-0005cg-1n for grub-devel@gnu.org; Fri, 11 Jan 2019 09:18:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ghxdP-0002t8-4J for grub-devel@gnu.org; Fri, 11 Jan 2019 09:18:08 -0500 Received: from mail-io1-xd43.google.com ([2607:f8b0:4864:20::d43]:39820) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ghxdN-0002rs-3w for grub-devel@gnu.org; Fri, 11 Jan 2019 09:18:05 -0500 Received: by mail-io1-xd43.google.com with SMTP id k7so12268301iob.6 for ; Fri, 11 Jan 2019 06:18:03 -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 :cc; bh=4H/S959DCClMEs9Mvpt8FGKS0W9Kv/XpkwVXw8/Dci4=; b=TJej4XqjAJjXg7mK9VVjaHny1cwsYF4KJ6oEHu2gZRv1Br0oZymPjHsE7kYTMYYYOQ 4IHWuBmiIb7ydUXCZwKTv95/h/fa5fqEVslayitNohL0DXb57JL2A1xo+iSuCmfM0X29 PfTtNYWLRG/sqnMHrCd+EveUaQaHl9k7EbJ0w= 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:cc; bh=4H/S959DCClMEs9Mvpt8FGKS0W9Kv/XpkwVXw8/Dci4=; b=a5IeLbuP9dt3r1QzO+boktSjP8OKXtBCtWu34jDOUPYOw/7MvoBOcfQCFbJ84frC21 9mB6XQcnN/2/VOI4pVHVSZPRVab801r6Mqlq90i1mUCDk1cvHi+nILpwpbUKwYa1+tfi eNL7cgxW/4rlV63TrHRPLDdvMjQMEU8VxcuQZVLZSfp2seY0JJ+937sQW6cJnvF78omk U9CT6ee3ySmUQdLhNZjwNmYcK0vkiA2KlECiGsUZsKS06JJ6YI36y8/QgSWiUgn4tZYE 1NhUi8f9JVg995e9ejGqMUmH0DjdtRGFnauybvdC+9adgPTnHTAOzAb3bhLk1Q0su6+7 +YSQ== X-Gm-Message-State: AJcUukeILJOdsWTaWa13vSXnLwhNRcpeXKeaAykXytBbgmnTxs8eda+f MvWSHQDdm/nR1AxZFr1AKscaeHaayIz+hCEVa/686w== X-Google-Smtp-Source: ALg8bN7eKTTQXIX0kAbSmxEKgsuutfmBRrBD6cAlLOxPf265cqYAiEo8nEle+FBe/7IRjAlQhYblMSqjRhoBY7AUH2k= X-Received: by 2002:a5d:8410:: with SMTP id i16mr9761529ion.173.1547216282278; Fri, 11 Jan 2019 06:18:02 -0800 (PST) MIME-Version: 1.0 References: <20190110081208.GA5021@mazu> <1CE00885-C88C-4D0C-B41C-3BBDDB65F716@suse.de> <20190111105854.4byy3hjcft6oeziy@bivouac.eciton.net> In-Reply-To: <20190111105854.4byy3hjcft6oeziy@bivouac.eciton.net> From: Ard Biesheuvel Date: Fri, 11 Jan 2019 15:17:54 +0100 Message-ID: Subject: Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM To: Leif Lindholm Cc: Alexander Graf , Michael Chang , grub-devel@gnu.org, 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::d43 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: Fri, 11 Jan 2019 14:18:10 -0000 On Fri, 11 Jan 2019 at 11:58, 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. I don't understand what this means. > 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. > > The 'problem' of using the UEFI LoadImage protocol is the whole point of secure boot. Shim and GRUB essentially bypasses UEFI secure boot entirely, but in a controlled way. > > 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. > > > Am I missing anything? > > 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.. > I will repeat the same thing I have been saying since 2013: carrying over Shim to other architectures is a mistake. We could have a simple and clean secure boot architecture on arm64, where the firmware authenticates GRUB, and GRUB calls LoadImage() which authenticates the kernel against the firmware keys. All we need for that is to ensure that the distros get their act together, and work with the industry to get Redhat, Canonical and Suse keys into the KEK and/or db databases by default. Instead, we are having this discussion again, how we can circumvent authentication checks so that GRUB can load what are essentially unverified binaries (from the POV of the firmware), authenticated against certificates that are kept in unauthenticated UEFI variables. Canonical is even shipping a GRUB with cosmic and disco now that is signed with their master key, and happily boots anything if shim is not loaded, which makes it impossible to ever move to a model where the canonical key is in the UEFI db rather than in the MOK database. So I strongly suggest that you make things work without shim, relying on a monolithic distro signed GRUB which authenticates against the UEFI database only. Should the need ever arise, we can always introduce shim at a later date. In fact, if I were running a shrink wrapped distro and did not have to rely on MS signed option ROMs, I wouldn't even want the MS key in my UEFI db if all I want to run is SUSE.