On Mon, 2015-12-28 at 16:29 +0200, Petko Manolov wrote: > On 15-12-28 07:51:15, Mimi Zohar wrote: > > On Mon, 2015-12-28 at 10:08 +0800, Dave Young wrote: > > > On 12/25/15 at 09:45am, Mimi Zohar wrote: > > > > IMA calculates the file hash, in this case, based on the buffer > > > > contents. The hash is calculated once and used for both measurement > > > > and appraisal. If the file integrity appraisal fails (eg. hash > > > > comparison or signature failure), IMA prevents the kexec files from > > > > being used. > > > > > > > > > > Ok, thanks for the explanatioin. But I have another question, why do we > > > need a special hook for KEXEC? Shouldn't all files use same way to do the > > > measurement and appraisal? > > > > "By all files" are you referring to all files read by the kernel or all > > files opened, executed or mmapped by the system? > > > > Currently IMA allocates a page sized buffer, reads a file a page chunk > > at a time calculating the file hash as it does so, and then frees the > > buffer before returning to the caller. This method of calculating the > > I kind of wonder isn't it possible to optimize the file read? If the file is > relatively small (a few megabytes, for example) it will fit into any modern > system's memory. At least those that cares to run IMA, i mean. > > Fetching file page by page is a slow process even though the BIO subsystem reads > larger chunks off the real storage devices. Has anyone done a benchmark test? Dmitry recently added asynchronous hash (ahash) support, which allows HW crypto acceleration, for calculating the file hash. Mimi