From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1kVpiO-0000YE-2t for mharc-grub-devel@gnu.org; Fri, 23 Oct 2020 01:34:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41302) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kVpiN-0000Y5-19 for grub-devel@gnu.org; Fri, 23 Oct 2020 01:34:11 -0400 Received: from mail-pg1-x542.google.com ([2607:f8b0:4864:20::542]:34982) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kVpiH-0004Y9-Oa for grub-devel@gnu.org; Fri, 23 Oct 2020 01:34:10 -0400 Received: by mail-pg1-x542.google.com with SMTP id f38so341201pgm.2 for ; Thu, 22 Oct 2020 22:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=PggidVwpDru5dxM6my9zwpYpPtJ5wCJLgOXfPWV6pMQ=; b=C+UwHG4oHiVOSM3+g5RP459NCC1rU19Vo1IPbQWzjVQAtZ2asvJH3FQxXa74H/tqU6 6r30BIaelUcPdHvwvrdFjN9KYMpnv5/opMiRGd0ubtRw2BcOUZFCzaCHACBSMf2zTHSo pFNoGS7/mMfgBfWvLLwY2IriHNQDXdi3gjVYc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=PggidVwpDru5dxM6my9zwpYpPtJ5wCJLgOXfPWV6pMQ=; b=MxJGRhrXnCmZFS2KzMhvYBFtrsrKgmIQB6T/7cCRTUhnJi1pL38ZkI/Lji4bYQtpYZ 7l4v+uFsf9nptrSyKcdnGrtPYQoa5JUAU8XVSNbqp+SFZ2l7C6NbVQLe3Qpb6mjYiXa7 FMy7jTs4JEn+M4+l04L6tgbmEMwS1OLrlZ+VlUO6s9aesmPIeIVgzCVcJCGkTTS7DpDp 0rxRf+N5FiFMn4h8xjeFSa8j9rfZxXrRCICRy5BhID9VnVjZuMYsQbl+Hl9MsNjjffAS aXfk0hCAthQ1KSL5mnDiRjWEUX59WZpVcw6yYzA3kTAGljPqsFD+acL2EW5eAWMgRNLg m+nQ== X-Gm-Message-State: AOAM531KvqhX6blrf0sCy9eGrchiTRCqixUQ/X7LN+aGmBnZBm657USK IPRw7oZrr0FdLuMqdelA2cbFGA== X-Google-Smtp-Source: ABdhPJwxXldQHQFNocddyoi/JUNpwx2sbU+DWF17I/h69A7owiwmg7wg6lJQ0BXoIFxSZrggiD2suQ== X-Received: by 2002:aa7:9e4a:0:b029:152:54d1:bffa with SMTP id z10-20020aa79e4a0000b029015254d1bffamr749873pfq.6.1603431242974; Thu, 22 Oct 2020 22:34:02 -0700 (PDT) Received: from localhost (2001-44b8-1113-6700-f5f7-0180-09a8-a649.static.ipv6.internode.on.net. [2001:44b8:1113:6700:f5f7:180:9a8:a649]) by smtp.gmail.com with ESMTPSA id e2sm443904pgd.27.2020.10.22.22.34.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Oct 2020 22:34:02 -0700 (PDT) From: Daniel Axtens To: Michal =?utf-8?Q?Such=C3=A1nek?= Cc: grub-devel@gnu.org Subject: Re: [PATCH 0/3] Add support for signing grub with an appended signature In-Reply-To: <20201022111457.GQ29778@kitsune.suse.cz> References: <20201016132038.4f48eea9@naga.suse.cz> <871rhuwi80.fsf@dja-thinkpad.axtens.net> <87lffyvqde.fsf@dja-thinkpad.axtens.net> <20201022111457.GQ29778@kitsune.suse.cz> Date: Fri, 23 Oct 2020 16:33:58 +1100 Message-ID: <87ft65v73t.fsf@dja-thinkpad.axtens.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::542; envelope-from=dja@axtens.net; helo=mail-pg1-x542.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: Fri, 23 Oct 2020 05:34:11 -0000 Hi Michal, >> 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. > > Why do you have to handle different boot media separately, though? > > There is this bug, supposedly in 'old firmware' that when the PReP > partition is large (gigabytes in size) the firmware crashes trying to > load the whole thing to memory and hand it over to the elf parser. If > this is fixed today you need to parse the header anyway to know how much > to load, or you need to just hand over some handle to the partition and > let the elf parser do the reading. Hmm, I will pass this on to the enterprise/proprietary Partiton Firmware (PFW) team to confirm that it's been fixed. It won't affect (at least modern versions of) SLOF, as SLOF caps the amount of PReP partition that it reads at 32MB. It reads min(partition size, 32MB) and passes that to the ELF loader. (I suppose that will break if a bootloader ever grows to be > 32MB, but most distros only allocate something like 8MB to PReP today, so you'd hit partition size limits first anyway.) > The appended signature format is exactly the same in each case: there is > a container such as a partition, a file, or a block of memory that has > an elf binary at the start, optional padding, and optinal signature at > the end. There is nothing stopping the elf parser from parsing both > the elf header and the signature footer when it gets the data. Reflecting on it, the proposed new design is also pretty quirky. The existing appended signature format is: data || pkcs7 || metadata || magic If you strip off the signature, only the data remains, which you can immediately calculate the hash on and verify the signature. The ELF note format perserves this property. Moving the signature to the end of the PReP partition gives you: data || [padding] || pkcs7 || metadata || magic Once you've stripped off the signature, you now need an extra processing step to strip off the padding. And - unusually for appended signatures - you need to know about the format of the data to distinguish data from padding. > In the case of the partition containing the elf binary it is expected > that the padding is non-zero, in the other cases having padding is > suspicious. > > In the case of a partition you have to read the data in some > device-specific sectors while files can be read at arbitrary sized > chunks. > > If you choose to write separate code to fetch the elf binary from > different media due to these differences then these separate code paths > must be adjusted. However, that is inherent to lack of suitable > abstraction in the code, and not the appended signature format. > > I think it is more productive to clean up the code to handle all media > the same way rather than inventing new unique quirky and deficient > signature format. You would need to handle the new padding at some stage in the pipeline, and that pipeline stage needs to know how to read an ELF header. So I agree that it would be logical to put signature verification in the ELF parsing stage. However, if you want to flag the existence of padding in non-PReP cases - either to reject it or warn about it - then the signature verifier needs to know if it's parsing a PReP partition. If the signature validation lives in the ELF parser, you now need to tell the ELF parser that you are parsing a PReP partion. This seems like an abstraction or layering problem - the ELF parser shouldn't need to know or care where the ELF binary comes from. So I think that merely cleaning up the code wouldn't be sufficient. Kind regards, Daniel > > Thanks > > Michal > >> >> 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