[Linux-ima-devel] [PATCH v2 4/7] ima: measure and appraise kexec image and initramfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux