Re: Verifier running out of memory on ieee1275/powerpc64

[Stefan Berger]

On 3/18/20 6:17 PM, Simon Hardy wrote:
> > > 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.

I found the lsmmap command and it shows me some impressive memory ranges 
to be known:

base_addr = 0x4000, length = 0x17c000, available RAM

base_addr = 0x1fffff, length = 0x1, available RAM

base_addr = 0x21ffff, length = 0x1, available RAM

base_addr = 0x2000000, length = 0x7bbf0000, available RAM

base_addr = 0x7feffffff, length = 0x1, available RAM

base_addr = 0x800903dc, length = 0x7ff6fc24, available RAM

There's more than needed memory here. It doesn't seem to be available 
for grub_malloc, though.

> 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.
Yes, saw this, verify_fs.
> 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.)
Also true.
> 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.


Stefan


> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel