Re: [RFC] Persist ima logs to disk

[Raphael Gianotti <raphgi@linux.microsoft.com>]

On 1/8/2021 9:58 AM, Raphael Gianotti wrote:
>
> On 1/8/2021 4:38 AM, Mimi Zohar wrote:
>> On Thu, 2021-01-07 at 14:57 -0800, Raphael Gianotti wrote:
>>>>>>> But this doesn't address where the offloaded measurement list
>>>>>>> will be stored, how long the list will be retained, nor who
>>>>>>> guarantees the integrity of the offloaded list.  In addition,
>>>>>>> different form factors will have different requirements.
>>> For how long the list would be retained, or in the case of a log 
>>> segments, it
>>> might make sense to have that be an admin decision, something that 
>>> can be
>>> configured to satisfy the needs of a specific system, as mentioned 
>>> below by
>>> James, does that seem correct?
>> For the discussion on exporting and truncating the IMA measurement
>> list, refer to:
>> https://lore.kernel.org/linux-integrity/1580998432.5585.411.camel@linux.ibm.com/ 
>>
>>
>>> Given the possibility of keeping the logs around for an indefinite 
>>> amount of
>>> time, would using an expansion of the method present in this RFC be 
>>> more
>>> appropriate than going down the vfs_tmpfile route? Forgive my lack 
>>> on expertise
>>> on mm, but would the vfs_tmpfile approach work for keeping several 
>>> log segments
>>> across multiple kexecs?
>> With the "vfs_tmpfile" mechanism, breaking up and saving the log in
>> segments isn't needed.  The existing mechanism for carrying the
>> measurement list across kexec would still be used.  Currently, if the
>> kernel cannot allocate the memory needed for carrying the measurement
>> across kexec, it simply emits an error message, but continues with the
>> kexec.
>
> In this change I had introduced "exporting" the log to disk when the size
> of the measurement list was too large. Given part of the motivation 
> behind
> moving the measurement list is the possibility of it growing too large
> and taking up too much of the kernel memory, that case would likely lead
> to kexec not being able to carry over the logs. Do you believe it's 
> better
> to use the "vfs_tmpfile" mechanism for moving the logs to disk and worry
> about potential issues with kexec not being able to carry over the logs
> separately, given the "vfs_tempfile" approach seems to be preferred and
> also simplifies worries regarding truncating the logs?

After a chat with Mimi I went ahead and did some investigative
work in the vfs_tmpfile approach suggested, and I wanted to
restart this thread with some thoughts/questions that came up
from that.
For the work I did I simply created a tmp file during ima's
initialization and then tried to use vm_mmap to map it to memory,
with the goal of using that memory mapping to generate return
pointers to the code that writes the measurement entries to memory.
What I found out is that vm_mmap creates a user space address
mapping, which can't be directly written to/read by kernel code,
am I missing something here ? I looked throughout the code and
read the implementation of vm_mmap and the functions it calls,
but I couldn't figure out if there's a version of this type of
mapping that returns a kernel space address.
Out of curiosity, I also tried (simply to test the approach),
translating the mapped address into a valid kernel address
by using find_vma(),  follow_page() and kmap(). I was able
to get a return value from kmap() that passed an IS_ERR() check,
however I couldn't get that to work properly when trying to
access it to read to/write from it. Again, I feel like the
mapping should be done directly to a valid kernel address,
but I wanted tried this to at least be able to prototype the
overall flow of the change.

Raph

>
>>
>> Mimi