Re: Verifier running out of memory on ieee1275/powerpc64

[Simon Hardy]

> > 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.
> 
> I think that's the problem to solve, at least for this platform, since none
> of the verifiers will work due to the memory exhaustion issue.

Increasing the heap size may be the easiest way for you to solve this
problem. I am not so familiar with the issues around doing this, but I
have seen recent discussion on this list.

The reason there is extra memory usage is that the verifier framework is
built on top of the file filter framework. The process is:
1. The file is opened using grub_file_open.
2. The verifier framework opens the underlying file and reads all of it
into a new heap-allocated memory buffer.
3. The verifier framework provides the buffer to the verifiers for
verification.
4. The verifier framework returns a file handle.
5. Read operations on this file handle are served by copying from the
verification buffer.
6. The file is closed. The verification framework frees its buffer.

There are good reasons for doing this. It is more secure to ensure that
verification is applied to the same data that is actually used. (An
attacker could give you different data on a second read from the disk.)
Some verifiers, like the TPM, prefer to receive the data in a single
chunk. Existing code depends on the open/read/seek/close file access
model.

The problem you have run into is that where you have a use case that
involves loading a large file into memory then you need enough free
memory to hold two copies of that file.

Ideally there would be an alternative grub_file_read_all function that
loads the contents of a named file to a user-provided memory buffer.
This doesn't look like it would be simple or easy, for example I don't
know how this would work for compressed files.