Hi, Come to think of it, there could be a MM trap though as I'm not sure this has been done before. This new file vmarea would sit in the kernel virtual memory area somewhere above the page_offset and the mm code might assume that there is no need to look for dirty pages there when running the PTE scan. But that shouldn't be more than one line patch if that is the only trap.. -- Janne On Wed, Aug 26, 2020 at 4:40 PM Janne Karhunen <janne.karhunen@xxxxxxxxx> wrote: > > Hi, > > Attached a variant of the patch from that time that only does the > element free and relies on the userspace reading the data. > > The reason why I stopped working on this at the time was that below > was sufficient for my needs. However, after a discussion between Mimi > and myself (based on a suggestion by Amir Goldstein) we realized that > we could do something considerably more elegant through vfs_tmpfile. > It's also much more work. > > The way this could probably work the best is if we would implement a > new allocator that would pull pages from a vmarea tied to a > vfs_tmpfile and the file could be opened by the kernel itself during > the ima init. Now if all the measurement list data blobs would be > allocated through this allocator the pages would never be permanently > resident in the kernel, they would only visit the memory for a while > when someone reads the data. If done this way the allocator probably > does not even need a 'free' and the mm code would do all the real work > pushing the data out. > > The benefits would be that no-one would ever have to poll from > userspace (kernel does not depend on the userspace to work) and we > would never OOM because of IMA as long as the filesystem is writable. > Also we would never lose any data as long as the file system is > functioning. > > Thoughts? > > > -- > Janne > > On Wed, Aug 26, 2020 at 11:14 AM Janne Karhunen > <janne.karhunen@xxxxxxxxx> wrote: > > > > Hi Raphael, > > > > Sorry I missed the reply. I'm not working on this right now, feel free > > to grab. Please copy me with the results, thank you. > > > > > > -- > > Janne > > > > On Tue, Aug 18, 2020 at 12:30 AM Raphael Gianotti > > <raphgi@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > Hi Janne, > > > > > > Subject: Re: [RFC] ima: export the measurement list when needed > > > > Date: Wed, 18 Dec 2019 17:11:22 +0200 > > > > From: Janne Karhunen <janne.karhunen@xxxxxxxxx> > > > > To: linux-integrity@xxxxxxxxxxxxxxx, Mimi Zohar <zohar@xxxxxxxxxxxxx> > > > > CC: Ken Goldman <kgold@xxxxxxxxxxxxx>, david.safford@xxxxxxxxx, > > > > monty.wiseman@xxxxxx > > > > > > > > Hi, > > > > > > > > Have in mind that below is the first trial draft that booted and > > > > seemingly accomplished the task once, it was not really tested at all > > > > yet. I will make a polished and tested version if people like the > > > > concept. > > > > > > > > Note that the code (almost) supports pushing and pulling of the > > > > entries. This variant is a simple pull given that the list size is > > > > above the defined limits. Pushing can be put in place if the recursion > > > > with the list extend_list_mutex is cleared, maybe this could be done > > > > via another patch later on when we have a workqueue for the export > > > > task? The workqueue might be the best context for the export job since > > > > clearing the list is a heavy operation (and it's not entirely correct > > > > here AFAIK, there is no rcu sync before the template free). > > > > > > > > > > > > -- Janne > > > > > > > > On Wed, Dec 18, 2019 at 2:53 PM Janne Karhunen > > > > <janne.karhunen@xxxxxxxxx> wrote: > > > >> > > > >> Some systems can end up carrying lots of entries in the ima > > > >> measurement list. Since every entry is using a bit of kernel > > > >> memory, add a new Kconfig variable to allow the sysadmin to > > > >> define the maximum measurement list size and the location > > > >> of the exported list. > > > >> > > > >> The list is written out in append mode, so the system will > > > >> keep writing new entries as long as it stays running or runs > > > >> out of space. File is also automatically truncated on startup. > > > >> > > > >> Signed-off-by: Janne Karhunen <janne.karhunen@xxxxxxxxx> > > > >> --- > > > >> security/integrity/ima/Kconfig | 10 ++ > > > >> security/integrity/ima/ima.h | 7 +- > > > >> security/integrity/ima/ima_fs.c | 178 +++++++++++++++++++++++++++++ > > > >> security/integrity/ima/ima_queue.c | 2 +- > > > >> 4 files changed, 192 insertions(+), 5 deletions(-) > > > > > > I've been looking into a solution to this same issue you started some > > > work on. I was wondering if you are still working on it. I was > > > considering taking your initial prototyping on this and extending it > > > into a final solution, but I wanted to reply here first and check if you > > > are currently working on this. > > >
