From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1kUeQ6-0006J6-4x for mharc-grub-devel@gnu.org; Mon, 19 Oct 2020 19:18:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42878) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUeQ4-0006FA-56 for grub-devel@gnu.org; Mon, 19 Oct 2020 19:18:24 -0400 Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]:33315) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kUeQ2-0008Ou-7x for grub-devel@gnu.org; Mon, 19 Oct 2020 19:18:23 -0400 Received: by mail-pl1-x629.google.com with SMTP id b19so625633pld.0 for ; Mon, 19 Oct 2020 16:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:subject:references:date:message-id:mime-version; bh=tnDpyJ5l/KpDsgaGQqC/vY3ZQSB17vu1c2GiVCou6YE=; b=Cl9ct74amZYXVo0XxAmXZqIXQdRhxUHqIG0pS/XdpHiGyMgEqX13M9hGTEgTACORjC Hy0yJiciQHcygCSHALQWboR9bNJanORhfqLGdu7c654fg5ZRNIDO5+4nsQQB20wVcckH IpVSU03OleF0nnkl5xu10TjJ1Mz1knjZ2NI4w= 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:references:date:message-id :mime-version; bh=tnDpyJ5l/KpDsgaGQqC/vY3ZQSB17vu1c2GiVCou6YE=; b=boqvBod0OBul6ELgsVQwmcMKwhJVUk+x1z87h7Aw1/OxA5i0PtOQyGDwQzudESmVtS jOxFPHalZ8MfB98F/PjNt0WwQyUYP9LHqzTlkjQgwW7ctJziFuK5H3DpSFf7mLR5cwpn Ik42roFIv+DV0jYIIrB0TdBpDphgqMhzYXQd4ltkCSZPEYcrr0ItWaK4ysyjuDxE9oXX k2agL/baX+6ab6G1fYz5TzuzKGcp+wfikCZQ7WgTyChXaJSA6hFM2pysROGm3VZjm15q u+uZLtP5GJKFeqcoFELk8phQXkxWs8KlVtFaeKBg0Shk/WdYIzNXPLv5hLiQ0AVntXQx JOzg== X-Gm-Message-State: AOAM531T0WWcQx1pBoopltbqWuhr9Og1hb7zwGG4DOuo3oUNPv3VJcKX zuwjzLVO+JpU9TFnfjNOXeB08I6gnSucjg== X-Google-Smtp-Source: ABdhPJynEM+O6YhEZZcIzJ3TC7HjKbWRFRsY/RF8q7eaea5AzGg8bCHBx7F62ckVJ+WKGxKLJDB7ZQ== X-Received: by 2002:a17:902:a40a:b029:d5:a8fd:9cf8 with SMTP id p10-20020a170902a40ab02900d5a8fd9cf8mr2109521plq.37.1603149500569; Mon, 19 Oct 2020 16:18:20 -0700 (PDT) Received: from localhost (2001-44b8-1113-6700-e473-e52f-4bd5-61fe.static.ipv6.internode.on.net. [2001:44b8:1113:6700:e473:e52f:4bd5:61fe]) by smtp.gmail.com with ESMTPSA id e196sm52919pfh.128.2020.10.19.16.18.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2020 16:18:20 -0700 (PDT) From: Daniel Axtens To: grub-devel@gnu.org Subject: Re: [PATCH 0/3] Add support for signing grub with an appended signature References: <871rhuwi80.fsf@dja-thinkpad.axtens.net> Date: Tue, 20 Oct 2020 10:18:16 +1100 Message-ID: <87v9f5vm87.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::629; envelope-from=dja@axtens.net; helo=mail-pl1-x629.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: Mon, 19 Oct 2020 23:18:24 -0000 [This bounced from the list for some reason, so I'm trying again.] Hi Michal, That's a really interesting proposal - thank you. I'm still thinking about it and experimenting with it in SLOF. Some thoughts: > It has been pointed out in the plumbers session that the ELF note will > cause problems when user wants to add additional signature. > > The normal appended signature has only one size information - in the > footer at the end of the binary, and that is not part of the signed > data. So if you want to add additional signature it if possible to > expand the room for the signature data. The appended signature metadata doesn't contain information about the size of the signed data. It contains the size of the PKCS#7/CMS signature block - because that can change in size based on the hash function and the identity of the signing certificate. Normally this doesn't matter: you can get a size of the whole file from the filesystem and then because you know the size of the appended signature data, you can work out the size of the signed data. > In contrast the ELF note size is present in the ELF header which is > also signed. This does not allow adjusting the size of the signature > data once the binary is signed. Correct. We could potentially allocate lots of space, but you are correct that the size of the ELF note is fixed by the signature. > 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. > 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