> > 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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
