Re: Verifier running out of memory on ieee1275/powerpc64

[Stefan Berger <stefanb@linux.ibm.com>]

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