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, Amir! One of the main requirements we discussed was protecting the O_TMPFILE, not allowing userspace direct access to the file. Mimi
