On 2/2/2021 5:07 AM, Mimi Zohar wrote:
On Tue, 2021-02-02 at 07:54 +0200, Amir Goldstein wrote:
On Tue, Feb 2, 2021 at 12:53 AM Raphael Gianotti
<raphgi@xxxxxxxxxxxxxxxxxxx> wrote:
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@xxxxxxxxxxxxx/
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.
I don't understand why you would want to do that. I might have misunderstood
the requirements, but this was not how I meant for tmpfile to be used.
Mimi explained to me that currently the IMA measurement list is entirely in
memory and that you are looking for a way to dump it into a file in order to
free up memory.
What I suggested is this:
- User opens an O_TMPFILE and passes fd to IMA to start export
- IMA starts writing (exporting) records to that file using *kernel* write API
- Every record written to the file is removed from the in-memory list
- While list is being exported, IMA keeps in-memory count of exported entries
- In ima_measurements_start, if export file exists, start iterator
starts reading
records from the file
- In ima_measurements_next(), when next iterator reaches the export count,
it switches over to iterate in-memory list
This process can:
1. Continue forever without maintaining any in-memory list
2. Work in the background to periodically flush list to file
3. Controlled by explicit user commands
4. All of the above
Is that understood? Did I understand the requirements correctly?
Thanks for the clarification Amir, I never actually saw your initial mails,
I apologize for the confusion, the use of mmap was something the original
author of the export ima logs to disk mentioned had been suggested, which
is why I went down that route.
Given the actual suggestion you originally had given, I believe the coding
of it is somewhat to the code I sent in the RFC in terms of approach (if we
were to have it do periodic flushes, for example). With the addition of
reads to the log starting with the file as the oldest logs will be there.
I believe the only difference there is whether the list is kept in a tmp
file or not, so with the tmp file approach it would be just to keep the
list out of memory (either partially or permanently), where with a permanent
file, the list would still be available after a cold boot for instance.
Thanks, Amir!
One of the main requirements we discussed was protecting the O_TMPFILE,
not allowing userspace direct access to the file.
Mimi
