Hi Raphael, Thanks a lot. I understand it very well that the mm tricks surprise many. Moreover, I certainly understand that it might be over-engineering in the case it hits a trap with the mm, but the approach does have clear benefits in case it works (most importantly we would never use any kernel memory). Let's see what you come up with. Thanks again, -- Janne On Wed, Sep 2, 2020 at 12:32 AM Raphael Gianotti <raphgi@xxxxxxxxxxxxxxxxxxx> wrote: > > Hi Janne, > > As I mentioned previously I know very little about the approach you had > mentioned. I read a little more on it and I think now I understand it a > little better and yes, it should actually work. > > I will spend some time familiarizing myself with how this would work > so I can actually compare both approaches myself on a technical level > and have a more well informed opinion on the matter before moving on > with either sending an RFC for the first approach (based on your code > from last year) or starting some work using the new approach you brought up. > > Thanks, > > -Raphael > > On 8/31/2020 11:52 PM, Janne Karhunen wrote: > > Hi Raphael, > > > > It depends how well you make it, if you do it right you would not lose > > them. If the pagefile has a readable format it should all be safe, > > right? > > > > > > -- > > Janne > > > > On Mon, Aug 31, 2020 at 7:49 PM Raphael Gianotti > > <raphgi@xxxxxxxxxxxxxxxxxxx> wrote: > >> Hi Janne, > >> > >> Thanks for your response, I didn't reply right away as I hadn't used mm > >> and vmarea via vfs_tmpfile before, so I wanted to read some code to > >> familiarize myself with it. Correct me if I am misunderstanding the > >> approach you mentioned, but in it, we would still lose the logs accross > >> kexec/cold boots as we do today, is that correct? It feels like this > >> approach would solely solve the issue where we can potentially run out > >> of memory for ima logs. > >> > >> For the original approach, I have a prototype version that I intend to > >> send as an RFC soon (I will link you and it's based off of your original > >> RFC from late last year). > >> > >> - Raphael > >> > >> On 8/26/2020 7:12 AM, Janne Karhunen wrote: > >>> 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. > >>>>>>
