From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1kVSAc-00014D-FK for mharc-grub-devel@gnu.org; Thu, 22 Oct 2020 00:25:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51296) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kVSAa-00013i-Hl for grub-devel@gnu.org; Thu, 22 Oct 2020 00:25:44 -0400 Received: from mail-pf1-x442.google.com ([2607:f8b0:4864:20::442]:34533) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kVSAW-0002zA-1P for grub-devel@gnu.org; Thu, 22 Oct 2020 00:25:44 -0400 Received: by mail-pf1-x442.google.com with SMTP id e10so358350pfj.1 for ; Wed, 21 Oct 2020 21:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=RrSe72JcgvqVxvVwAODqGlFrMMUZ0yDRCqBKWY2bieQ=; b=b5NLsUQCYKvKlanPueF/S6oFQrU8kjQHhm8KW8pj309JI3RoMl/OUY5W5XqHQ060lN sl4e5yYvTs50ZFvGdi43qa+1C/OdAbYxfORCgRK58TU+3KFTsycpqRwPkx9mFP/H4T+a HgvkaSeAvFd0OFv9SjCNwRUVcJa2p0g18jNSk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=RrSe72JcgvqVxvVwAODqGlFrMMUZ0yDRCqBKWY2bieQ=; b=unZ4N0ZznJjUYZtNrCh6aES1FwQXJ9MobXSWR3fVYkIh9tp+wwYqJOzk/Nq3VycQ/M J3/vqtJJXVaXLnVhG0eSledkalCBBuzj0BcyWBrq366r+hyj+diXoaNJ4dhrO9kvFvwj PABhnQgF98xyQ930qKd7RX77rUqSQ4TyAHxDD6RMztgU4oJnKuHXX/iKbyl/5pRWAGXb 1zA47gfG3LU4cOaifsvcT9hknoqpUJk0JEdOk70TrqQ4EKt3GajCW4g4mszKsdPe3tSr EorS4g0lDxcZPbh4bZzfr25TpOdDd4jwCaJKPNHbrQaqNmTMU32//B8CsrSLjInfkn9j 6FiA== X-Gm-Message-State: AOAM533KXMwwmLSUisxGpraUJx0XRnP6dGhJUsdKK+xjrpJMdGKv8qj1 hWSp/hesMcuvz4fF7BCzN7iyCw== X-Google-Smtp-Source: ABdhPJxLffuz+sSl4MhhZmjZW3gSckMH/Kv/pbxfGyStrjjnu8HlCdvCZmP4Tl7zGQ5uxVM3rBaYZQ== X-Received: by 2002:a63:ab45:: with SMTP id k5mr722327pgp.240.1603340737206; Wed, 21 Oct 2020 21:25:37 -0700 (PDT) Received: from localhost (2001-44b8-111e-5c00-f46e-77ea-75c9-0b7f.static.ipv6.internode.on.net. [2001:44b8:111e:5c00:f46e:77ea:75c9:b7f]) by smtp.gmail.com with ESMTPSA id kv19sm333815pjb.22.2020.10.21.21.25.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2020 21:25:36 -0700 (PDT) From: Daniel Axtens To: Michal =?utf-8?Q?Such=C3=A1nek?= , grub-devel@gnu.org Subject: Re: [PATCH 0/3] Add support for signing grub with an appended signature In-Reply-To: <871rhuwi80.fsf@dja-thinkpad.axtens.net> References: <20201016132038.4f48eea9@naga.suse.cz> <871rhuwi80.fsf@dja-thinkpad.axtens.net> Date: Thu, 22 Oct 2020 15:25:33 +1100 Message-ID: <87lffyvqde.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::442; envelope-from=dja@axtens.net; helo=mail-pf1-x442.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 04:25:44 -0000 Hi Michal, >> A simpler scheme would be for grub-install to parse the signature >> footer, split-off the signature, write the ELF binary at the start of >> the PReP partition, and the signature at the end. Then the grub >> signature can use exactly same format as the kernel and modules. > > I got part way through implementing this today in SLOF and realised that > it's not immediately clear what the size of the signed data is for > verifying the appended signature - that is, how much of the PReP > partition should I be hashing? As I said, the appended signature > metadata doesn't encode this particular size value. > > One thing that we might be able to do is to base the size of the > verified data on a size calculated from the ELF header: basically figure > out the maximum file offset + size for all the program headers, capped > at (partition size - appended signature size), and hash that many > bytes. If I understand correctly, and assuming grub-mkimage constructs > valid ELF files, this should be correct. > > I'll give this a go in SLOF tomorrow, and I'll also need to confer with > the team that develops the proprietary firmware used by PowerVM. > I talked to the firmware team this morning. So grub is usually loaded from the PReP partition if you are booting from disk. But, if you are booting from a CD/USB/etc, we first parse /ppc/boot-info.txt and then load whatever file it identifies. If you're netbooting we load the file we get from the network. One strength of the ELF-note based scheme is that verification of the appended signature is exactly the same in all these scenarios, and in each case it can live entirely in the ELF parsing and loading code. In contrast, if we don't have an elf note, we have to handle PReP partitions, CHRP boot-info.txt and netboot separately. At least in the PReP case we also have to do parse enough of the ELF header to determine how much data we need to be hashing for signature verification, and this crosses a couple of previously separate steps of the process. To illustrate from SLOF, currently the ELF note stuff lives almost entirely in elf32.c, but for the scheme you describe we need to patch load-from-dos-boot-partition, load-from-gpt-prep-partition, whatever code we use for where we boot a file directly from disk for CHRP boot-info.txt loading, and something somewhere in the netboot code. We can still support multiple signers disjoint in time with the scheme I suggest at https://lists.gnu.org/archive/html/grub-devel/2020-09/msg00081.html although I do agree it's ugly in its own separate way. Kind regards, Daniel >> The disadvantage is that for signed grub dd is no longer an alternative >> to grub-install. >> >> There was also concern about distinguishing signed and un-signed grub. >> That is that writing an un-signed grub might lease a stale signature >> leading to an error. >> >> However, secure boot is something that should be enabled or disabled in >> firmware settings, and not triggered by the PPeP partition containing a >> signature. >> >> When secure boot is enabled checking the grub signature is required and >> un-signed grub is invalid. When secure boot is disabled the signature >> is irrelevant and stale signature should not cause any error. > > What I'm concerned about here - and it's possible I explained it poorly > at Plumbers - is how a systems administrator would distinguish between > having accidentally installed an unsigned grub, and having installed a > grub with a broken or untrusted signature. > > Having said that, ... > >> grub-install can also remove the signature magic when installing >> un-signed grub for consistency. Users using dd to install un-signed >> grub might still have an old signature at the end of the partition. > > if we make grub-install do the right thing, I think that sufficiently > mitigates my concern. > > Thanks again, and I'll let you know how I get on shortly. > > Kind regards, > Daniel