On 3/18/20 11:59 AM, Simon Hardy wrote:
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.
Simon, thanks a lot for your reply.
TPM 2's logging behavior is different than that of a TPM 1.2 and it's
not clear whether hashing in grub will produce the right hash or hashes
(for different PCR banks) as needed by the firmware. I would rather
leave the hashing entirely up to the firmware because it knows which PCR
banks are activate and what hashes it wants to use for logging and PCR
extending.
I was wondering whether it would not be possible to load the raw file
into memory, pass it to the firmware for hashing (and logging) via the
verifier, and if we do not trust that the firmware treated the file data
as a read-only array, load the file again into the same array right
after. This way we wouldn't need more memory. [*] However, I am not sure
how it fits into the architecture with the verifiers or whether the TPM
verifier would have to take on a special role (possibly with a flag) then.
You didn't pick up on the idea of a bigger heap. Is there a problem with
the heap size somehow? My machine has GBs of memory, so it really
shouldn't be a problem to get memory.
[*] Obviously we can load the files. We can also load them while the TPM
verifier is active but only when preventing the loading of those large
files (actually allowing the grub_malloc() on the large size to occurr
seems to cause issues booting). The memory allocations that are
occurring due to the TPM verifier do not seem to cause memory
fragmentation that would prevent the loading of those large files. So,
makes me think, re-load the files into the same memory.
Stefan
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
