All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Hardy <simon.hardy@itdev.co.uk>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: Verifier running out of memory on ieee1275/powerpc64
Date: Wed, 18 Mar 2020 15:59:07 +0000	[thread overview]
Message-ID: <20200318155906.GC2186@itdev.co.uk> (raw)
In-Reply-To: <a09d69a2-8e3d-54ba-394e-4c7090ce2df3@linux.ibm.com>

The 2020/03/17 13:15, Stefan Berger wrote:
>  I trying to add (v)TPM support for the ieee1275/powerpc64 platform to grub.
> The issue I have been running into is that the verifier runs out of memory.
> At that point it has loaded the (~ 32MB) Linux kernel and now the verifier
> is invoked to load the file. Unfortunately it cannot load the file since it
> doesn't have enough memory to grub_malloc. I have played with increasing
> heap size(es) but it still doesn't work. The kernel and initramfs files on
> ppc64 can be rather big, thus we do not a lot of memory. The rescue
> initramfs here is for example 78MB, a regular initramfs from Fedora 31 is
> ~34MB. The kernel sizes on my system are 32MB, though a colleague was using
> an unstripped kernel of 127MB, so lots of (unfragmented) memory needs to be
> available to run verifiers.

The verifiers framework has a flag, GRUB_VERIFY_FLAGS_SINGLE_CHUNK, that is
used by the platform-independent TPM module. This could be deferred to the
platform-specific TPM file (see point 3 below). With this flag unset for your
platform, you could verify the files in small chunks. This requires three
further elements: 

1. You will need to implement the chunk-by-chunk behaviour in
verifiers.c, it doesn't exist yet.

2. You will need to add functionality to calculate a hash from chunks, or
require that the crypto module is built into the core.

3. The firmware interface needs to support HashLogExtend with a user supplied
hash instead of a memory buffer. For example the PC Conventional BIOS API has
this, but the UEFI API does not.



  reply	other threads:[~2020-03-18 15:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-17 17:15 Verifier running out of memory on ieee1275/powerpc64 Stefan Berger
2020-03-18 15:59 ` Simon Hardy [this message]
2020-03-18 19:32   ` Stefan Berger
2020-03-18 20:27     ` Stefan Berger
2020-03-18 22:17       ` Simon Hardy
2020-03-19 16:37         ` Stefan Berger
2020-03-20 17:14           ` Eric Snowberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200318155906.GC2186@itdev.co.uk \
    --to=simon.hardy@itdev.co.uk \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.