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.
